PureBoard

@ts-soft
Ja, ich weiß. Ich wollte nur rasch zeigen, was passiert, wenn das Fenster X (ob 1. oder 2. Fenster) im Vordergrund ist. Hab einfach bei mir irgendeine Vorlage genutzt.

ts-soft hat geschrieben:

DarkDragon hat geschrieben:Ich weiß nicht, wie ihr das verteitigen könnt, das ist ein zusätzlicher Parameter, der dem PB Team sogar die Arbeit wegnehmen würde das aktive Fenster zu suchen.

Mit anderen Worten, als Default sollte 0 sein? Das bringt ja die Einsteiger zu fehlern und gesucht werden muss da auch nicht.

Ja, standardmäßig sollte erstmal nichts modal sein. Erst wenn man ein Fenster angibt sollte es modal sein. Eventuell könnte man ja zusätzlich zum Fensterargument ein Flag angeben: #PB_ModalParent_AutoChoose, #PB_ModalParent_None, #PB_ModalParent_SeeParameter, damit man auch rückwärtskompatibel bleibt. Der Standardwert könnte dann auch #PB_ModalParent_AutoChoose sein damit es sich so wie jetzt verhält.

Auch die anderen Dialoge sollten dann demnach angepasst werden und auch erstellte Fenster sollten Modal zu anderen sein können.

ts-soft hat geschrieben:PS: Ich weiß ja nicht, was RSBasic mit seinem Beispiel beweisen möchte, aber blockierende Dialoge dürfen nur in dem Thread
erstellt werden, in dem das zugehörige Fenster erstellt wurde. So ist das Beispiel die genau falsche Anwendung eines
modalen Dialoges

Ja, das dachte ich auch, aber es demonstriert wie PB funktioniert und das ist schon behämmert so wie es ist.

DarkDragon hat geschrieben:und auch erstellte Fenster sollten Modal zu anderen sein können.

Können Sie doch
ParentID und EnableWindows, alles benötigte ist doch dabei.

Um mal kurz auf das Beispiel in RSBasics Post zurück zu kommen. Unter Linux werden die beiden Fenster erstellt und dann kommt "Das mit dem Debugger getestete Executable endete unerwartet.". Mache ich den Thread weg, gibt es keine Probleme. Ist das nun ein Bug?`

@ NicTheQuick
Vergiss bitte, was für Beispiele ich dort oben gepostet habe.

Versuch es damit: Einmal mit SetWindowState(1,#PB_Window_Minimize) und ohne testen.
Sollte aber nur zeigen, was passiert, wenn 1. oder 2. Fenster im Vordergrund ist, bevor die MsgBox erscheint. Du musst dann auf das entsprechende Fenster anklicken, um zu sehen, ob die MsgBox aufblinkt. Hat aber direkt nichts mit dem besprochenden Bug zu tun.

@RSBasic: Es fehlt immer noch das Flag "#PB_Window_MinimizeGadget", sonst wird bei mir gar nichts minimiert. Und ich hab auch immer noch nicht den Unterschied verstanden mit und ohne das "SetWindowState(...)". Beide male kommt ein MessageRequester und zeigt mir was und ich kann die beiden Fenster nicht schließen bevor ich auf "OK" drücke, was ja Sinn macht, weil ich bis dahin noch gar nicht im Event-Loop bin. Das minimierte Fenster kann ich zwar wiederherstellen, aber auch solange nicht erneut minimieren, bis ich auf "OK" gedrückt habe. Verschieben der Fenster ist kein Problem.
Ich glaub ich hab nicht ganz kapiert, was hier zu testen ist. ^^

@NicTheQuick
Ups ja stimmt, funktioniert bei mir aber auch ohne Minimize-Flag.

Bezüglich deiner Verständnisfrage: Das extra Thema ging ab hier los: http://www.purebasic.fr/german/viewtopi ... 02#p304102
Die Frage lautete, warum die MsgBox standardmäßig modal zum aktiven Fenster wird, welches sich im Vordergrund befindet. D.h. du musst die MsgBox erst wegklicken und erst dann kannst du das Fenster, welches noch aktiv war, weiterverwenden.
DargDragon hat sich dann gefragt, woher PB das ParentWindow nimmt, weil normalerweise so ist, dass die modal-Einstellung optional ist. (Z.B. bei WinAPI)
Daraufhin wollte ich mit Hilfe meiner Beispielcodes den Unterschied zeigen, dass er das derzeit aktive Fenster, welches sich im Vordergrund befindet, als ParentWindow nimmt. (MsgBox-Titelleiste blinkt dann dreimal, wenn man auf das ParentWindow klickt.)

RSBasic hat geschrieben:@NicTheQuick
Ups ja stimmt, funktioniert bei mir aber auch ohne Minimize-Flag.

Blöd, dass das von OS zu OS so unterschiedlich ist. Ich finde es bei mir dann aber logischer.

(MsgBox-Titelleiste blinkt dann dreimal, wenn man auf das ParentWindow klickt.)

Blinken tut hier gar nichts. Wieder ein Unterschied.

@RSBasic,

nee, das Thema ging ganz oben los, da war von Requestern ÜBERHAUPT keine
Rede. Sondern, "Warum flackert das ganze Fenster, wenn ich mit der Shift (Strg, Alt ...)-Taste
in einem Stringgadget eine Eingabe mache". Man sollte die Themen nicht immer
zu Multi-Themen werden lassen.

@3BO,

richtig, bei 4.51 passiert nüscht, bei 4.60 auch noch nicht, erst ab 4.61

Gruß Jens

@sharkpeter
Sag es nicht mir, ich habe damit nicht angefangen.