Lustiges Versehen. #PB_Window_SizeGadget mit ListIconGadget

[GlassJoe]

https://postimg.cc/LYxqtVLy

Ich weiss nicht so recht was ich dazu sagen soll

Ist das vielleicht nützlich ? Und viel weniger umständlich als ein MDI Gadget ?

Hat einer schon mal so'n versehen (ich war in Eile, und Müde ^^)

Code: Alles auswählen

ListIconGadget(#List,10,40,300,200,"Monk",170,#PB_Window_SystemMenu|#PB_Window_ScreenCentered|#PB_Window_SizeGadget)

wie ich da aussgeführt ?

[ST4242]

Hallo,

habe das eben mit einem Stringgadget probiert - auch hier geht es- allerdings war der Text nicht editierbar

Gruß

[GlassJoe]

Ich hab mal folgendes probiert.

Code: Alles auswählen

  EditorGadget(#funny,10,60,300,200,#PB_Window_SizeGadget|#PB_Window_ScreenCentered|#PB_Editor_ReadOnly)
  SetGadgetText(#funny,"blabla")

Damit hat mann ein schwebendes EditorGadget, daß sich wegen dem ReadOnly Flag gut als Sticker Gadget macht
Ohne ReadOnly gehts auch

[mk-soft]

Das macht hier keinen Sinn mit irgendwelchen Konstanten zu spielen.
Vor allem das es nur bei Windows etwas funktioniert und das nicht sicher mit allen dwStyles ...
Die Flags werden zu CreateWindow mit verknüpft und durchreicht ...

MSDN Link Window Styles https://docs.microsoft.com/en-us/window ... dow-styles
MSDN Link Edit Styles https://docs.microsoft.com/en-us/window ... rol-styles

Code: Alles auswählen

;-TOP

Enumeration Windows
  #Main
EndEnumeration

Enumeration Gadgets
  #Edit
EndEnumeration

Enumeration Status
  #StatusBar
EndEnumeration

Procedure Main()
  
  If OpenWindow(#Main, #PB_Ignore, #PB_Ignore, 800, 600, "Window" , #PB_Window_SystemMenu)
    ; StringGadget == Window EDIT control
    StringGadget(#Edit, 10, 10, 780, 25, "RightText", #ES_RIGHT) 
    Repeat
      Select WaitWindowEvent()
        Case #PB_Event_CloseWindow
          Break
      EndSelect
    ForEver
    
  EndIf
  
EndProcedure : Main()

[GlassJoe]

Ich weiss wie es richtig sein sollte nach 15 Jahren PB sollte ich sowas schon Wissen
Lustig & interessant ist trotzdem, was geht wenn mann etwas unorthodoxes tut

Vor allem seit PB so nervig geworden ist, wenn es um Fenster in Threads geht (alles nach 4.60 nervt da)
.........könnte jedes mal rein schlagen wenn der Debugger das meckern anfängt, nur weil es in Linux Probleme macht und in Windows nicht, soll mann dann auf total umständlichen Code mit Bind Event, Window Timer etc aussweichen
und muss seinen Fenster Code an einer total umständlichen Stelle ausführen.


Früher

Main Window -> Startet Window Thread A
Aus Windows Thread A kann ich (muss aber nicht) Window Thread B starten.
Aus Main Window kann ich Window Thread B ! starten, während Window A noch läuft.
Window A kann ohne Probleme direkt auf Änderungen durch Window B reagieren.

Nach PB 4.60

Debugger nervt ! Also nichts mehr mit Fenstern in Threads.

Main Window -> Startet Window A
Main Window reagiert auf nichts mehr, muss Window B Code in der Window A Event Schleife plazieren.
Window B ist ein weiterer Teil von Window A, reagiert aber auf keine Änderungen die in Window B sind, weil
ja kein Thread, nein ich soll erst mit irgendwelchen Bind Zeugs und Window Timern oder globalen Variablen herum arbeiten
um den Inhalt von Window A durch die Aktionen von Window B zu verändern, aber natürlich erst wenn Window B
geschlossen ist.

Wenn ich falsch liege klär mich Bitte auf, du hast 39384 x mehr Ahnung von PB als ich.

Also so wie ich das verstanden habe bringt das BindEvent in dem Fall sowieso nichts, sobald Window A läuft, kriegt doch MainWin nichts mehr mit, weil die Eventschleife steht, und das Bind Zeug nicht in einem Thread läuft (jedenfalls konnte ich in der Hilfe kein Beispiel mit Thread finden) und selbst wenn es das machen würde.

Ich kann BindGadgetEvent() doch erst benutzen wenn das Gadget erstellt ist.
Nur blöd das das Gadget um das es geht, in Window B ist, daß noch gar nicht existiert, und selbst wenn steht die
Window A Event Schleife nach Aufruf von Window B.

Ein Teufelskreis

[mk-soft]

Es ist eigentlich ganz einfach.

Es sollte IMMER nur eine Event Schleife geben und diese darf nicht geblockt werden.
Auch die mit BindEvent gebundene Events werden erst beim Aufruf vom WaitWindowEvent() im MainScope verarbeitet (1). Auch die mit PostEvent abgesetzten Event werden in den Event-Buffer hinzugefügt auch erst beim Aufruf von WaitWindowEvent() im MainScope verarbeitet (2). Somit liegen alle zu bearbeiteten Events Stabil und in richtiger Reihenfolge im MainScope.
Außerdem mag es Linux und macOS intern nicht, wenn die GUI von unterschiedlichen Threads bearbeitet wird. (Crash)
Bei Windows geht es meistens, führt aber machmal zu Synchronisation Problemen.

Um stabil aus Threads die GUI zu ändern, schau mal in meine Signatur 'ThreadToGUI"

(1) Mit BindEvent können mehr System-Event empfangen werde. Zum Beispiel bei #PB_Event_SizeWindow jede Änderung.
(2) Ein PostEvent kann auch aus dem MainScope abgesetzt werden. Zum Beispiel aus dem Menu ein Event #PB_Event_CloseWindow auszulösen.

[GlassJoe]

Danke für die Erklärung

Ich guck mir dein ThreadToGui gleich mal an