PureBoard

Verfasst: **10.03.2018 18:38**

Durch das SetGadgetText im Else-Strang, dass selbst wieder Events auslöst, gerätst
du in eine Endlosschleife, sodass die Zeichenvorgänge abgebrochen bzw. unvollständig
werden. Nimm also lieber Debug für irgendwelche Eventauswertungen.

Verfasst: **10.03.2018 18:49**

PureBasic hat da sein eigenes Eventsystem. Es werden die
wichtigsten Ereignisse, die man normalerweise braucht,
zur Verfügung gestellt. Die kann man über die Konstanten
(z.B. #PB_Event_CloseWindow usw.) oder über
#PB_Event_Gadget abfragen. Der Rest der Messages
in der Message-WarteSchlange wird intern abgearbeitet
oder an das OS weitergegeben.

Es dient halt auch der Einfachheit für den User. So ein
Klick z.B. besteht ja aus zwei Events :
zum einem aus einem MouseDown und zum zweiten aus
einem MouseUp. Wenn man jetzt auf einen Button klickt,
sieht man, daß der zugehörige Code erst beim Loslassen
des Buttons (MouseUp) ausgeführt wird.

Wenn man besondere Events oder Messages abfragen möchte,
muß man die Windows - API dafür nehmen.

Bei PB hätte ich mir bei diesem Thema mehr Funktionen
gewünscht. XProfan macht das zwar ähnlich, hat aber bei
diesem Thema weitaus mehr zu bieten. Das ganze
Messagesystem wirkt da viel transparenter.

Sowas ähnliches wünsche ich mir auch für PB.

Verfasst: **10.03.2018 22:26**

Bei Purebasic gibt es für Windows die Funktion "SetWindowCallback(@WinCallback())".
Die müsstest Du aber kennen...

Es kommen aber nicht alle Messages im Hauptfenster an, da Windows Teilweise diese nur direkt an die Controls "Gadgets" geschickt.
Dazu kann man aber wieder die Callback des Control über API auch wieder umleiten.

Ich finde schon das Purebasic es gut durchreicht.

Verfasst: **10.03.2018 23:19**

@H.Brill
Aus u.a. dem Grund, das XProfan mit Messages nicht richtig umgehen kann, hab ich es schlussendlich gelassen

Verschiedene Fensterstile, nicht unbedingt API-Stile, sorgen dafür, das ein Event erzeugt wird oder nicht. Viele Events, auch standard Events müssen in XProfan bekannt gemacht werden, damit sie durchgereicht werden. Der Befehl für eine "Event-Schleife" bestimmt welche Ereignisse überhaupt ankommen. Manche Fremdcontrols lassen sich in XProfan überhaupt nicht nutzen, da keine Events mehr ankommen, XProfan kennt diese eben nicht.

Wo XProfan da mehr zu bieten hat, verstehe ich also überhaupt nicht. Aber so hat jeder seine Vorlieben.

XProfan hat ja auch seine Vorteile, aber die liegen mit Sicherheit nicht im Messagesystem.

Verfasst: **11.03.2018 08:41**

mk-soft :
Eine Callback - Proc gibt es mittlerweile auch in XProfan.

ts-soft hat geschrieben:@H.Brill
Viele Events, auch standard Events müssen in XProfan bekannt gemacht werden, damit sie durchgereicht werden.
Der Befehl für eine "Event-Schleife" bestimmt welche Ereignisse überhaupt ankommen.

Das ist ja auch mit den USERMESSAGES kein Problem.
Zumindest hat man dann den Event in einer Systemvariablen,
wo man bei PB in der Hilfe vergeblich sucht. Erst versierte
Nutzer, wie du ts-soft, wissen dann, wie sie dann an diese
Events rankommen.

Was ich meinte, ist, daß es für den Laien in XProfan viel
leichter ist, bei den Messages bzw. Events durchzublicken.
Wenn man möchte, kann man die Messageverwaltung
auch selbst übernehmen, zumal man den Durchblick hat.

XProfan ist halt ein Interpreter. Andererseits hat so ein
Interpreter auch die Möglichkeit, verschiedene Systemvariablen
bereit zu stellen (z.B. %NotifyCode - %NotifyWnd - %wmNotify).

Diese Sachen machen es dann dem etwas fortgeschrittenen
Anwender doch erheblich leichter. Und in der Hilfe ist auch
einiges darüber zu lesen.

Für kleinere Programme und Tools nutze ich es immer noch
gerne. Aber das ist Ansichtssache und jeder sollte nach seiner
Vorstellung das für ihn richtige benutzen.

Verfasst: **11.03.2018 12:37**

Meine letzte Version von Profan is v7.6 und habe lange nichts mehr damit gemacht.
Fande ich aber nicht schlecht. Bin aber bei Purebasic gelandet, weil diese mehr Möglichkeiten hatte.

Das letzte wo ich Profan brauchte, als ich aus Windows 3.10 Daten exportieren musste. Da brauchte ich noch eine 16bit Windows Anwendung.
Die hatte ich noch mit Profan 4.5 geschrieben, da Purebasic keine 16bit Windows-Anwendungen erstellen konnte.

Die 32bit Erweiterung für Windows 3.10 wollte ich nicht extra installieren.

Meine letzte DOS-Anwendung hatte ich mit Pascal geschrieben und war für eine PC-XT mit 640 kByte Arbeitsspeicher.
War eine kleine Musik Datenbank mit bis zu 5000 Titel. Die lief nachher unter einen PC-286 wie die Hölle super schnell.
Da musste man die Fenstertechnik und sämtliche Tasten noch selber auswerten. Um Speicher zu sparen hatte ich den gesamten Speicher von der Grafikkarte verwendet um überlappende Fenster zu Verwalten. Irgend wo habe ich auch noch den Pascal Code...

Verfasst: **11.03.2018 13:01**

Zum Theme Gadget und Event.

Man kann sich auch ein Code - Baustein erstellen und immer wieder verwenden
Der Eventtype #PB_EventType_LeftClick kommt auch bei Buttons an, da dieser den Wert Null hat

Code: Alles auswählen

Procedure EventGadgetXXX()
  
  Select EventType()
    Case #PB_EventType_LeftClick        ; Klick mit der linken Maustaste
      ;TODO
    Case #PB_EventType_RightClick       ; Klick mit der rechten Maustaste
      ;TODO
    Case #PB_EventType_LeftDoubleClick  ; Doppelklick mit der linken Maustaste
      ;TODO
    Case #PB_EventType_RightDoubleClick ; Doppelklick mit der rechten Maustaste
      ;TODO
    Case #PB_EventType_Focus            ; Fokus erhalten
      ;TODO
    Case #PB_EventType_LostFocus        ; Fokus verloren
      ;TODO
    Case #PB_EventType_Change           ; Inhalt hat sich geändert.
      ;TODO
    Case #PB_EventType_DragStart        ; Der Anwender versucht, eine Drag & Drop Operation zu starten.
  EndSelect
EndProcedure

Es gilt nach einen Event (WaitWindowEvent) dieses wie ein Baum zu betrachten. Diese ist festgelegt und man muss sich daran halten.
Eine Abweichung von dieser Regel führt unweigerlich zu einen Fehler in der Auswertung des Events.

Diese kann so aussehen...

Code: Alles auswählen

;- TOP

; GUI Konstanten
Enumeration Windows
  #Main
EndEnumeration

Enumeration Menus
  #MainMenu
EndEnumeration

Enumeration MenuItems
  #MainMenuItemExit
EndEnumeration

Enumeration Gadgets
  #MainList
EndEnumeration

Enumeration Statusbar
  #MainStatusBar
EndEnumeration

; Globale Variablen
Global ExitApplication

; Funktionen

Procedure EventGadgetMainList()
  
  Select EventType()
    Case #PB_EventType_LeftClick        : Debug "Klick mit der linken Maustaste. Gadget " + EventGadget()
      ;TODO
      Debug "Eintrag " + GetGadgetState(#MainList)
    Case #PB_EventType_RightClick       : Debug "Klick mit der rechten Maustaste. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_LeftDoubleClick  : Debug "Doppelklick mit der linken Maustaste. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_RightDoubleClick : Debug "Doppelklick mit der rechten Maustaste. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_Focus            : Debug "Fokus erhalten. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_LostFocus        : Debug "Fokus verloren. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_Change           : Debug "Inhalt hat sich geändert. Gadget " + EventGadget()
      ;TODO
    Case #PB_EventType_DragStart        : Debug "Der Anwender versucht, eine Drag & Drop Operation zu starten. Gadget " + EventGadget()
  EndSelect
EndProcedure

Procedure MainSizeWindow()
  ResizeGadget(#MainList, 0, 0, WindowWidth(#Main), WindowHeight(#Main) - MenuHeight() - StatusBarHeight(#MainStatusBar))
EndProcedure

;- Mainloop
Procedure Main()
  Protected Event, index
  
  If OpenWindow(#Main, #PB_Ignore, #PB_Ignore, 600, 400, "GUI-Example",#PB_Window_SystemMenu | #PB_Window_SizeGadget)
    ; Menu
    CreateMenu(#MainMenu, WindowID(#Main))
    MenuTitle("&Ablage")
    MenuItem(#MainMenuItemExit, "Be&enden")
    ; Statusbar
    CreateStatusBar(#MainStatusBar, WindowID(#Main))
    AddStatusBarField(100)
    AddStatusBarField(#PB_Ignore)
    ; Gadgets
    ListViewGadget(#MainList, 0, 0, WindowWidth(#Main), WindowHeight(#Main) - MenuHeight() - StatusBarHeight(#MainStatusBar))
    For index = 1 To 10
      AddGadgetItem(#MainList, -1, "Item " + index)
    Next
    ; Event Loop
    Repeat
      Event = WaitWindowEvent()
      Select Event
        Case #PB_Event_CloseWindow
          Select EventWindow()
            Case #Main
              ExitApplication = #True
          EndSelect
        Case #PB_Event_SizeWindow
          Select EventWindow()
            Case #Main
              MainSizeWindow()
          EndSelect
        Case #PB_Event_Menu
          Select EventMenu()
            Case #MainMenuItemExit
              ExitApplication = #True
          EndSelect
        Case #PB_Event_Gadget
          Select EventGadget()
            Case #MainList
              EventGadgetMainList()
          EndSelect
          
      EndSelect
      
    Until ExitApplication
  EndIf
  
EndProcedure : Main()

End

Verfasst: **11.03.2018 17:35**

Hallo Bisonte,

Du siehst : (Wait)WindowEvent() löst keine Ereignisse aus, sondern diverse Objekte, wie eben Gadgets oder Fenster.

Das habe ich auch nicht behauptet. Ich sagte, WaitWindowEvent() registriert Events und legt die Id des Events in der Variablen EId ab. Eigentlich geht es mir gar nicht um die Frage, wer oder was welches Event ausgelöst hat. Sondern ich habe das Thema gestartet, um nur eine einzige Frage zu klären:

Was muß passieren, damit nach einem #PB_Event_Gadget (ausgelöst von wem auch immer, ob nun offiziell dokumentiert oder nicht, völlig egal) EventGadget() -1 zurückgibt?

DAS würde ich gern verstehen, und wenn jemand darauf eine Antwort hat, wäre ich ihm sehr dankbar, wenn er sie mir mitteilt. (Und daß genau das im Default-Zweig passiert, beweist ja mein kleines Beispielprogramm.)

@ ts-soft

Der Default-Zweig ist in diesem Falle einfach unnötig.

Das ist jetzt eine ziemlich steile Aussage, weil Du ja nicht den Grund kennst, aus dem ich den Default-Zweig eingefügt habe. Ich habe ihn nicht eingefügt, um ein funktionierendes Event-Management zu bekommen -- das habe ich schon --, sondern um das Event-Handling von PureBasic besser zu verstehen. Ich will nicht nur eine funktionierende Event-Schleife, sondern ich will darüber hinaus wissen, warum sie funktioniert. Und da bin ich momentan noch keinen Schritt weiter, weil ich nicht weiß, wieso der Default-Zweig in meinem Programm überhaupt angesprungen wird.

Zu den anderen Posts kann ich nichts sagen, weil ich mich noch als Anfänger betrachte und mit Callbacks, XProfan usw. nichts zu tun hatte.

Gruß

Verfasst: **11.03.2018 18:11**

Dein Default in Event macht eigentlich keinen sinn, da hier alles aufläuft was du vorher nicht Case #PB_Event_Gadget, Case #PB_Event_CloseWindow, etc abgearbeitet hast. Dazu gehören z.B. Case #PB_Event_Menu, etc dazu.
Da du hier auch noch bei den anderen Events auch EventGadget() abfragst ist der Rückgabewert ungültig. Das dann -1 zurückgibt ist auf jeden fall gut, denn nur nach den Event #PB_Event_Gadget erhältst du eine gültige Gadget-Nummer und danach den gültigen EventType().

Also wie ich geschrieben habe die Events und deren Unterfragen wie ein Baum betrachten.

siehe mein Beispiel oben...

Verfasst: **11.03.2018 18:46**

WindowEvent() bzw. WaitWindowEvent() leitet die meisten der Windows Messages (die heißen nirgends PureBasic Messages), aus dem Message Queuing (MSMQ) in meine Schleife, wo dann die wichtigsten rausgepickt werden können. Der Rest wird weiter geleitet (polling) und von Windows automatisch bearbeitet.

Eine Select-Schleife, hat immer einen Default-Zweig, ob belegt oder nicht. Das dieser immer sinnvoll belegt werden muss, steht nirgends, zu mal er in diesem Falle autom. von Windows belegt wird und nicht von PureBasic.

Wenn Dir jetzt noch nicht klar ist, warum der Default-Zweig ignoriert werden kann, dann kann ich Dir auch nicht helfen

PureBoard

Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets

Re: Events und Gadgets