| |
|
|
- Seite 1 - |
|
| Die Usermessages-Unit (Source ist open) ist für die Programmierung von anderen Units - welche Usermessages benötigen - Pflichtprogramm da es nicht möglich ist von Haus aus eine einzelne Usermessage zu entfernen.
Die Unit kann aber nur dann im Programm das gewünschte Ergebnis liefern wenn auch alle anderen Units - welche Usermessages benötigen - mit der Usermessage-Unit arbeiten und das eigentliche Programm ebenfalls für die Verwaltung von Usermessages ausschliesslich die Usermessages-Unit benutzt.
So ein Quark weil eine einzelne Usermessage nicht wieder entfernt werden kann, und weil man nicht prüfen kann ob eine Usermessage gesetzt ist.
Wenn ein XProfanprogramm eine Usermessage gesandt bekommt - egal ob von aussen oder innen - dann darf diese niemals verloren gehen da sonst hässliche Konstrukte nötig sind um sicherzustellen ob eine Message angekommen ist - oder nicht. (Beispiel für hässlicher Konstrukt: eine Schleife die auf einer anderen Message prüft ob wiederum eine Message vom eigentlichen Empfänger abgesandt wurde) |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
Jac de Lad |
Wo wir grad beim Löschen sind: Darf ich nochmal kurz DeleteListBoxItem nummer% in den Raum werfen? |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 05.12.2007 ▲ |
|
|
|
|
| Jac
Darf ich nochmal kurz DeleteListBoxItem nummer% in den Raum werfen?
Gern, in einem anderen Thread! ;)
@Roland: Jetzt fehlt eigentlich nur noch die Kleinigkeit das man festlegen kann welchen Antwortwert (long) der Sender vom XProfanprogramm zurückbekommt als Result von Sendmessage an eine Usermessage.
Einfaches beispiel: Wenn man möchte das die XProfan WProc auf die Message wm_activate mit false antwortet (was jetzt leider nicht möglich ist) dann sollte man KompilierenMarkierenSeparieren definieren können, oder nach jeder anderen Syntax wie z.B: KompilierenMarkierenSeparieren Dann wäre es tatsächlich zum ersten Male möglich festzulegen was die Antwort auf eine Message sein soll welche z.B. von einem Fremdprogramm abgesandt wird. (Kommunikation von Prozessen untereinander)
Das Usermessage-Thema wäre damit erschlagen und würde völlig neue tolle Möglichkeiten bieten welche sich letztendlich vereinfachend auswirken. |
|
|
| |
|
|
|
RGH | iF
Jetzt fehlt eigentlich nur noch die Kleinigkeit das man festlegen kann welchen Antwortwert (long) der Sender vom XProfanprogramm zurückbekommt als Result von Sendmessage an eine Usermessage.
Das hast Du natürlich recht. Das baue ich noch ein, wobei ich die zweite vorgeschlagene Syntax nutzen werde, da sie flexibler ist. Man kann leichter im Programmlauf die Antwortmeldung austauschen. Allerdings kürze ich den Funktionsnamen ein wenig: SetUAnswer(MsgNr%, Answer%). Ist MsgNr nicht vorhanden, gibt es eine Fehlermeldung.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 05.12.2007 ▲ |
|
|
|
|
Jac de Lad | Gut, dann zurück zum Thema UserMessages: Es werden immer noch einige nicht weitergegeben (z.B. wenn ein Fenster bewegt wird). Vielleicht ließe sich da noch was machen... |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 05.12.2007 ▲ |
|
|
|
|
Frank Abbing |
Allerdings kürze ich den Funktionsnamen ein wenig: SetUAnswer(MsgNr%, Answer%).
Ich schlage vor: Set(UMessageAnswer, MsgNr%, Answer%) |
|
|
| |
|
|
|
| Jau jau jau!
@Frank: Damit können wir auch das PSDK im Bezug auf die Kommunikation mit XIDE etwas abspecken!
@Jac: Das liegt wohl leider an etwas anderem...
<duck>jetzt fehlt eigentlich nur noch dass das XProfan die UserMessages erstmal "auffängt" und die aufgefangenen erst bei/mit "Waitinput" abbaut - sodass keine mehr verloren gehen. </duck> (@Frank: dann könnten wir auf das ping-pong der Messages verzichten und alles würde noch sauberer laufen...) |
|
|
| |
|
|
|
RGH | iF
jetzt fehlt eigentlich nur noch dass das XProfan die UserMessages erstmal auffängt und die aufgefangenen erst bei/mit Waitinput abbaut - sodass keine mehr verloren gehen.
Ok, ich habe meine Mittagspause für eine kleine, fixe MessageStack-Unit genutzt und diese eingebaut. Wenn Du heute abend (nach dem Eishockeyspiel der Adler) noch auf bist, kann ich Dir eine erste Version zum Testen schicken. An der Syntax hat sich nichts geändert.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 06.12.2007 ▲ |
|
|
|
|
| Jawohl gerne! Ich melde mich einfach per Schkeip wenn ich zu hause bin! |
|
|
| |
|
|
|
| Ich habe mich geirrt - da gibt es noch eine Kleinigkeit die meine Usermessages-Unit nötig macht - und zwar ist es sehr nötig das man eine neue freie UserMessage beziehen kann. XProfan sollte das vollständigkeitshalber intus haben. KompilierenMarkierenSeparieren
|
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
Nico Madysa | Hältst du das wirklich für wichtig? Ich denke, die Hand voll eigener UserMessages kann ein Programmierer sich auch merken; oder notfalls in einen Header schreiben. KompilierenMarkierenSeparieren |
|
|
| |
|
|
|
Frank Abbing | Denke nicht nur in so kleinen Bahnen, Nico. Mehrere Hundert Usermessage sind für ein Programm doch durchaus denkbar. |
|
|
| |
|
|
|
| @Nico: Und was wäre wenn z.B. eine Unit userMessages für sich registrieren möchte ohne vlt. vorhandene zu überschreiben? |
|
|
| |
|
|