Message-Spezialist gesucht für "echtes" modales Fenster/Control [Beispielscript]

Hi,
seit einiger Zeit hänge ich an folgendem Problem:
AutoIt-Script mit GUI ruft per MemoryFuncCall() ein eingebettetes Assemblerprogramm auf. Aus diesem Assemblerprogramm springe ich per Callback in eine AutoIt-Funktion _CB() und nach Abarbeitung einiger Berechnungen wieder zurück ins Assemblerprogramm. Das funktioniert einwandfrei.

Nun folgendes Problem:
Versuche ich, innerhalb der callback-Funktion _CB() das Programm "anzuhalten" (while 1 / wend), bekommt das Hauptfenster nach einigen Sekunden die Meldung "Keine Rückmeldung" . Das kann ich mit ersetzen der while/wend durch eine MsgBox() vermeiden. Das kommt wohl daher, dass die MsgBox() ein echtes modales Fenster ist, mit dementsprechendem Message-Handling.
In der GUI enthaltene Buttons kann ich natürlich per GuiRegisterMsg() auch während der Anzeige der Msgbox abfragen.

Frage:
Was muss ich machen um innerhalb der callback-Funktion ein Warteschleife (ohne Messagebox) zu realisieren ohne dass die GUI die "Keine Rückmeldung"-Message erhält?

Am liebsten wäre mir in der GUI ein "Weiter"-Button, der das angehaltene Script weiterlaufen lässt.
/EDIT/ habe mich schon mit subclasses beschäftigt, ohne da wirklich weiterzukommen. Ich vermute, dass durch die AutoIt/Assembler/callback-AutoIt-Kombination die Messages durcheinanderkommen, obwohl sie sich eigentlich im gleichen Thread(Adressraum) befinden.

Habe mal ein Beispielscript angehängt, einfach starten, so läuft es einwandfrei(32Bit).
Während der Anzeige der Messagebox kann auch der Button in der GUI angeklickt werden.

Wenn aber in der Callback-Funktion _CB() die while/wend einkommentiert wird, kommt nach einigen Sekunden Sanduhr die "keine Rückmeldung"-Msg in der GUI.

Hi,
vielen Dank, aber ich glaube, du hattest es etwas falsch verstanden^^
Ich benötige die Endlosschleife innerhalb der Funktion _CB(), gewissermassen an Stelle der Messagebox!
Die Messagebox hält das Script innerhalb der _CB() an, ohne dass es zu einer "Keine Rückmeldung"-Nachricht an die GUI kommt.
Die Messagebox soll nun durch eine Endlosschleife ersetzt werden, so dass es nicht zur "Keine Rückmeldung"-Nachricht an die GUI kommt.

Ich möchte ein "warte auf Mausklick auf den WEITER (in der MsgBox ist das der OK) -Button" realisieren.
Letztendlich soll in der _CB() eine Endlos-Schleife laufen, welche durch einen Klick auf den Button beendet wird. Per globalem Flag zum Beispiel.
Ein kleines Fensterchen, welche die Funktion der Messagebox übernimmt an der Position des Buttons würde mir auch schon reichen!

Ich habe schon eine dll erstellt, die aber nichts weiter als ein "echtes" modales Fenster (nur mit OK-Button) an der Position des "Weiter"-Buttons erstellt. Aber ich möchte diese dll nicht in den Code einbinden und daraus starten bzw. als externe Datei mitgeben, da sie im Vergleich zum restlichen AutoIt-Code immens gross ist....90kB um ein kleines Fensterchen mit einem OK-Button irgendwo auf eine GUI zu pinnen ist ziemlich happig!

Zitat

Ist aber wirklich seltsam, dass eine msgbox das Problem umgehen kann.

Nein, das ist garnicht seltsam, das hängt damit zusammen, dass MsgBox die API-Funktion DialogBox() aufruft, welche eine eigene Message loop installiert. Und die wiederum "fängt" sich die Messages.

Prog@ndy, vielen Dank, da habe ich ja was zu tun^^
Da der asm-Code Threadsicher ist, könnte ich ihn in eigene Threads verfrachten, mal schauen, was passiert.
Im Zweifelsfall mache ich doch eine "eingebettete" dll, das Problem von DialogBox() ist eigentlich nur, dass es die Fensterdaten aus den Ressourcen einer Datei ausliest. Eine asm-dll habe ich mittlerweile auf einige Bytes zusammengestampft, da die Ressourcen reingepackt und fertig wäre die Laube. Ich hatte schon das komplette Fenster als modale GUI getestet, das funktioniert auch, baut das Fenster aber in jedem Durchlauf "neu" auf, auch suboptimal....

Zitat

aber dafür musst du die ganzen Strukturen von Hand zusammenbasteln

hehe, da bin ich auch schon durch, da ist die dll mit den Ressourcen schneller und einfacher zu basteln.

Zitat

Oder du hängst di Dialog-Ressourcen an die AutoIt-Exe an, aber dann musst du immer erst kompilieren.

genau das wollte ich vermeiden, es geht um einen "Debugger" für den inline-asm-code (AssembleIt), der zur LAUFZEIT des Assemblercodes Daten an eine AutoIt-GUI ausgibt. Da ist permanentes kompilieren Kontraproduktiv imho.

Zzt. bin ich so weit, den kompletten "Debugger" (eigentlich ist es nur ein Anzeigefenster für alle Registerinhalte, Prozessorflags, FPU- und SSE-Registerinhalte, Inhalte des Stacks usw.) in Autoit in das AssembleIt-tool eingebunden zu haben. Nur das "weiterschalten" der GUI geschieht zzt. noch über das modale MsgBox-Fenster.

Aktueller Stand ist so, dass zwischen die einzelnen Assemblerbefehle ein _ASM_DEBUG() eingefügt werden kann, welches dann während der Laufzeit die GUI für die Anzeige der Daten aufruft. Weiterhin kann damit auch ein Abbruchbefehl z.B. in einer ASM-Schleife eingefügt werden. _ASM_DEBUG("eax<50") lässt dann den Assemblercode so lange laufen, bis das Register eax einen Wert kleiner 50 enthält. Also schon sehr komfortabel.

Ob man für "Weiter" nun auf den "OK"-button der MsgBox klickt oder auf einen Button innerhalb der GUI ist eher Kosmetik, aber du kennst das ja, für die 5% verbesserte Usability werden 95% Gehirnschmalz und Arbeit aufgewendet^^

Was soll ich sagen, ULTRACREMIG! Vielen Dank, funktioniert einwandfrei. Den Button hänge ich jetzt noch irgendwie an die GUI, damit er sich ggf. mitverschiebt, aber das sollte jetzt nicht mehr so wild werden!
Meine dll hab ich auf 96 Byte eingestampft, incl der Ressourcen natürlich^^, allerdings wird das wiederum aufgefressen von der Orgie, das Ding in den Speicher zu entpacken, dort zu starten, registrieren uswusf, in AutoIt nicht wirklich "schön"...

Dein Button macht das Rennen! Änderungen an Grösse, Style usw sind so auch einfacher nachvollziehbar wie Änderungen in einer geladenen dll....

habe mir angewöhnt, wenn möglich sowieso alle structs "am Stück" hintereinander in einen zusammenhängenden Speicherblock zu schreiben. Der wird dann einmal an einer 16-byte-Grenze aligned und dann kann man nach belieben damit arbeiten. Im Debugger sind das mittlerweile fast 2k an struct, Da kommts dann auf das bisschen 65 Bytes auch nicht mehr an