Minimalgröße eines Fensters festlegen

Jac de Lad · 22. April 2018, 10:42

Folgendes Problem:
Ich hab ein größenveränderbares Fenster. Das Fenster soll eine bestimmte Minimalgröße haben, also nicht kleiner gezogen werden können.Das ist bei etlichen Anwendungen Standard. Bei XProfan kenne ich jetzt nur die Möglichkeit die entsprechende Notification während eines WaitInput/GetMessage mittels Subclassing abzufangen und die Fenstergröße zu manipulieren. Das klappt wunderbar und flackerfrei. Wenn ich dem Programm aber etwas zu tun gebe, dann klappt das natürlich nicht. Ich behelfe mir momentan mit einem zweiten Prozess, das flackert aber und ist auch nicht elegant. Gibt es eine andere Möglichkeit das hinzubiegen, viellecht kann man die Minimalgröße des Fensterobjekts als Eigenschaft festlegen?

Nachtrag:
So wie ich das verstehe ist das Aufgabe der Funktion, die die Messages des Fensters verarbeitet, also müsste das direkt in XProfan integriert sein. Reagiert XProfan überhaupt auf Messages während das Programm normal weiterläuft?

H.Brill · 22. April 2018, 12:37

Mach es mal mittels UserMessage :

Quellcode

Declare Handle win, Long ende, xminsize, yminsize
xminsize = 400 : yminsize = 200
win = Create("Window", %DeskTop, "Mein Fenster", 100, 100, 600, 400)
ende = 0
UserMessages $0232 ' wm_ExitSizeMove
WhileNot ende
WaitInput
If %UMessage = $0232
If &UlParam = $0 ' size_move
Case Width(win, 1) < xminsize : SetWindowPos win = 100, 100 - xminsize, yminsize
Case Height(win, 1) < yminsize : SetWindowPos win = 100, 100 - xminsize, yminsize
EndIf
EndIf
Case %Key = 2 : ende = 1
EndWhile
End

Alles anzeigen

Was anderes wüßte ich jetzt auch nicht.

Jac de Lad · 22. April 2018, 13:28

Jaja, aber das bringt wie gesagt nur was in der Schleife. Bei anderen Programmen geht es auch jederzeit, auch wenn das Programm schwer beschäftigt ist.

ts-soft · 22. April 2018, 13:57

In XProfan sollte es mit einem Callback zu SetWindowsPlacement funktionieren. In der WINDOWPLACEMENT structure sollte der Flag: WPF_SETMINPOSITION gesetzt sein.

Weitere Infos auf MSDN:
msdn.microsoft.com/en-us/libra…op/ms633544(v=vs.85).aspx
msdn.microsoft.com/en-us/libra…op/ms632611(v=vs.85).aspx

Nach XProfan muß das aber einer von euch schon transferieren ;-)

In PureBasic gibt es die Funktion WindowsBounds() dafür, um Crossplattform-Funktionalität zu erreichen.

Jac de Lad · 22. April 2018, 14:15

Hm, danke, aber ich glaube das hilft nicht weiter. Die Funktion scheint nur das Minimieren etc. zu ermöglichen. Außerdem muss die Funktion ja auch extra aufgerufen werden, was mir nicht weiterhilft wenn mein Progrmm anderweitig beschäftigt ist.
WPF_SetMinPosition gibt auch eine Position an, nicht eine Größe.

ts-soft · 22. April 2018, 14:33

Jac de Lad schrieb:

WPF_SetMinPosition gibt auch eine Position an, nicht eine Größe.

Das ist ein Flag und gibt nichts an ;-)

Für die Größe ist der Member RECT in der Strukture zuständig. Ein Callback sollte bei eintreffen des entsprechenden Ereignisse automatisch aufgerufen werden, weiß allerdings nicht wie das in XProfan funktioniert. Deswegen programmiere ich ja auch nicht mehr in XProfan ;-)

PS: Wenn sich das Fenster verändern läßt, empfängt es auch Ereignisse, ansonsten wäre das Fenster Tot und zeigt keinerlei Veränderungen. Verstehe also das Problem nicht.

Jac de Lad · 22. April 2018, 14:50

Also entweder blick ich das gerade nicht, oder du liegst falsch.
Beschreibung von SetWindowPlacement:
Sets the show state and the restored, minimized, and maximized positions of the specified window.

Beschreibung von WPF_ASYNCWINDOWPLACEMENT:

If the calling thread and the thread that owns the window are attached to different input queues, the system posts the request to the thread that owns the window. This prevents the calling thread from blocking its execution while other threads process the request.

Die geben mir beide keinen Hinweis darauf, dass die Funktion per Callback arbeitet. ersteres sagt mir nur, dass ich damit das Fenster manipulieren kann, letzteres, dass damit der Aufruf an den Owner umgeleitet werden kann, falls der Thread eine andere Input Queue benutzt.

ts-soft · 22. April 2018, 15:12

Keine Ahnung wie XProfan tickt :-D

Es gibt doch z.B. WM_SIZE oder WM_MOVE ereignisse. Dort wird die minimale Größe abgefragt und bei unterschreiten als neu gesetzt. Wenn das XProfan-Programm zu beschäftigt ist, gibt es auch keine Änderung der Größe.

WPF_ASYNCWINDOWPLACEMENT sollte bei XProfan gar nicht funktionieren, da keine Threads unterstützt werden.

Ansonsten mal Roland fragen, ob er sowas einbauen kann oder entsprechenden Code programmieren.

Jac de Lad · 22. April 2018, 16:19

Wm_sizing und wm_size nutze ich ja schon. Bringt aber nur in einer waitinput Schleife was, ansonsten per Timer. Bleibt nur Roland. Vielleicht kann der einen Befehl "Set("WindowMin",handle,dx,dy)" einbauen.

RGH · 22. April 2018, 17:18

Das Verändern der Fenstergröße unterbricht doch schon immer das WAITINPUT und setzt %KEY auf 4!

Gruß
Roland

RGH · 22. April 2018, 17:45

Und hier ein kleines Beispielprogramm:

Quellcode

window 500, 500
declare int dx, dy
var int ende = 0
whilenot ende
waitinput
if %key = 27 // Escape-Taste
ende = 1
elseif %key = 2 // Schließen gewählt
ende = 1
elseif %key = 4 // Fenster ändert Größe
dx = width(%hwnd, 1)
case dx < 300 : dx = 300
dy = height(%hwnd, 1)
case dy < 300 : dy = 300
setwindowpos %hwnd, %winleft, %wintop - dx, dy
endif
endwhile
end

Alles anzeigen

Gruß
Roland

H.Brill · 22. April 2018, 18:23

RGH schrieb:

setwindowpos %hwnd, %winleft, %wintop - dx, dy

Müßte das nicht

Quellcode

setwindowpos %HWnd = %winleft, %wintop - dx, dy

heißen.

RGH · 22. April 2018, 18:36

Ja natürlich. Aber mit dem Komma anstelle des Gleichheitszeichen funktioniert es auch.

Gruß
Roland

Jac de Lad · 22. April 2018, 18:50

Leute, es geht mir um Veränderungen der Fenstergröße während das Programm NICHT im Waitinput hängt und irgendwas tut. Im Waitinput habe ich kein Problem damit, das läuft ja schon flackerfrei. Aber man kann die Fenstergröße natürlich auch ändern während das Programm beschäftigt ist. Dann kann ich nicht verhindern, dass das Fenster kleiner als z.B. 200*300 gezogen wird.

ts-soft · 22. April 2018, 19:06

Jac de Lad schrieb:

das Programm NICHT im Waitinput hängt

Ein Windows-Programm befindet sich solange im Event-Loop, bis es beendet wird. Es ist Ereignisgesteuert. Alles andere sind keine Windows-Programme und sollten dann auch als Batch-Programm deklariert werden und möglichst keine GUI haben.

Jac de Lad schrieb:

Aber man kann die Fenstergröße natürlich auch ändern während das Programm beschäftigt ist.

Ein Resizen des Fensters ist auch gar nicht möglich, ohne das ein Ereignis verarbeitet wird, es sagt ihm ja niemand: ändere Deine Größe, es kann also nicht in der Größe verändert werden.

Es könnte natürlich sein, das XProfan noch in anderen Routinen (RunTime?) die Ereignisse verarbeitet, so muß man sich hier einklinken. Wie das geht weiß ich leider nicht, dafür fehlen mir die Kenntnisse in XProfan. Aber ich denke eher, das der Programm-Ablauf hier verkehrt gewählt wurde.

Aber ich halte mich lieber raus und laß die XProfan Profis unter sich.

Volkmar · 22. April 2018, 19:20

Profan tickt da etwas anders, als normale Windowsprogramme. Die eigentliche Messageverarbeitung findet intern im Interpreter oder der Runtime statt und hat mit WaitInput wenig zu tun. Dorthin werden nur gezielt bestimmte Ereignisse "durchgereicht", damit ich überhaupt irgendwas machen kann :-D

Sogar das funktioniert und kann beliebig in der Größe verändert und natürlich auch per Klick auf das Schließfeld beendet werden:

Quellcode

cls
while 1
endwhile

Gruß Volkmar

H.Brill · 22. April 2018, 19:32

Was spräche denn gegen einen Dialog (Create("Dialog",...)
oder halt ein Fenster mit Dialogstil ?
Da kann der User die Größe nicht ändern und
das Problem tritt gar nicht erst auf.

RGH · 22. April 2018, 19:43

Zum Einen kann man dann gleich einen Windowsstil wählen, in dem die Fenstergröße nicht veränderbar ist und zum Anderen bleibt dann nur das Subclassing, dass ja vom Waitinput unabhängig ist. Dort kann man dann die Message zur Größenänderung abfangen und dafür sorgen, dass die Mindestgröße eingehalten wird.

Gruß
Roland

ts-soft · 22. April 2018, 19:44

Volkmar schrieb:

Die eigentliche Messageverarbeitung findet intern im Interpreter oder der Runtime statt und hat mit WaitInput wenig zu tun

So in etwa funktioniert auch "WaitWindowEvent()" bzw. "WindowEvent()" in PureBasic, was aber mehr ein Überbleisel aus älteren Versionen darstellt. Aber mit dem Befehl: "SetWindowCallback()" kann ich eine Procedure bestimmen, in der "alle" Ereignisse, ungefiltert eintreffen. Ich dachte eigentlich, das es diese Funktionalität inzwischen auch in XProfan gibt.

Edit: Lösung von RGH scheint das Problem doch zu lösen, SubClassing!