PureBoard

Verfasst: **05.08.2012 17:25**

ts-soft hat geschrieben:Okay, zur MessageBox. In früheren Versionen hat PB das hWnd nicht übergeben, sondern einfach nur 0. Das war verkehrt und ist
jetzt richtig, zumindest unter Windows.

Das ist genauso verkehrt wie zuvor, geht nur ins andere Extreme. Es sollte optional sein und wenn man einen modalen Dialog will, soll man gefälligst das Fenster angeben können zu dem der Dialog modal sein soll. Zu welchem Fenster ist es denn bitteschön aktuell modal?

__________________________________________________
Thread abgetrennt
Repaint (Flackern) bei Shift, ist das normal?>MessageRequester ParentWindow
Allgemein>Allgemein
06.08.2012
RSBasic

Verfasst: **05.08.2012 17:35**

Eine Messagebox ist immer Modal zum Hauptfenster, wie alle anderen Windows-Dialoge wie Speichern, Drucken usw. auch.
Eine Anwendung wird immer autom. deaktiviert, solange so ein Dialog geöffnet ist, alles andere macht ja auch keinen Sinn.

Optionales angeben zu was oder wem (Taskmodal, Systemodal usw.), ist nichts gebräuchliches, dafür kann man die API
nutzen, zu mal es sowas ja auch nicht unter jedem OS gibt.

Wenn so ein Dialog geöffnet wird, werden die Informationen für den weiteren Ablauf benötigt und es macht keinen Sinn,
wenn diese nicht Modal sind, ansonsten ist der Dialog fehl am platze.

Verfasst: **05.08.2012 19:28**

ts-soft hat geschrieben:Eine Messagebox ist immer Modal zum Hauptfenster, wie alle anderen Windows-Dialoge wie Speichern, Drucken usw. auch.
Eine Anwendung wird immer autom. deaktiviert, solange so ein Dialog geöffnet ist, alles andere macht ja auch keinen Sinn.

Optionales angeben zu was oder wem (Taskmodal, Systemodal usw.), ist nichts gebräuchliches, dafür kann man die API
nutzen, zu mal es sowas ja auch nicht unter jedem OS gibt.

Was ist bei dir denn die Definition des Hauptfensters eines Programms? Ich glaube du verstehst nicht worauf ich hinaus will. Ein Programm kann mehrere Fenster haben die alle wiederum Dialoge hervorrufen können. Teilweise kann es dann unerwünscht sein, wenn ein unvorhersehbares Fenster blockiert und ein anderes nicht blockiert wird. Deshalb gibt es unter jedem "Windows, Icons, Menus, Pointer"-System die Möglichkeit anzugeben, welcher Dialog zu welchem Fenster (zumindest im selben Prozess) modal sein soll. Ich habe noch nie erlebt, dass es sowas nicht gab.

Verfasst: **05.08.2012 19:32**

DarkDragon hat geschrieben:Was ist bei dir denn die Definition des Hauptfensters eines Programms?

Das Fenster, welches die MsgBox aufruft.

Verfasst: **05.08.2012 19:42**

RSBasic hat geschrieben:
DarkDragon hat geschrieben:Was ist bei dir denn die Definition des Hauptfensters eines Programms?
Das Fenster, welches die MsgBox aufruft.

Ja, dann sag mir mal wo man beim MessageRequester das Fenster angeben kann. Woher soll denn der MessageRequester wissen, welches Fenster den Dialog aufgerufen hat, wenn man es ihm nicht übergeben kann? Das ganze spielt sich auf semantischer, evtl. sogar schon auf pragmatischer oder apobetischer Ebene ab. Da kann PB noch so viel Fensterraten, es wird das Hauptfenster nicht immer finden.

Verfasst: **05.08.2012 19:44**

Naja, das aktive Fenster halt.

Verfasst: **05.08.2012 19:45**

Genau, alle Fenster, bei denen bei der Erstellung keine ParentID mit angegeben wurde, sind Hauptfenster
und PB kann das auch problemlos feststellen

zu welchem Fenster die MessageBox gehört.
MessageBoxen sind immer blockierende Dialoge. Es besteht also im normalfalle kein Bedarf für diesen
Parameter, wobei ein optionaler parameter ja nicht schaden würde, aber für diese Spezialfälle gibt es ja
die API. Ist also IMHO mehr Ballast als nützlich.

Verfasst: **05.08.2012 19:51**

RSBasic hat geschrieben:Naja, das aktive Fenster halt.

Das ist aber keineswegs das richtige?! Wenn ich einen Dialog hab der im Hintergrund ist, weil er einen Download durchführt o.ä. (nur als Beispiel) und jetzt bricht die Verbindung ab, weshalb ich dem Nutzer das mitteilen will, dann soll er mir nicht das aktive Fenster sperren. Das wäre doch Blödsinn!

[EDIT]
Ey hallo? Wir haben doch nicht für die Ausrede bezahlt, dass man auf die API zurückgreifen kann.

Wenn ich sowas auf der Arbeit bringen würde, wäre ich schnell wieder entlassen. 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. Und sogar in GTK ist das nur ein zusätzlicher Parameter, genau wie unter Windows. Bei Cocoa und dem neuen wird es denke ich nicht viel anders sein.

Verfasst: **05.08.2012 19:57**

Ist aber so.
Beispiel 1:

Code: Alles auswählen

EnableExplicit

Define EventID

Procedure Window1()
  If OpenWindow(1,0,0,300,200,"ChildWindow",#PB_Window_SystemMenu|#PB_Window_WindowCentered)
    SetWindowState(1,#PB_Window_Minimize)
  EndIf
EndProcedure

Procedure Thread(z)
  Delay(1000)
  
  MessageRequester("", "Hallo Du.", 0)
EndProcedure

If OpenWindow(0,0,0,500,400,"Window",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
  Window1()
  CreateThread(@Thread(),0)
  
  Repeat
    EventID=WaitWindowEvent()
    If EventID = #PB_Event_CloseWindow
      End
    EndIf
  ForEver
EndIf

Beispiel 2:

Code: Alles auswählen

EnableExplicit

Define EventID

Procedure Window1()
  If OpenWindow(1,0,0,300,200,"ChildWindow",#PB_Window_SystemMenu|#PB_Window_WindowCentered)
    ;SetWindowState(1,#PB_Window_Minimize)
  EndIf
EndProcedure

Procedure Thread(z)
  Delay(1000)
  
  MessageRequester("", "Hallo Du.", 0)
EndProcedure

If OpenWindow(0,0,0,500,400,"Window",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
  Window1()
  CreateThread(@Thread(),0)
  
  Repeat
    EventID=WaitWindowEvent()
    If EventID = #PB_Event_CloseWindow
      End
    EndIf
  ForEver
EndIf

Verfasst: **05.08.2012 20:07**

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.

Was ist den mit den anderen Dialogen, Dateispeichern, Öffnen usw. die Arbeiten alle so.

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

PureBoard

MessageRequester ParentWindow

MessageRequester ParentWindow

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?

Re: Repaint (Flackern) bei Shift, ist das normal?