Programm erscheint nicht am Desktop, ist aber im Taskmanager

[Günter Preißer]

Hallo allerseits,

ich habe ein komisches Problem mit einer kleinen Gui-Anwendung (V. 1.90 355) nachdem ich sie auf List & Label umgestellt habe.
Nun zum Problem: die Applikation liegt mit der Exe-Datei, den Dlls und den Daten in einem Ordner auf einen Windows
2008 Server mit 64 Bit. Rufe ich nun das Programm wie früher über eine Verknüpfung an einen XP-Arbeitsplatz auf, dann
erscheint das Programm nicht am Desktop, man sieht es jedoch im Taskmanager der Workstation.
Melde ich mich aber am Server, der auch als WTS fungiert mit Remote-Desktop an und starte dann die Applikation, dann
erscheint das Programm korrekt und alles funktioniert.
Geändert habe ich im Programm eine Kleinigkeit: nach dem Aufruf
oDlg:show() habe ich noch eingefügt
SetAppWindow( oDlg )
SetAppFocus( oDlg )
weil sonst das Druckfenster von List & Label nicht den Fokus bekam und somit vom Programm verdeckt wurde.

Vielleicht kein einer von Euch dieses Phänomen und kann mir helfen

Viele Grüße
Günter

[Tom]

Hallo, Günter.

Z.B. in LlPrintStart() (aber auch in LlDefineLayout oder LlPreviewDisplayEx usw.) übermittelst Du das Handle des Owner-Fensters an L&L. Hier übergibst Du entweder nichts oder Unsinn. Der AppDeskTop() sollte nicht der Owner für L&L sein!

Also: LlPreviewDisplayEx(nJobHandle,cFormName,cPreviewPath,oOwner:GetHwnd(), ... Optionen)

"oOwner" sollte ein sichtbarer Xbase++-Dialog sein! Und nicht AppDeskTop()!

[Günter Preißer]

Hallo Tom,

vielen Dank für Deine Antwort. Du hast recht, ich übergebe als "Owner" derzeit das "SetAppWindow(), das werde ich so schnell wie möglich ändern.
Allerdings verstehe ich nicht, warum sich die Applikation, wenn ich sie lokal lege oder mich am WTS anmelde und dann starte, korrekt am Desktop zeigt, beim Aufruf über eine Verküpfung von einem Arbeitsplatz jedoch nur im Taskmanager zu sehen ist.

Hast Du dafür auch eine Erklärung?

Viele Grüße
Günter

[Tom]

Hallo, Günter.

Mmh. Die App ist gestartet, zeigt aber noch kein Fenster an. Das heißt, sie hängt vorher irgendwo, wartet auf etwas, versucht, eine Tabelle zu sperren oder ähnliches. Möglicherweise greift sie auf falsche DLLs zu (Arbeitsverzeichnis?). Für solche Fälle, die zuweilen auch dadurch auftreten können, dass irgendwas im System verhaspelt ist ("Fremdeinwirkung"), gibt es bei mir den "Servicemodus": Wenn die App mit einem bestimmten Parameter gestartet wird, schreibt sie vor dem Entstehen des Hauptfensters jeden wichtigen Schritt in eine Log-Datei, die auch sofort - also nach jedem Schritt - weggespeichert wird. In dieser Datei kann man dann sehen, wo es gerade hakt. Möglich ist auch etwas so Absurdes wie das Folgende: Du merkst Dir irgendwo (XPF? INI? XML?) die Größe und Position des Hauptfensters und versuchst, es beim abermaligen Start genau dort wieder anzuzeigen. Durch veränderte Bildschirmeinstellungen aber liegt dieser Bereich nicht im sichtbaren Bereich. Und so weiter.

Ergänzende Erklärung: Im Taskmanager als Anwendung erscheint eine Applikation erst dann, wenn sie mindestens ein Fenster zeigt, das auch für die Taskbar aktiviert ist. Vorher ist sie ein "Prozess".

[Herbert]

Tom, deine Antworten gefallen mir. Durchdacht, technisch fundiert und passend. Danke =D>

Kleine Ergänzung noch:
Falls ein Fenster schon da ist, aber ausserhalb des sichtbaren Bereichs, dann musst du, Günter, prüfen, ob
die rechte obere Ecke des Fensters innerhalb AppdeskTop():CurrentSize() liegt. Wenn nicht, umplazieren.
Wir machen das bei allen Fenstern (speichern dabei die letzte durch den User gesetzte Position ab), da auch mal an ainem niedriger auflösenden Bildschirm gearbeiteet werden könnte.

[Günter Preißer]

Hallo Tom, hallo Herbert,

das "komische" an meinem Problem ist, daß wenn ich die Applikation vom Terminalserver aus starte, dann erscheint mein
Programm ganz normal am Bildschirm. Wenn ich jedoch über einen Link von einer Workstation aus das Programm starte, dann sehe ich die Software nur im Taskmanager. Baue ich testweise eine Meldung über msgbox() ein, so sehe ich diese
Meldung, mein Hauptfenster der XbpDialog() ist scheinbar aber nicht sichtbar. Wie Tom ja betont hat, gibt es keine Anzeige
am Desktop ohne ein Fenster.
Was ich einfach nicht verstehe ist,das unterschiedliche Verhalten des gleichen Programms bei 2 verschiedenen Aufrufmöglichkeiten.

@ Tom noch eine Frage nebenbei.
Ich habe Deinem Rat folgend als Owner "oDlg" von XbpDialog() an die L&L-Funktionen übergeben.
Jetzt verschwindet die Anwendung mit dem L&L-Druckfenster hinter einem beliebigen Fenster falls ein Fenster vorhanden ist. Als ich noch "SetAppWindow()" als Owner in den L&L-Funktionen hatte, war dieses Verhalten nicht da.

Viele Grüß u. vielen Dank
Günter

[Wolfgang Ciriack]

Schau mal nach, ob an der Station ein lokaler Drucker installiert ist, oder nur Netzwerkdrucker.
Es gab da mal m.E. ein Problem mit L&L, wenn kein lokaler Drucker installiert war.

[Günter Preißer]

Hallo Wolfgang,

danke für Deine Antwort. An der Workstation bei der die Software nicht am Desktop erscheint ist kein lokaler Drucker
installiert. Am Terminalserver allerdings ist auch kein lokaler Drucker installiert und doch funktioniert hier das Programm wie gewünscht. Der Unterschied beim Aufruf ist nur einmal Remote-Desktop und dann Aufruf am Terminalserver und
einmal Aufruf über einen Netzwerkarbeitsplatz durch eine Verküpfung auf die EXE-Datei am freigegebenen Server-LW.
Wenn ich das gesamte Programm-/Datenverzeichnis z.B. auf unseren hauseigenen Novell-Server lege, klappt der Programm- aufruf über eine Verküpfung wie erwartet. Der Unterschied scheint also der Windows 2008 R2 Server zu sein.

Viele Grüße
Günter

[Günter Preißer]

Hallo allerseits,

jetzt habe ich den Fehler für mein Anzeige-Problem gefunden. Es ist der Init-Aufruf von L&L 12.0 (ohne Patches):

LL12ModuleInit()
hJob := LLJobOpen(-1)
LlSetOptionString (hJob, LL_OPTIONSTR_LICENSINGINFO, cSN)

Wenn das Programm auf einem Windows 2008 Server 64 Bit liegt und nur über einen Link aufgerufen wird, dann erscheint
mein Hauptdialog nicht weil am Anfang des Programms die obigen Zeilen stehen.
Als Lösung habe ich das Programmverzeichnis auf die lokalen PCs gelegt, die Daten liegen weiterhin am Server und schon
funktioniert der L&L-Aufruf auch wieder.

@ Wolfgang Du warst mit Deinem Hinweis auf ein L&L-Problem sehr nahe dran - vielen Dank

Vielen Dank an alle und schöne Grüße
Günter

[Günter Preißer]

Hallo,

kann bitte jemand sagen wie ich mein Problem als "erledigt" markieren kann.

Gruß Günter

[Jan]

Günter,

Du gehst auf "Ändern" bei Deinem ersten Beitrag. Und änderst dann den Titel entsprechend.

Jan

[Tom]

Hallo, Günter.

Fängst Du in LL12ModuleInit() ab, ob die DLLs von L&L auch geladen werden konnten (also ob ein gültiges Handle entsteht)? Sind wirklich alle zu L&L gehörigen Dateien - nicht nur die DLLs - für die Applikation "sichtbar" gewesen ("Redistributierbare Dateien" unterhalb des L&L-Installationsverzeichnisses)? Dieser Code dürfte nämlich ansonsten keinen Hänger erzeugen, auch ohne Standarddrucker. Tatsächlich aber hat Wolfgang Recht; L&L macht Probleme, wenn keine Drucker installiert sind und/oder kein Standarddrucker erreichbar ist. Darauf sollte man achten. Das kann man aber mit etwas Code abfangen:

Code: Alles auswählen

FUNCTION PrinterExists()
LOCAL oPrinter, aPrinterList := {}
oPrinter := XbpPrinter():New()
oPrinter:Create('test')
aPrinterList := oPrinter:List()
IF Len(aPrinterList) = 0
  MsgBox('Keine Drucker installiert!')
usw.

[Günter Preißer]

Hallo Tom,

ich fange bis jetzt bezüglich der L&L-Init-Funktion nichts ab.
Es ist allerdings so, daß wenn ich das komplette Verzeichnis mit Programm, allen nötigen Dateien und den DBFs vom
Windows 2008 Server z.B. auf einen Novell-Server kopiere und dann per Verküpfung die Applikation starte dann ist der
"Hänger" auch nicht da. Ebenso ist der Fehler ja weg seit ich das komplette Programm auf den Workstations habe und nur noch die Daten im Netz liegen. Starte ich das Programm am Windows-Server nachdem ich mich per Remote-Desktop direkt
am Server angemeldet habe, gibt es auch kein Problem obwohl es das gleiche Verzeichnis ist.
Ich kann mir also nicht vorstellen, daß irgendein Modul nicht geladen werden, folglich muss das Aufruf- bzw. Ladeproblem
durch die Verknüpfung "F:\datenpfad\meinprog.exe" passieren. Sollte hier vielleicht der Laufwerksbuchstabe statt des
UNC-Pfades das Problem sein? Was meinst Du?
Ich werde den Aufruf mal auf UNC-Pfad-Angabe testweise umstellen.

Vielen Dank für Dein Code-Beispiel

Viele Grüße
Günter