Verzögerungen beim Starten von Office-Programmen

[Markus Walter]

Hallo,

ich höre immer wieder von meinen Anwendern, dass es, wenn meine Xbase-Anwendung läuft, zu Verzögerungen beim Starten von Office-Programmen (Word, Excel) kommt. Der Start von Word dauert dann sehr lange (nur der Start, das Arbeiten mit Word ist nicht beeinträchtigt...)
Das Ganze scheint etwas mit dem Event-Handling zu tun zu haben, wenn man nämlich in dieser "langen Startphase" von Word in meine Anwendung klickt (->Event), dann erscheint im Hintergrund sofort Word.
Also irgendwie scheint der in der Event-Schleife zu hängen und durch das Event vom reinklicken "erlöst" zu werden.
Die Event-Schleife(n) scheinen grundsätzlich okay zu sein (keine Prozessorlast) und der Effekt scheint auch nur in Verbindung mit MS Office zu sein. Ich habe z. B. OpenOffice installiert und kann da kein Problem feststellen.
Das Ganze passiert sowohl bei "normalen" Netzwerkstationen, als auch im TerminalModus und auch mit unterschiedlichen Office-Varianten (Office 2000, OfficeXP).
Ich verwende Xbase 1.82 im Hybrid-Modus und benutze Express. Das Problem besteht wohl generell (sowohl in der Event-Queue des Pulldown-Menüs, in GETs von Express und auch in "alten" @ x, x get-Eingaben).

Hat jemand von Euch sowas auch oder eine Idee woran das liegen kann?

[Jan]

Ich habe da keinerlei Probleme mit.

Bei mir liegt das etwas anders. Ich habe meine Taskleiste auf verschwinden gestellt, die kommt nur zum Vorschein wenn ich mit der Maus auf den unteren Rand gehe. Und sobald ich ein Xbase++-Programm gestartet habe (inkl. VX), dann kann ich mit der Maus machen was ich will, die Taskleiste kommt nicht zum Vorschein. Ich behelfe mir dann immer mit STRG + TAB. Nervig ist es aber trotzdem.

Passiert so unter Win 2000 Pro und XP

Jan

[dvdbommel]

Hallo, ...

Hat jemand von Euch sowas auch oder eine Idee woran das liegen kann?

genau das gleiche Problem kenne ich auch .... habe jedoch keine Lösung ... aber es NERVT SEHR !!!

Gruß

[Martin Altmann]

Hallo Markus und Frank,
vergleicht doch mal Eure Eventqueues - da muss es ja irgendwelche Gemeinsamkeiten geben, die an dem Verhalten Schuld sind!
Ich starte Word aus meiner Anwendung heraus (mit einem RunShell auf die zu öffnende RTF-Datei) und es geht genauso schnell, wie wenn ich Word per Doppelklick starte (auch wenn meine Anwendung nicht läuft).

Hallo Jan,
so einen Effekt hatte ich auch schon mal - habe aber nie wieder drauf geachtet und weiss auch nicht hundertprozentig, ob es bei mir eine XBase++-Anwendung war oder nicht...

Viele Grüße,
Martin

[Lewi]

Die Probleme mit xBasse in Zusammenhang mit MS-Office-Produkten kann ich nicht bestätigen.
Wir entwicklen mit 1.82 und u.a. der Jace-Bibliothek. Alle 3 Verfahren zum Aufruf von Office-Produkten laufen bei unseren Kunden ohne Probleme:

- runshell()
- über das Windows-API
- COM+/ActiveX mit Jace

Auch konnten wir keine Anomalien in Verbindung mit CITRIX-Sessions, Windows-Netzwerken oder NOVELL-Netzwerken feststellen.

Nach unseren Erfahrungen kann manchmal ein aktiver Virenscanner das System verlangsamen bzw. zu einem Fokus-Wechsel führen.

Gruß,Olaf

[Markus Walter]

Hallo,

nicht das wir uns falsch verstehen: Ich starte nicht Word aus der Xbase-Anwendung heraus, sondern der Anwender startet es manuell aus dem Windows-Menü oder der Desktop-Verknüpfung während meine Xbase-Anwendung läuft (respektive "idle" ist).

Was ich wundert ist, dass es sowohl in meiner "Haupt-Event-Queue" (Pull-Down-Menü) ist, aber eben auch im Readmodal() bei zeichenorientierten Masken (XbpCrt) und in reinen Gui-Dialogen (Express). Das sind ja schon mal 3 verschiedene Event-Queues...

Bei einem kleinen Testprogramm (reines Gui mit Express) scheint es nicht zu sein (blöde ist ja, dass ich es hier nicht testen kann...)

[Lewi]

Naja, aus meiner Sicht macht es keinen Unterschied, ob ein Programm eine Office-Anwendung aufruft oder der Anwender über den Desktop. In beiden Fällen ist die xBase-Anwendung im "idle"-Zustand (zumindest sollte sie es sein)

Wenn der Taskmanager für die xBase-Anwendung im Idle-Zustand keine Prozessorauslastung anzeigt, dann sollte es normalerweise keine Probleme geben. Windows stellt für jedes Anwendungsfenster einen eigenen Event-Queue bereit.

[Martin Altmann]

Hallo Olaf,

Windows stellt für jedes Anwendungsfenster einen eigenen Event-Queue bereit.

es ist wohl sinnvoll, wenn beide mal ihre Eventqueueverwaltung vergleichen! Ich denke hier im speziellen an den vierten Parameter von AppEvent().

Viele Grüße,
Martin

[Lewi]

Hi Martin,
inwieweit der 4. Parameter weiter helfen soll, vermag ich nicht zu beurteilen. Da er standardmäßig "0" ist, wartet die Anwendung so lange, bis ein Ereignis in der Warteschlange ist und reicht das Ereignis an das ensprechende Objekt weiter.

Mag sein, dass sich der EVENT-Queue im VIO-Modus etwas anders verhält. Aber damit habe ich unter xBase keinerlei Erfahrungen.

Gruß, Olaf

[Tom]

Wir haben dieses Fehlverhalten auch, und zwar bei allen Kunden und bei uns vor Ort (also nachstellbar). Wenn wir Office-Produkte direkt aus der Applikation aufrufen, ist alles in Ordnung, aber wenn man sie extern startet, während unsere Anwendung läuft, gibt es enorme Verzögerungen. Man kann das ein bißchen austricksen, indem man in der Taskleiste zwischen den Anwendungen hin- und herschaltet. Ganz schlimm wird es, wenn die Office-Anwendung nicht direkt, sondern indirekt über ein Dokument geöffnet wird. Das Problem haben wir seit der 1.8. Unsere Applikation ist ziemlich groß und wir setzen tonnenweise Drittprodukte ein, aber das muß an irgendwas Anderem liegen. Ich hatte das Memory-Management von Xbase im Verdacht, bisher.

[Tom]

@Markus: Machst Du was mit JazzAge?

[Lewi]

Hi Tom!
Wir haben beispielsweise eine 21MB große Anwendung (ohne xBase-DLL´s) bei einer Leasingfirma im Einsatz. Und, no Problems in Verbindung mit Office!

Gruß, Olaf

Nachtrag: Unsere eigene Klassenbibliothek (DLL) hat noch einmal 10 MB!

[Tom]

Hallo, Olaf.

Unsere Applikation ist etwa 110 MB groß (EXE/DLL), hinzu kommen Zusatzprodukte wie L&L 11, eXPress++, JazzAge, Marshallsoft, Flipper, TX TextControl und einige andere mehr. Und die Xbase-Runtimes natürlich. An ausführbarem Code liefern wir um die 200 MB aus, würde ich mal schätzen.

[Lewi]

Hi Tom

Wir programmieren ausschließlich objektorientiert (ca 99%) . Beim Klassen-Design haben wir Wert auf Wiederwendbarkeit und Skallierung gelegt. Das hat zur Folge, dass Datenbank-, Dialog- und tbowse-Objekte wir nicht jedes mal neu "durchcodieren" müssen. Das spart Zeit und Code.

Mal ne Frage: Wieviel Hauptspeicher fordert Eure Anwendung durchschnittlich an?

Gruß, Olaf

[Tom]

Wir arbeiten auf ähnliche Art. Die Anwendung nimmt sich um die 120 MB Hauptspeicher, aber die diesbezüglichen Aussagen der Windows-API sind leider nicht sehr verläßlich. Unsere kleinere Applikation, das hauseigene Warenwirtschaftssystem, arbeitet mit genau der gleichen Ausstattung (und auch multithreaded), ist aber dramatisch kleiner (etwa 30%) und erzeugt die Verzögerung mit Office-Paketen nicht. Das Phänomen tritt übrigens wirklich nur mit Office auf; Anwendungen wie CorelDraw, Dreamweaver usw. lassen sich problemlos starten.

[Martin Altmann]

Hallo Tom,
hast Du das mal mit dem RC2 nachgestellt? Wahrscheinlich nicht, da zu viele Drittprodukte dranhängen - aber interessant zu sehen wäre es ja schon, da ja mit 1.9 auch einiges am Memoryhandling geändert worden sein soll...

Viele Grüße,
Martin

[Lewi]

Dann liegt das Problem wohl mit der Größe der Speicheranforderung zusammen. Bei 120 MB Speicherauslastung für eine Anwendung muss XP wohl erst einmal reichlich Hauptspeicher für Office freischaufeln.

Wir haben Kunden, die ziemlich alte Rechner (800 Mhz) mit 256 MB Speicher und XP im Einsatz haben. Auf solchen Rechnern dauert der Start von Winword aus der Anwendung heraus auch "Ewigkeiten".

[Tom]

Hallo, Olaf.

Nein, das kann's nicht sein. Beim Start mit RunShell() oder ähnlichem funktioniert es ohne Verzögerung - die übrigens am größten ist, wenn man über Dokumente aufruft (Doppelklick auf eine DOC/XLS-Datei).

@Markus: Benutzt Du SET PATH/SET DEFAULT?

@Martin: Nee, habe ich mit der 1.9 noch nicht probiert.

[Lewi]

Tja Tom, dann bin ich mit meinem Latein auch am Ende. Zumal wir die Probleme nicht haben.

Gruß, Olaf

[Markus Walter]

Iss ja Wahnsinn, was heute alles in diesem Thread passiert... wow.

@Tom: kein Jazzage, kein "set path", kein "set default"

ich verwende:
- Xbase 1.82
- Express++
- List&Label 10
exe und meine eigene DLL sind zusammen ca. 16,5 MB, Speicherbedarf liegt (frisch gestartet) bei ca. 38 MB (also viel kleiner wie bei Euch )

Mit einem kleinen Testprogramm kann ich es auch nicht nachvollziehen (respektive einer meiner Mitarbeiter, da ich ja kein Office habe). Mit allen Programmen, die ich benutze OpenOffice, CorelDrw, Thunderbird und vieles mehr, kann ich das Problem nicht nachvollziehen. Es tritt wohl ausschließlich in der Verbindung mit MS Office auf.

@Tom: Ich kann bestätigen, dass das Starten direkt über eine .doc oder .xls-Datei noch deutlich länger dauert, als wenn man Word oder Excel selbst startet.
Es reicht wohl aber ein Klick in das Fenster des Xbase-Programmes und sofort erscheint im Hintergrund das gestartet Dokument in Word.

Ich lasse das Ganze mal mit einer Version testen, die mit 1.9RC2 gelinkt ist, testen.

[Markus Walter]

So, habe das jetzt auch mal mit 1.9RC2 getestet... Leider unverändert

Ich kann das Ganze jetzt auf einem TerminalServer (Win2000) testen, auf dem ist MS Office installiert.

Zunächst fällt mir auf, das ewig lange der Prozess "Excel" gar nicht im Task-Manager erscheint (nach dem Doppel-Click auf ein Excel-Dokument).
Wenn ich dann meine Xbase-Anwendung anklicke, erscheint das leere Excel-Programm-Fenster und bleibt auch wieder lange so stehen. Außer wenn ich die Maus über dem Xbase-Fenster bewege, dann erscheint im Excel sofort das Dokument...

Also Tom, die Hoffnung auf 1.9 ist in diesem Falle nicht gerechtfertigt...

Ich frage mal bei Alaska an, ob da was bekannt ist...

[Tom]

Hallo, Markus.

Schade.

Ich habe übrigens in der Alaska-Knowledgebase einen steinalten PDR (Version 1.3) zu diesem Thema gefunden, der zwar noch offen ist, sich aber augenscheinlich um CRT-Applikationen rankt:

http://www.alaska-software.com/scripts/ ... PDRID=3505

[rassekst]

Hallo Markus,

Ich habe auch solche Effekte.

XP, XBase 1.8

Bei mir tritt das sehr oft mit dem Acrobat auf. Ich denke es ist egal welches Programm gestartet wird. Das xBase Programm scheint eine gewisse Blockade auszuüben. In dieser Zeit ist keine grosse Auslastung oder änliches.
Ich habe mich schon dran gewönt. Kunden haben sich noch nicht beschwert.

Schöne Grüsse
Steffen

[Markus Walter]

Hallo Steffen,

bei AcrobatReader tritt in meiner Applikation definitiv nicht auf, weder auf meinem Rechner, auch nicht auf anderen Rechnern in unserem Büro. Bisher haben wir nur Probleme mit MS Office festgestellt.

[Markus Walter]

Hi an alle, die es angeht,

bei meiner Anwendung liegt es ganz offensichtlich am initialisieren von List&Label (sowohl LL-Version 8 als auch 10).

Nach Aufruf von LL10ModuleInit (bzw. LL8ModuleInit) tritt das Problem auf (und bleibt auch nach Aufruf von LL10ModuleExit bestehen. Solange diese Funktion nicht aufgerufen wird, tritt die Verzögerung nicht auf...

Übrigens ist nicht nur MS Office betroffen, sondern auch der WindowsExplorer (nicht jedoch der InternetExplorer).

@Tom: Kannst Du das mit LL mal gegenprüfen?
Ggf. könnten wir uns dann mal an den Combit-Support wenden.

@dvdbommel, rassekst: nutzt Ihr auch List&Label?

@rassekst: hast Du im AcrobatReader (welche Version?) vielleicht ein besonderes PlugIn installiert?