Hallo,

das Betriebssystem liefert für den OLE-Fehler <b>800A03EC</b> die folgenden Informationen zurück:
<pre>
Error Result : 0x800A03EC ( -2146827284 )
ID Defined as :
Error Type : OLE HRESULT Error
Facility : FACILITY_CONTROL 0x0000000A ( 10 )
Severity : SEVERITY_ERROR 0x00000001 ( 1 )
Code : 0x000003EC ( 1004 )
Source Error file :
Message Text : This 800a03ec is a FACILITY_CONTROL (HRESULT_SEVERITY = 1 and HRESULT_CODE = 3ec)
error that is specific to the control's interface that returned this error.
See the documentation of the interface that returned this error for
information about this HRESULT.
</pre>
Somit stammt der Fehler direkt aus Excel.

Wenn man in Microsoft Excel den <b>VBA-Editor</b> aufruft, steht die VBA-Hilfe zur Verfügung (wenn man diese Hilfedatei mit installiert hat). Dort werden für <b>Application.Left</b> verschiedene Ausnahmen dokumentiert.

Der Aufruf von <b>GetUserDefaultLCID</b> gehört zur Gattung "defensiver Programmierstil" und soll pauschal Probleme vorbeugen, die bei bestimmten Funktionen auftreten können, wenn man für die lcid nur den Wert 0 übergibt. Auch hier gibt die VBA-Dokumentation des Excel-Objektmodells letzte Klarheit.

In der Tat gibt es seit einigen Tagen ein Buch: <b>COM/DCOM/COM+ mit Delphi</b> (ISBN 3-935042-01-9) befasst sich in einem Kapitel auf 112 Seiten mit dem Thema <i>Automation</i> mit dem Schwerpunkt Microsoft Office 2000 (Word, Excel, Outlook). Auf der CDROM zum Buch ist auch ein Tool zu finden, mit dem derartige OLE-Fehler selbst untersucht werden können.
&#10

loadPicture über delphi ausführen
  hallo,

ich habe das problem, dass ich beim aufruf einer excel-datei (über delphi)
sowohl text, als auch ein bild in bestehende komponenten laden möchte.

in der excel-datei sind die beiden komponenten für
1. text = label (heiüt kopfzeile)
2. bild = image (heiüt briefkopf)

um den text in das bestehende label KOPFZEILE einzutragen benutze ich in
delphi den befehl

xlSheet.Kopfzeile.Caption := 'dies ist meine kopfzeile'
wobei xlSheet vom Typ OleVariant ist und voher über xlApp := CreateOleObject('Excel.Application) mit
xlSheet := xlApp.ActiveWorkbook.Sheets("start") initialisiert wurde.

wie aber kann ich ein bitmap in die image-komponente BRIEFKOPF laden.

der VBA-Code in Excel sähe wie folgt aus:
ActiveWorkbook.Sheets(i).briefkopf.Picture = LoadPicture(bild.bmp)

hierfür finde ich aber in delphi keine möglichkeit.

weiü vielleicht jemand rat.

vielen dank im voraus
stefan

Fehler - oder nur Sprung zum Debugger...?
  Hallo,

...ich weis nicht, ob ich das jetzt richtig verstanden habe :
Es kommt keine Fehlermeldung, sondern es wird nur der Debug-Modus aufgerufen...?
Wenn das so ist, dann gibt es im VBA-Projekt einen Konflikt zwischen
VBA-Code und Byte-Code.

Grund : Es ist noch ein Haltepunkt im Byte-Code vermerkt,
der im Quelltext nicht mehr existiert. Oft hilft hier, irgendwas zu ändern,
und das VBA-Projekt neu zu kompilieren und zu speichern.

Falls das nicht hilft, muü man den Bytecode aus dem Projekt entfernen.
Bei Access gibt es eine Kommanozeilenoption /decompile - bei Excel weiss
ich das nicht. Evt. muü man das Modul exportieren, löschen und neu einfügen...

...und falls es doch eine Fehlermeldung gibt -
hast Du die irgendwo gepostet
(und ich bin nur zu blind, diese zu sehen...) ?

Grüüe,
tAgedObject

An alle VBA Spezialisten!!!
  Hi,
Ich möchte in einer Inputbox, welche als Passworteingabe eingesetzt werden soll, das Passwort mit einer Reihe von Sternchen ****** quasi unsichtbar machen. Meistens ist ja das Umgekehrte der Fall ;-) !
Konkret ich arbeite in Excel, habe verschiedene Dateien die mit einem Passwort geschützt sind. Tippe ich nun beim Aufruf der Dateien mein Passwort in die Inputbox, so kann Kollege XY mir jederzeit über die Schultern gucken und mein Passwort erspähen.
Ich weiss, es existieren solche Macros in VB (die Inputbox kann als Passwortfeld direkt definiert werden, so viel ich weiss) ich muss diese Verschlüsselung jedoch in VBA haben!
Kann mir jemand den Code dazu liefern, oder sogar für mich schreiben. Ich selber habe nämlich von VB und VBA keine Ahnung!!!! :o

Ich freue mich schon auf eure Hilfe!!!

Thx Tea

Hallo Alexander,

Alexander Lorenz schrieb:
> wie gesagt ich sehe sowas auch zum ersten mal. Ich debugge im
> Einzelschritt zu dieser Zeile wo das Tabellenblatt kopiert werden
> soll. Sobald ich dann diese Zeile mit F8 ausführe ist der gelbe
> Balken weg und mein Cursor blinkt wieder. Keine Fehlermeldung - kein
> gar nix. Im übrigen ist das Tabellenblatt auch nicht kopiert.
> Ich habe dann das ganze einmal von Hand gemacht (copy sheet to) und
> da klappt alles.

wenn dein Code nicht als Tabellenfunktion aufgerufen wird, ist mir das
auch ein Rätsel. Wenn es dir nichts ausmacht, kannst du mir ja mal eine
anonymisierte Mappe mit dem Fehler zusenden, vielleicht kann ich ja
etwas erkennen.

MfG
Michael

--
Michael Schwimmer
Home : (Kein Link ?)
Excel VBA ISBN 3-8273-2183-2

Hallo Norbert,

Norbert Harz schrieb:
> ( es sei actRow = 1 und i = 1 )
>
> Range(Cells(actRow + 2 + i, 1), Cells(actRow + 2 + i, 3)).Merge
>
> Trotzdem werden die Zellen nicht verbunden..
> Hat jemand noch eine Idee??

unter Excel 2000 und 2003 funktioniert diese Syntax einwandfrei,
welche Excel-Version verwendest du?

Eine einfacherere Schreibweise wäre wie folgt:

Cells(actRow + 2 + i, 1).Resize(1, 3).Merge

> Mal gleich nochwas. Wenn ich versuche die Geschichte mittels
> Tabelle2.Range(Cells(actRow + 2 + i, 1), Cells(actRow + 2 + i, 3)).Merge
> aufzurufen, bekomme ich einen Laufzeitfehler 1004. Ich umgehe das, indem
> ich das Sheet aktiviere und wieder deaktiviere.
> Kann man Merge auch auf ein nicht aktives Sheet anwenden?

Um auf Zellen eines nicht aktiven Tabellenblattes zuzureifen musst du das
Worksheet-Objekt jeweils den Range- und Cells-Angaben voranstellen:

With Worksheets("Tabelle2")
.Range(.Cells(actRow + 2 + i, 1), .Cells(actRow + 2 + i, 3)).Merge
' oder
.Cells(actRow + 2 + i, 1).Resize(1, 3).Merge
End With

Mit freundlichen Grüssen
Melanie Breden

--
- Microsoft MVP für Excel -
Microsoft Excel - Die ExpertenTipps (Kein Link ?)
Das Excel-VBA Codebook (Kein Link ?)
Excel-Auftragsprogrammierung

Dateiliste per VBA
  Hallo zusammen,
beim Aufruf einer UserForm wird in meinem Makro eine Liste der derzeit
geöffneten Excel-Dateien angezeigt, aus der der User eine Datei auswählen
soll. In diese Datei sollen dann Meüwerte aus der aufrufenden Datei
übertragen werden. Folgenden Code benutze ich (auf das wesentliche reduziert):

Private Sub UserForm_Initialize()
Dim Datei As Object
For Each Datei In Workbooks
ListBox1.AddItem Datei.Name
Next
End Sub

Das Problem: Ich möchte verhindern, daü der Name der aufrufenden Datei
ebenfalls in der Liste angezeigt wird, damit nicht jemand versehentlich die
Daten in diese Datei kopieren kann.
Kann mir jemand helfen?
Danke und schönen Gruü
Alexander

VB6.0: Hilfedateien ( CHM - Files) werden nicht korrekt angezeigt
  Hallo wer weiü Rat?
Die Hilfedateien für die Visual Basic Referenzen werden nicht korrekt
angezeigt.
Der Ladevorgang beim Aufruf über F1, egal ob aus dem Programmcode einer
VBA-Anwendung (Office 2000 Paket) oder VB6.0 professionell ist schleppend.
Icons erscheinen nur als Platzhalter. Querverweise funktionieren nicht. Auch
die Microsoft Excel Hilfe verhält sich so.
Betriebssystem WinXP SP2 Home musste erst kürzlich repariert werden. Office
2000 wurde wieder neu nachinstalliert, ebenso VB6.0 mit MSDN-Library.
Gruü
Reinhard

Hallo Reinhard!

"Reinhard Schüll" <Reinhard.Schuell@t-Online.de> schrieb:
> Die Hilfedateien für die Visual Basic Referenzen werden nicht korrekt
> angezeigt.
> Der Ladevorgang beim Aufruf über F1, egal ob aus dem Programmcode einer
> VBA-Anwendung (Office 2000 Paket) oder VB6.0 professionell ist schleppend.
> Icons erscheinen nur als Platzhalter. Querverweise funktionieren nicht.
> Auch die Microsoft Excel Hilfe verhält sich so.
> Betriebssystem WinXP SP2 Home musste erst kürzlich repariert werden.
> Office 2000 wurde wieder neu nachinstalliert, ebenso VB6.0 mit
> MSDN-Library.

Sicherheitshalber solltest du zuerst einmal die Temporären Internetdateien
löschen. Sollte dies nicht das Problem beheben, dann kannst du wie folgt
vorgehen:

Wenn kleine "Kästchen" anstatt der Links in der Hilfe angezeigt werden, kann
dies durch Einspielen bestimmter Patches verursacht worden sein, die die
HTML Help mit einer falschen Version überschreiben. Abhilfe schafft die
Installation folgender Patches:

MS02-055: Unchecked Buffer in Windows Help Facility May Allow Attacker to
Run Code
<URL:http://support.microsoft.com/?scid=kb;EN-US;323255>

HTML Help Update to Limit Functionality When It Is Invoked with the
window.showHelp( ) Method
<URL:http://support.microsoft.com/?scid=kb;EN-US;811630>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Tachchen!

>> Wesentlich bestand das Verzeichnis bereits in der Vorlage und wird
>> dann beim Seriendruck (genau ein Exemplar, in welches die
>> Serienbrieffelder aus der Excel-Datei eingefügt werden) entsprechend
>> aktualisiert - soweit so gut.
> Führst du den Seriendruck echt in eine neue Datei aus? Dann wird das
> TOC-Feld sowieso in sein Resultat umgewandelt und ist kein Feld mehr
> (nur noch die Seitenzahlen sind Hyperlinks/Querverweise auf Ziele, die
> aber auch nicht mehr auf's Richtige zeigen :-)).

Alternative mit den Datenfeldern?

> Also: Im Serienbriefhauptdokument oder im "Resultat" (in neue Datei
> ausgeführter Serienbrief). Falls Ersteres und du sagst, dass es _vor_
> deinem Code funktioniert, dann würde ich mich mit Codeauszug in die
> .vba-Gruppe wenden.

Das mit dem Vor_Meinem_Code sollten wir klären:
1. Vorlage wird aufgerufen und stellt erst einmal sämtlichen Werte und
Daten ein.
2. Datenbank (Excel-Datei) wird verknüpft und die Daten dann in ein
neues Dokument geschrieben.
3. Im neuen Dokument stimmen die Ergebnisse der TOC-Felder überein,
jedoch sind die Zielmarken nicht mehr vorhanden. F9 bringt dann doch zum
Vorschein, dass die Feldmarken nicht existieren.

Ich habe mir gerade mal genauer angeschaut, was mit F9 passiert und
dabei feststellen müssen, dass im Gegensatz zu dem, was ich gewöhnt bin,
mit F9 nicht das gesamte Dokument aktualisiert wird, sondern nur die
Markierung....

Damit ist zu mindest klar, dass der fehler beim öbergang auf das neue
Dokument ohne VBA passiert. Jetzt brauch ich nur eine Lösung, wie das
TOC (am besten variabel - für den Fall von ćnderungen im Zieldokument)
den öbergang überlebt.

solong,
Erik.

"Beat" <beathinnen@web.de>:

> Liesse sich das Problem nicht viel eleganter mit Formularfeldern
> und einem geschützten Abschnitt lösen?

Wir haben von der Marketingfirma auch eine Version mit Formular-
feldern erhalten. Das hat sich als nicht praktikabel herausge-
stellt, weil es viel zu unflexibel ist. Obwohl ich persönlich
meine, daü einigen Nutzern damit schon geholfen wäre.

Vielleicht entwerfe ich auch eine Version, die einen Menüpunkt
hinzufügt. Der öffnet einen Dialog, in die der Nutzer seine Daten
eintragen kann. Der VBA-Code dieses Dialoges platziert das dann
unfallfrei an den entsprechenden Stellen im Briefkopf, weist die
dafür vorgesehenen Formatvorlagen zu und stellt sicher, daü die
Grunddaten in der Dokumentvorlage gespeichert werden.
Wird die Userform dann bei einer bereits konfigurierten Dokument-
vorlage aufgerufen, kann der Nutzer wählen, ob die Daten nur in das
Dokument übernommen oder ob auch die Vorlage nachgeführt werden
soll. Schlieüt der Nutzer den Dialog, wird der Cursor direkt an die
Position für den Flieütext gesetzt, alles andere hat der Nutzer
bereits im Dialog angegeben.
Ich habe schon einen VBA-Code (und Erfahrung mit VBA for Excel und
Access), der Text an Textmarken einfügen und diese dabei auch
konservieren kann. Er kann auch umgekehrt Text aus Textmarken in
Dialogfelder übernehmen, so daü der Dialog wiederholt aufgerufen
werden kann. Damit könnte man die Dokumentvorlage auch in Zukunft
beliebig anpassen, ohne in den VBA-Code eingreifen zu müssen. Das
Sekretariat, das zumindestens im Hinblick auf Word deutlich kompe-
tenter als die übrigen Nutzer ist, wäre durchaus in der Lage,
Formatvorlagen, Rahmen etc. auch ohne meine Hilfe an neue
Bedürfnisse anzupassen.

Ich werde das erst am Montag weiterentwickeln können, da ich die
Dateien nicht zu Hause habe.

CU
--
Lars P. Wolschner lars.wolschner@nexgo.de
Bernardstraüe 11b lars.wolschner@gmx.de
D-63067 Offenbach am Main
Fon & Fax: +49 69 80068670 Mobil: +49 163 8122462 (eplus)

Shared Memory Support in DLL applikationsübergreifend möglich?

Guten Tag!

Da ich in der Suche zu "Shared Segment Data" auf diesen Beitrag von Dir gestoüen bin, Christian, und ich heute vor genau diesem Problem stehe, wie ein gemeinsames Datensegment in einer DLL von verschiedenen Anwendungen genutzt werden kann (öbergabe von Daten von einer Anwendung an eine Andere), will ich meine Frage hier anfügen.

In der mir vorliegenden Ausgabe des Buches "C++Builder6 Developer's Guide", ist im Kapitel 16 eine Möglichkeit beschrieben, die als gleichwertiger Ersatz für die entsprechende VC-Option genannt wird:

Statt

#pragma data_seg("-sdata")
int Num =0;
double dClose;
...
weitere "Inter-Applikationsvariable"
...
#pragma data_seg()
... "normale" DLL variable

wie der Befehlsblock in VC++ aussieht, wird im BCB6 die Unterstützung eines gemeinsamen Speicherbereiches durch eine eigene "Definition"-CPP-Datei im Buch beschreiben. Das sieht dann etwa so aus:

#pragma option -zRSHSEG
#pragma option -zTSHCLS
int Num = 0;
double dClose;
...
weitere "Inter-Applikationsvariable"
...

Selbstverständlich sind dann die entsprechenden Variablen in den Funktionsprogramm-Dateien der DLL über "extern" zu deklarieren.

Das Erstellen der DLL mit dieser eingebundenen Datei verlief fehlerfrei. Jedoch bei der Erzeugung der .DEF Datei fehlte bereits das dritte Element, das der SEGMENT-Liste.

So ist es wohl auch nicht überraschend, das die erhoffte Wirkung dieser Arbeit ausgeblieben ist.

Konkret: Ich arbeite mit einem Börsen-Chart-Programm (TradeStation), in dem die Möglichkeit besteht, mit der eingebauten Programiersprache "EasyLanguage", DLL-Funktionen aufzurufen und abzuarbeiten. Mit der von mir Erstellten DLL, die nach o.g. Schema die Erweiterung zur Unterstützung des gemeinsamen Speichers beinhaltet, sind alle gewünschten Operationen innerhalb der Applikation "TradeStation" wunschgemäü.

Jedoch ist beabsichtigt, die Daten des gemeinsamen Speicherbereichs, auch von EXCEL her abzurufen und/oder einzuschreiben, eben als "Inter-Applikationsdaten".

Das klappt leider nicht. Der Versuch, die DLL-Funktion über EXCEL-VBA auszuführen, verläuft zwar ohne Fehler. So wurde eine Variable in dem deklarierten Bereich der DLL mit einer DLL-Set-Funktion gesetzt und auch mit einer Get-Funktion wieder ausgelesen, doch der übergreifende Effekt bleibt versagt.

Innerhalb einer Instanz der MDI-Applikation EXCEL, ist der Datenaustausch möglich (in Mappe1 wird eine Variable in den DLL-"SHSEG"-Speicher eingeladen, die dann in einer Mappe2 wieder aus diesem Speicher ausgelesen wird).

Sobald jedoch eine weitere Instanz von EXCEL aufgerufen wird, in der ebenfalls auf diese DLL zugegriffen wird, liefert das Auslesen der "SHSEG"-Variablen den vorbesetzten Wert 0.

Nun hoffe ich, dass Du, Christian, oder ein andere Leser, einen Lösungshinweis mir geben kann. Wenn es hilfreich ist, kann ich gerne den Code der DLL mit den ensprechenden Grundfunktionen hier zur Auswertung bereitstellen.

Danke für das Lesen meiner Anfrage.

Gruü
Uw

Problem beim Importieren von Website Daten mittels QueryTable
  Hallo!

Ich versuche Daten von einer Website in Excel zu importieren. Tatsächlich handelt es sich um dynamisch aufgebaute Seiten die alle sehr ähnlich aufgebaut sind, und so brauche ich immer dieselben Tabellen dieser Seite:

Code:
Sub M1
i=1
While (i < 10)
        indexVal = Cells(i, 1).Value
       
        Call DeleteQueryTables

        Set qt = ActiveSheet.QueryTables.Add(Connection:="URL;https://www.testseite.de?val=" & indexVal & "", Destination:=Range("J1"))

        With qt
            .Name = "Test" & i
            .FieldNames = True
            .RowNumbers = False
            .FillAdjacentFormulas = False
            .PreserveFormatting = True
            .RefreshOnFileOpen = False
            .BackgroundQuery = True
            .TablesOnlyFromHTML = True
            .RefreshStyle = xlOverwriteCells
            .SavePassword = False
            .SaveData = True
            .AdjustColumnWidth = True
            .RefreshPeriod = 0
            .WebSelectionType = xlEntirePage
            .WebSelectionType = xlSpecifiedTables
            .WebTables = "2,3"
            .WebFormatting = xlWebFormattingNone
            .WebPreFormattedTextToColumns = True
            .WebConsecutiveDelimitersAsOne = True
            .WebSingleBlockTextImport = False
            .WebDisableDateRecognition = False
            .WebDisableRedirections = False
            .Refresh BackgroundQuery:=False

        End With

        i = i + 1

    Wend
End Sub

Sub DeleteQueryTables()
    For Each qt In ActiveSheet.QueryTables
        qt.Delete
    Next
End Sub Das Ganze klappt manchmal einige Male am Stück, manchmal wird aber auch schon beim zweiten mal eine Fehlermeldung ausgegeben:

Laufzeitfehler 1004: Auf die Datei konnte nicht zugegriffen werden.

Das seltsame dabei ist: Erfolgreich durchgeführte Abfragen klappen beim Versuch danach immer. Ich habe den Eindruck, dass VBA gar nicht so richtig abwartet bis die Webseite abgerufen wird. Es kommt mir so vor als würde Excel bei jedem erneutem Aufruf des Makros ein paar Seiten mehr laden.

Habe echt ewig rumgetan an dem Problem. Wüsste jemand einen Rat?

Vielen Dank!

Jan Peter Stotz schrieb:
Eric March schrieb:


Logisches Argument: Wenn ich nichts lade dann ist auch nichts zum Cachen
da, auüer dass sich Leerraum im Speicher findet (Zustand nach Reboot,
bis auf WIN + Autostart). Dann lade ich. Und ich lade mehr - und WIN
lagert aus wenn noch RAM frei ist??? Unlogisch.

Nein, das ist normal, Windows weist jedem Programm ein WorkingSet an
Speicherseiten zu. Dieses WorkingSet enthält die innerhalb eine bestimmten
Zeit benötigten Speicherseiten. Verwendet ein Programm mehr Speicher als in
sein WorkingSet hineingeht wächst das WorkingSet langsam mit. Nicht oder
nur sehr sehr selten verwendete Programmteile/Speicherseiten die nicht in
das WOrkingSet passen werden vorsorglich ausgelagert, aber nicht unbedingt
im Speicher freigegeben. Sie existieren also doppelt im Speicher wie in der
Auslagerungsadatei. Wird nun die Speicherseite wieder benötigt, ist sie
direkt da, wird hingegen der Speicher anderweitig benötigt (oder ist aus
Sicht von Windows da sinnvoller aufgehoben) muss der Inhalt nicht mehr
ausgelagert werden.

Nur so am Rande:
Ich erinnere mich an eine Modifikation für Eclipse (Java
Entwicklungsumgebung mit einem immensen Speicherhunger), bei dem das
Programm selber Einfluss auf seine WorkingSet-Gröüe genommen hat um ein
Auslagern zu verhindern.

Soll effektiv heiüen: Win lagert nach Gutsherrenart dennoch präventiv
aus - oder WIN legt nach Guthsherrenart ohne mich oder ein Tool zu fragn
Platz fest und wenn der nicht reicht wir der nicht erweitert sondern
peinlich Raum für andere Anwendungen freigehalten. Kann doch wohl nicht
wahr sein…

Also lade ich mal da RMA
voll (Video, was weiü ich), werfe das wieder raus. Was immer dann noch
in diesem Cachearsal steht - es ist Schrott der vielleicht auf Verdacht
nicht neu gelden werden müsste.
Aber mir will dich kein normaler Mensch vormachen, dass ein
reaktiviertes, erst recht so gecachtes, Programme eine wilde Auslagerung
auslöst (Mozilla müsste sich, live erst recht, darin finden!)?

Das Problem ist dass dein Hirn kein Computerinterface hat um Windows
mitzuteilen, welches Programm du als unverzichtbar deklarierst und welches
Programm Windows denn bitte auslagern darf. Solange du Windows nicht
Mitteilen kannst welches Programm wie behandelt werden soll, werden alle
Programme gleich behandelt, sprich irgendwann ausgelagert. Einzige
alternative wäre eine funktionsfähige Zeitmaschine, damit Windows nachsehen
(oder besser vorsehen) könnte welches Programm du wann in der Zukunft
benötigst.

Dann hat Mozilla aber was an sich immer der Pechvogel bei diesen
Aktionen zu sein…

Und ich
fände es hanebüchen wenn für einen Verdachtscache beendeter Progs bei
Aufruf neuer nicht dieser Cache geopfert wird sondern normale Programme
ausgelagert werden müssen! Das wäre doch Irrsinn im Quadrat!!
RAM ist belegt oder für den User da - alles andere geht in meinen Kopf
nicht rein. Egal was WIN meint im Hinterstübchen optimieren zu müssen:
meine zu ladenden Applikationen gehen vor!

Gut, stell dir vor Windows arebitet komplett anders und alle deine
Applikationen liegen vollständig im Speicher, damit auch ja nicht
ausgelagert werden muss. dadurch ist der Speicher aber voll. Nun surfst du
mit Mozilla auf eine Seite mit vielen Bildern, CSS-Code usw, so dass
Mozilla plötzlich 10 MB mehr Speicher benötigt. Windows fängt an
auszulagern, die Festplatte ackert und Mozilla stockt, bis endlich der
erforderliche Speicher da ist. Ich möchte nicht mitbekommen, was du in
diesem Fall dann über das Verhalten von Windows hier in der NG zu sagen
hättest...

Ganz einfach, dass ich eine Aktion auslöse und ein Programm
_innerhalb_seines_Ablaufs_ reagiert.

Wenn ich ein Prog das in der Taskliste ist reaktiviere ist immer Mozilla
wie ich schrieb der dumme. Offenbar wird es (und warum das so lange
dauert ist ein Mysterium für sich, der Neufaufruf geht wesentlich
schneller, auch ohne "-turbo") irgendwie in den Speicher
zuückmanipuliert. Zu wessen Nachteil wüsste ich nicht, Word, Excel, VBA,
Opera sind alle faktisch sofort wieder da, von Texteditoren nicht zu reden.

Wäre das RAM knallvoll - OK, dann sähe ich das alles ein. Da mir aber
keine 60% Nutzung gemeldet werden müssen 40% für irgendwas verwendet
sein die ich besser gebrauchen kann. Diese Irgendwas müssen sich doch
beeinflussen lassen. Oder wir ziehen das Fazit, dass XPs
Speicherverwaltung von vorgestern ist, selbsherrlich 1GB RAM will um dem
User praktische 512MB zur Verfügung zu stellen.

--
Eric March

ÂťSchreibe kurz - und sie werden es lesen. Schreibe klar und sie werden
es verstehen. Schreibe bildhaft - und sie werden es im Gedächtnis
behalten.ÂŤ Joseph Pulitzer