| |
|
|
| Hallo Roland,
seit Version 1 von [X]Profan[²] hat es ein dickes Manko wie ich zur Zeit höchstens noch von uralten Java(tm)-Anwendungen kenne: Programme können nicht auf Fensterskalierung reagieren während das Fenster skaliert wird.
User könnten fertige Programme als minderwertig einstufen - viele XProfaner nutzen deshalb Steife Fenster.
Es sollte möglich sein das dieser Code KompilierenMarkierenSeparieren den Inhalt nicht erst nach der Skalierung ausführt. Das Setzen einer entsprechenden UserMessage nutzt insofern nichts da die Messages WaitInput auch erst nach der Skalierung durchbrechen.
Bitte finde hierfür eine Lösung - thread.pcu oder subClassen von hWnd sind problematisch wegen dem ProcAddr-Problem, also nicht empfehlenswert. Waitinput durchbrechen bei wm_sizing als UserMessage wäre ausreichend. Ebenso ist festzustellen das wm_erasebkgnd als UserMessage auf hWnd Wunder bewirkt - bei gesetzter UserMessage flimmert hWnd nicht beim Skalieren. Ist vielleicht ne Brush-Sache - sollte aber mal angeschaut werden. |
|
|
| |
|
|
|
Jac de Lad | Dem schließe ich mich ohne Zögern an. Bisher ist das nur mit der Easyvent.dll möglich, die, aufgrund anderer Erweiterungen, immer überflüssiger wird. Wenn das mit dem Skalieren und auch mit dem Message_während_des_Verschiebens geht, bleiben eigentlich kaum Wünsche mehr in der Richtung offen.
Jac |
|
|
| 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 | 10.01.2008 ▲ |
|
|
|
|
| Jac
Dem schließe ich mich ohne Zögern an. Bisher ist das nur mit der Easyvent.dll möglich, Jac ...
Nein, ebenso mit der thread-unit und mit der onevent-unit und/oder mit inline-Asm und/oder jeder anderen Variante des subClassens eines Fensters. Problem hierbei ist das alle diese Varianten am proc-addr-Problem leiden - das Programm also potentiell gefährlich sein kann.
Roland könnte die procAddr-Aufrufe ebenso auf einen Stack packen wie er es jetzt mit den userMessages tut (was ich übrigens große Klasse finde!).
Dann wären easyVent.dll und onEvent-Unit und die thread-Unit im vollen Umfange 100% sicher nutzbar.
Oder Roland kommt für diese Problematik mit einer eigenen Lösung. |
|
|
| |
|
|
|
RGH | Das Problem ist, dass ich Windows bislang nicht dazu bewegen kann, das Waitinput zu verlassen, während man mit der Maus am Rahmen zieht. Selbst wenn ich in meiner Wuindowsprozedur auf wm_sizing reagiere und eine Variable setze, die sonst sofort zum Verlassen des WaitInput führt, klappt das hier nicht. (Wenn ich da testweise eine Bildschirmausgabe einbaue, wird diese tatsächlich sofort während der Größenveränderung durchgeführt.
Übrigens läßt sich die gleiche Problematik mit dem Timer zeigen: KompilierenMarkierenSeparieren Solange ich das Fenster vergrößere oder verkleinere, passiert nichts. Auch hier wäre es mir lieber, wenn der Timer durchkäme. Aber momentan habe ich keine Idee, wie das schmerzfrei ändern könnte. (Etwaige UserMessages gehen aber wegen des neuen Stacks trotzdem nicht verloren. Sie werden aber auch erste nach dem Loslassen des Fensterrahmens abgearbeitet.)
... aber vielleicht fällt mir ja noch was ein ... ;)
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 | 10.01.2008 ▲ |
|
|
|
|
|
Das Problem ist, dass ich Windows bislang nicht dazu bewegen kann, das Waitinput zu verlassen ... Wenn ich da testweise eine Bildschirmausgabe einbaue, wird diese tatsächlich sofort während der Größenveränderung durchgeführt.)
Dann Waitinput nicht verlassen - drinn bleiben. Wenn eine Bildschirmausgabe klappt dann könntest Du an dieser Stelle vielleicht auch eine Prozedur aufrufen event.wm_sizing(h,wparam,lparam) |
|
|
| |
|
|
|
Frank Abbing |
Nein, ebenso mit der thread-unit und mit der onevent-unit und/oder mit inline-Asm und/oder jeder anderen Variante des subClassens eines Fensters. Problem hierbei ist das alle diese Varianten am proc-addr-Problem leiden
Die Inline-Assembler-Methode krankt nicht daran.
Roland, du könntest alternativ bei WM_MOUSEMOVE/WM_NCMOUSEMOVE prüfen, ob sich die Fenstergröße verändert hat. |
|
|
| |
|
|
|
RGH | Frank Abbing
Roland, du könntest alternativ bei WM_MOUSEMOVE/WM_NCMOUSEMOVE prüfen, ob sich die Fenstergröße verändert hat.
Das hilft leider auch nicht. Wenn ich demnächst einen größeren Block Zeit finde, werde ich mich mal näher damit befassen, was Windows da anstellt und wie ich an die Kontrolle komme, während ich mit der Maus den Fensterrahmen zwecks Größenänderung erfaßt halte.
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 | 10.01.2008 ▲ |
|
|
|
|
| @Frank: Die inlineasm-Variante ist ebenso nutzlos wenn man die Controls per XProfan-Proc repositionieren möchte. PS: Dein Avatar passt irgendwie!
@Roland: SBM_GETSCROLLINFO ist hiervon ebenso betroffen - auch hier wäre es sehr sehr wichtig das WaitInput verlassen wird. |
|
|
| |
|
|
|
Frank Abbing | iF
@Frank: Die inlineasm-Variante ist ebenso nutzlos wenn man die Controls per XProfan-Proc repositionieren möchte. PS: Dein Avatar passt irgendwie!
Ja, aber wer macht das schon? Avatar paßt? Wozu denn? |
|
|
| |
|
|
|
RGH | So wird es in der nächsten experimentellen Subscriptionsversion gehen: KompilierenMarkierenSeparieren $H Messages.ph
SubClassProc
If SubClassMessage(%hWnd, ~wm_sizing)
SetStyle %hwnd, 1, GetStyle(%hwnd, 1) | $02000000 WS_EX_COMPOSITED
Resize
ElseIf SubClassMessage(bt&, ~wm_rbuttondown)
SetText bt&, Autsch!
ElseIf SubClassMessage(bt&, ~wm_rbuttonup)
SetText bt&, Test1
SetMenuItem 3000
ElseIf SubClassMessage(st&, ~wm_mousemove)
SetMenuItem 3001
ElseIf SubClassMessage(%hwnd, ~wm_close)
SetMenuItem 3999
EndIf
EndProc
Proc Resize
SetWindowPos bt& = 0, 50 - Width(%HWnd)/2, Height(%HWnd) - 75
SetWindowPos bt2& = Width(%HWnd)/2, 50 - Width(%HWnd)/2, Height(%HWnd) - 75
SetWindowPos st& = 0, 0 - 0,0; 0
SetWindowPos tb& = 0, 0 - 0,0; 0
EndProc
declare bt&, bt2&, st&, tb&
declare ende%
cls
st& = create(StatusWindow, %HWnd, Statuszeile)
tb& = create(Toolbar, %HWnd,0,15,1,1000,1)
bt& = create(Button, %HWnd, Test1, 0, 50, Width(%HWnd)/2, Height(%HWnd) - 75)
bt2& = create(Button, %HWnd, Test2, Width(%HWnd)/2, 50, Width(%HWnd)/2, Height(%HWnd) - 75)
SubClass %HWnd, 1 SubClassing des Hauptfensters einschalten
SubClass bt&, 1 SubClassing des 1. Buttons einschalten
SubClass st&, 1 SubClassing der Statuszeile einschalten
whilenot ende%
waitinput
If %Key = 4
Resize
SetStyle %hwnd, 1, GetStyle(%hwnd, 1) - $02000000
ElseIf MenuItem(3000)
MessageBox(Rechtsklick auf Button 1!,Test,0)
ElseIf MenuItem(3001)
MessageBox(Mausbewegung über Statuszeile!,Test,0)
ElseIf MenuItem(3999)
Case Messagebox(Wollen Sie das Programm wirklich verlassen?,Frage,36) = 6 : Ende% = 1
EndIf
endwhile
Subclassing wieder ausschalten
SubClass %HWnd, 0
SubClass bt&, 0
SubClass st&, 0
end
Hinweise: - Die Funktion SubClassMessage() macht nur in der SubClassProc Sinn. Wenn die Funktion wahr (1) ergibt, wird die Original Windowsprozedur für das entsprechende Fenster nicht mehr aufgerufen, ansonsten wird sie vor dem EndProc automatisch aufgerufen. (Will man eine Message behandeln und trotzdem die Originalroutine anschließend aufrufen, kann man statt SubClassMessage() eine Abfrage über %sWin uns %SMessage machen.) - Die SubClassProc läuft grundsätzlich im FastMode ab. - Die SubClassProc wird grundsätzlich im WaitInput aufgerufen und außerhalb des WaitInput ignoriert. - Das alte SetMenuItem N% kommt zu neuer Geltung: Damit wird das WaitInput verlassen und man kann über MenuItem(N%) nun tatsächlich auf alle Messages selbst reagieren. (Siehe Beispiel. Hier wird z.B. das übliche UserMessages 16 überflüssig, um das Beenden abzufangen.)
Wenn dieses Verfahren sich in meinen Tests als stabil erweist, könnte es Eingang in die endgültige Version 11 finden.
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 | 18.01.2008 ▲ |
|
|
|
|
| print J+mkstr$(a,&getTickCount) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
|
|
| |
|
|
|
Jörg Sellmeyer | Sieht sehr cool aus. Eine Frage habe ich aber noch: Im waitinput bedeuted wahrscheinlich, daß Du in Deiner WaitInput-Prozedur das Auslesen der Subclassmessages erledigst, oder? Ist das denn jetzt in jedem WaitInput so, nur auf das Hauptfenster bezogen, oder kann/soll/muß man das irgendwie ausschalten, wenn ich z.B. ein Dialogfenster mit eigener Schleife und WaitInput öffne? Gruß Jörg |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 18.01.2008 ▲ |
|
|
|