Verzögerungen beim Starten von Office-Programmen
Moderator: Moderatoren
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Verzögerungen beim Starten von Office-Programmen
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?
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?
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
Re: Verzögerungen beim Starten von Office-Programmen
Markus Walter hat geschrieben: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
- Foren-Administrator
- Beiträge: 16509
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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
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
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
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...)
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...)
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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.
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
- Foren-Administrator
- Beiträge: 16509
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Olaf,
Viele Grüße,
Martin
es ist wohl sinnvoll, wenn beide mal ihre Eventqueueverwaltung vergleichen! Ich denke hier im speziellen an den vierten Parameter von AppEvent().Lewi hat geschrieben:Windows stellt für jedes Anwendungsfenster einen eigenen Event-Queue bereit.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
Herzlich,
Tom
Tom
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16509
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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".
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
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.
@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.
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
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...
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...
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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
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
Herzlich,
Tom
Tom
-
- UDF-Programmierer
- Beiträge: 97
- Registriert: Mi, 01. Feb 2006 23:49
- Wohnort: Glauchau
- Kontaktdaten:
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
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
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
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?
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?
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz