HWND nach mehrmaligem Aufruf plötzlich NULL

DocShoe

Mal was ganz Anderes:
Was genau möchtest du eigentlich erreichen, was ist die Aufgabe deiner Anwendung? Lass so Sachen wie Dialog nach vorn bringen etc. mal weg und beschreib´ uns, was du funktional haben möchtest.

elmut19

@DocShoe

Zunächst: Das mit "_NOCHMAL1" oder "NOCHMAL2" war ohne Einfluss.
Habe auch meine copy/paste-Fehler gesehen. Danke.

Nun mein Vorhaben:
Mein Programm steuert mehrere Anlagen, die irgendwas verarbeiten.
Dazu wird eine Anlage mit Produkten beladen. An den Produkten kleben bis zu n Etiketten, die hierzu erfasst werden sollen.
Es können auch n-x Etiketten sein.

Nun will ein Kunde die Etiketten sowie die zugehörige Anlage, die den Verarbeitungsprozess durchführt, über die gerade gesammelten Daten auch starten.
Das soll verhindern, dass man plötzlich nicht mehr weiss, an welcher Anlage man gerade war.
Mein Steuer-Programm erkennt somit auch gleich die Anlage und öffnet den Start-Dialog, der die Daten empfängt und nach einem Plausi-Test noch eine Übersichtsliste der gesammelten Daten zeigt.
Danach kann dann die schon vorgewählte Anlage gestartet werden.

Der Scanner arbeitet im Batchbetrieb, damit die Daten auch in 20m Entfernung gesammelt werden können.
Am PC werden sie dann auf einen Rutsch übertragen.

Klar. Ich fände es auch wesentlich angenehmer, wenn die Leute den Dialog selbst öffnen würden/müssten.
Dabei funktioniert ja auch alles. Und man wüsste auch, dass das Eingabefeld den Fokus hat, und, und ...
Es läge auch in der Verantwortung des Bedieners.

Aber nun kommen dann immer wieder so lästige Anforderungen ....
Auch von meinem Boss.
Und am Besten wäre es, wenn man gar nicht mehr auf den Bildschirm schauen müsste.

Und solche Anforderungen ziehen dann automatisch andere nach sich.
So kann ich ab dieser Anforderung schon nicht mehr sicher sein, ob die Anwendung, die ich bedienen will, auch selbst den Fokus besitzt.
Es würden also die erfassten Daten ev. ins Leere laufen.

Und somit komme ich auf den riesigen Aufwand, nur um sich einen Klick auf einen Button zu ersparen.

DocShoe

Mal sehen, ob ich das richtig verstanden habe:

Es gibt eine Software von euch, die von einem Barcodeleser Etikettendaten liest
Es gibt eine zweite Software, über die Anlagen gestartet werden können. Diese Software möchtet ihr mit eurer Software fernsteuern (programmgesteuert einen Dialog öffnen, einen Etikettentext in ein Texteingabefeld eintragen und dann einen Button klicken)

Stimmt das so in etwa?

elmut19

@DocShoe
Es ist alles in eine Software integriert.
Aber ja, es läuft auf Fernsteuerung durch den Barcode-Scanner raus.

Ich habe die Software durch einen "HookDll" ergänzt.
Und in "MainFrm" ist die Empfänger-Methode für den Hook integriert.
Diese filtert dann die einzelnen Zeichen raus, die eindeutig vom Scanner stammen.
Das ist allerdings auch ein Sch....
... Und hat auch noch ein paar Macken.
Diese Methode erkennt vom Scanner das eingestellte Startzeichen.
Dann gehe ich davon aus, dass alle Scanner-Zeichen sehr schnell hintereinander kommen.
Über einen Timeout, währenddessen sich nichts mehr am übertragenen String ändert,
gehe ich davon aus, dass ich alle Daten vom Scanner angekommen sind.
Dann setze ich ein Flag für meinen Thread, der die Daten übernimmt und entweder den Dialog
damit aufruft oder, wenn der Dialog schon da ist (und einen Plausifehler oder fehlende Daten meldet),
die weiteren Daten direkt ins Edit-Ctrl schreibt.

... Ob dieser Automatisierungsgrad in der Praxis auch praktikabel ist oder eher mehr Ärger bringt als Vorteile, kann man wohl erst am Beispiel sehen.
Ich sehe jedenfalls mehr Ärger!
Aber sag das mal ohne Beweis.

DocShoe

Wenn alles in einer Software integriert ist kannst du dir doch das Fensterhandle des Dialogs merken, oder nicht? Warum dann das Geraffel über Set/GetForeground Window?

elmut19

@DocShoe
Kann ich denn sicher gehen, dass der Dialog, sowie sein Edit-Ctrl immer denselben Handle bekommen?
Bei jedem neuen Aufruf?
Der Dialog verschwindet schlisslich immer wieder!

DocShoe

Na und? Dann setzt du beim Erzeugen des Dialogs das Handle halt neu. Und beim Schließen löschst du´s halt wieder, musst nur drauf achten, dass das threadsicher verriegelt wird.

DocShoe

Ähm, was mir gerade auffällt....
Wenn das alles in einer Software passiert... warum dann der umständliche Weg über die GUI? Beim Drücken auf den Start Button werden Parameter aus der GUI ausgelesen und iwie an die Anlage geschickt. Kann das nicht der Thread alles selbst erledigen, ohne den Umweg über die GUI zu gehen?

elmut19

@DocShoe
Das habe ich mir auch schon alles überlegt.
Aber wie gebe ich dann Fehlermeldungen aus?
Wenn z.B. einmal weniger Etiketten gescannt werden sollen, als für die Anlage vorgegeben?
Das kommt öfter mal vor. Und das soll dann bestätigt werden können.
Also brauche ich irgend einen Dialog.
Und mein Thread hat keine GUI.

Aber inzwischen denke ich, dass es doch manchmal Probleme mit den aufeinanderfolgenden "Set/GetForeground" geben könnte.
Ich bekomme gerade für den Dialog den selben Handle, wie für meine App.

Aber warum geht/ging das öfters gut?

Ich müsste den Dialog besser über seine ID suchen und darüber seinen Handle ermitteln.
Aber wie? Habe da nix gefunden.

Dieses "FindWindow(..)" verlangt ja blöderweise immer nach dem Fenster-Titel!
Der ändert sich aber immer bei mir (andere Sprachen).

Und 40 Minuten später...
Nun habe ich mir überlegt, dass ich den Dialog seinen Handle selbst ermitteln lasse.
Das kommt dann in eine globale Var.
Die ersten Tests sind schon mal positiv.

elmut19

@DocShoe sagte in HWND nach mehrmaligem Aufruf plötzlich NULL:

::SetForegroundWindow(g_hwndMain);
g_hwndBcStart = ::GetForegroundWindow();
Das verstehe ich nicht. Warum setzt du erst das Vordergrundfenster um dann das Handle des Vordergrundfensters per GetForegroundWindows zu holen? Kannst du nicht direkt über g_hwndMain drauf zugreifen? Welches Handle erwartest du denn bei dem Aufruf von GetForegroundWindows? Und wer erzeugt das Fenster? Kannst du dir das Handle beim Erzeugen nicht merken und damit arbeiten?

Tja, das war´s wohl.
Ich habe da mit meiner Version wohl ein zeitliches Fehlverhalten ausgelöst, das fälschlicherweise eine für mich teilweise funktionierende Version erzeugt hatte.
Das hat sich dann, durch Deinen Hinweis, ein Sleep() einzubauen, bewiesen.
Es ging dann gar nicht mehr.

Wie oben gesagt, lasse ich mir nun den Handle vom Dialog selbst setzen, auf den ich dann, wenn der Dialog steht wieder zugreifen kann.
Es funktioniert nu schon eine ganze Weile.

Danke DocShoe!!!

Martin Richter

@elmut19 sagte in HWND nach mehrmaligem Aufruf plötzlich NULL:

WM_KILLFOCUS

Mal Grunsätzlich. WM_KILLFOCUS wird nur als Notification von Windows versendet.
Man sollte es niemals selbst versenden...
Dazu gibt es SetFocus!