| |
| |
|
| - Seite 1 - |
|
 | Hi, ich will hier im Stammtisch einfach nochmal das kleine Thema FastMode und wProc ansprechen.
Wer mit XProfan viel programmiert stößt automatisch auf kleine subtile Unzulänglichkeiten welche aber IMHO garnicht sein müssten.
Oft ist es nur der Wunsch bei Fensterskalierung sofort reagieren zu können, oder nen Doppelklick richtig abzufangen, oder oder...
Am Ende sinds doch aber nur die Messages welcher hier richtig abfangbar sein müssten.
Ich hatte vor ein paar Monaten mal das Thema EventHandler angesprochen - ich stelle mir einfach vor das Roland eine Uni-Prozedur ermöglicht welche zuvor-definierte Events empfängt. Das schöne hierbei wäre das XProfan nicht mehr durcheinander kommt (wie es bei Callbacks der Fall sein kann (das leidige Thema)).
Also ich stelle mir ne Syntax vor wie:
KompilierenMarkierenSeparieren
Ich glaube das es auch garnicht schwer für Roland zu realisieren ist - und es würde eine Menge Probleme vom Tisch wischen!
Er müsste doch nur eine seiner WProcs veranlassen Daten durchzuschleifen... und erkönnte nicht nur mit OOP werben - sondern mit EventBased... |
|
| |
| |
| |
|
|
| |
| |
| - Seite 1 - |
|
Rolf
Koch | und wenn nicht, XPSE iF? 
Klar gibt ja die Event.dll, aber XPSE hab ich ja mittlerweile standardmässig drin. |
|
| |
| |
| |
|
|
| Den Hunni kriste später?!?  |
|
| |
| |
| |
|
|
| Mit XPSE wäre es möglich , der aber würde dann das Programm zum Fastmode umschreiben - und das wiederum würde nicht wirklich helfen wenn mein ProcAddr  -Problemverdacht sich bestätigt.
(aber ein riesen Aufwand wäre es schon *grml*) |
|
| |
| |
| |
|
|
Rolf
Koch | | *lol* und die anderen Beiträge a 100 bitte per vereinbartem Zahlziel |
|
| |
| |
| |
|
|
| [quote:79dedd6d31=Rolf Koch]*lol* und die anderen Beiträge a 100 bitte per vereinbartem Zahlziel [/quote:79dedd6d31]
Die Community ruiniert mich nach diesem Verfahren... |
|
| |
| |
| |
|
|
Rolf
Koch | | Ja stimmt auch wieder iF, also Roland DU MUSST |
|
| |
| |
| |
|
|
 | Wird er nicht!  |
|
| |
| |
| |
|
|
RGH | Rolf Koch
Ja stimmt auch wieder iF, also Roland DU MUSST
... aber bestimmt nicht mehr in XProfan 10! Und für XProfan 11 ließe sich daraus tatsächlich ein interessantes Feature gestalten.
Man kann aber doch schon jetzt mit UserMessages alle Messages abfangen: Eine UserMessage veranlaßt immer ein Verlassen des WaitInput. Mit UserMessages kann man das WaitInput also beliebig reaktionsfreudiger machen.
Und in manchen Fällen hilft auch schon die Verwendung des MessageMode 2.
Gruß
Roland
(muß sich manchmal zwingen, erst XProfan 10 richtig fertig zu machen, bevor er an XProfan 11 denkt) |
|
| |
| 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 | 10.09.2006 ▲ |
|
| |
|
|
Michael
Dell | | Da hat man doch (noch) was worauf man sich freuen! |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 10.09.2006 ▲ |
|
| |
|
|
Uwe
''Pascal''
Niemeier | Hallo Leute!
Hier ein Vorschlag, den ich schon Ende 2004 in RGHs Forum gemacht hatte; das geht doch auch in diese Richtung:
1. Erweiterung der Messageverwaltung (hatte ich vor einiger Zeit schonmal vorgeschlagen)
Es gibt ja eine Reihe von Controls (z.B. TreeView, ListView, Header, Rebar), die spezielle Notify-Messages verwenden, die man bisher nicht verarbeiten konnte. Mit den Möglichkeiten von XProfan geht das zwar im Prinzip, aber es hat sich ja gezeigt, dass Eingriffe in diverse WndProc- oder DlgProc-Routinen u.U. unerwartete Nebenwirkungen haben.
Alternative:
UserNotify Handle&, Bereich#, Message1& [, Message2&, ... MessageX& ]
Handle&: Das Handle des Controls, dessen Notify-Messages geprüft werden sollen
Bereich#: Der Bereich, in den die (meist erweiterte) NMHDR-Struktur kopiert wird, wenn eine
der vorgegebenen Messages empfangen wird. Für ausreichende Dimensionierung ist der Anwender
verantwortlich.
MessageX&: Die Notify-Messages, die ausgewertet werden sollen
Damit könnte man z.B. bei einem TreeView ohne allzu grosse Umstände auf TVN-Messages reagieren.
Alternativ könnte man statt des Handles auch die ID des Controls verwenden; dann könnte man mehrere Controls der gleichen Art gleichzeitig überwachen (das Handle wird normalerweise in der NMHDR-Struktur zurückgegeben).
SeeYou
Pascal |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
Nico
Madysa | Naja, ich habe schon mal ein wenig mit Usermessages herum experimentiert, allerdings waren die Ergebnisse nicht sonderlich...
Mein Hauptwunsch für das Messagehandling wäre, dass Waitinput auch auf Messages reagiert, die Kind-Controls von Kind-Controls bekommen (z.B. Radio-Buttons, die einer Groupbox untergeordnet sind, durchbrechen bei Draufklick z.Z. Waitinput noch nicht).
Was die On-Funktion angeht. TOP!!!  
Würde unter Anderem auch das Neuzeichnen in Dialogfenstern erleichtern. |
|
| |
| |
| |
|
|
| | So - ich habs einfach mal versucht! Es gibt jetzt eine On-Unit [...] - damit dürfte fast das alles hier möglich sein - nur eines mag mir nicht gelingen - das live-Anpassen bei Fensterskalierung. (Glaube weil Roland trotz gesetzter UMessage das Waitinput nicht beenden lässt) |
|
| |
| |
| |
|
(1.078)
Deutsch
English
Français
Español
Italia