Deutsch
Wünsche und Anregungen

Oberwunsch: Fensterskalierung

 
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.
 
10.01.2008  
 




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.
 
10.01.2008  
 




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)
 
10.01.2008  
 




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.
 
10.01.2008  
 




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.
 
10.01.2008  
 




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?
 
10.01.2008  
 




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) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
18.01.2008  
 




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  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

10.388 Betrachtungen

Unbenanntvor 0 min.
Peter Max Müller22.10.2017
E.T.02.01.2016
ByteAttack09.08.2015
Normann Strübli22.08.2014
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie