[code] Eventloop für mehrere Fenster

[Kaeru Gaman]

ich find's toll, dass hier wirklich ein lebhafter Gedankenaustausch entstanden ist!

zum Einwand, zuerst nach Gadgetnummer zu unterscheiden und nur im Bedarfsfall nach Fensternummer... ( HeX0R , 04 Jun 2009 19:23 )

ich finde, es fällt in punkto Performance praktisch nicht ins Gewicht,
und selbst wenn du nur nach Gadgets unterscheidest,
solltest du trotzdem eine klare Gliederung nach Fenster in deinem Code haben.

insofern ergibt sich bei deiner Herangehensweise das Problem, dass du eigentlich eine wesentlich unklarere Gliederung provozierst.

Code: Alles auswählen

; Fenster 1
  # Gadget 1.1
  # Gadget 1.2
  # Gadget 1.3

; Fenster 2
  # Gadget 2.1
  # Gadget 2.2
  # Gadget 2.3

; Fenster 3
  # Gadget 3.1
  # Gadget 3.2
  # Gadget 3.3

# Resize
 # Fenster 1
 # Fenster 2
 # Fenster 3

# Close
 # Fenster 1
 # Fenster 2
 # Fenster 3

also warum nicht gleich

Code: Alles auswählen

# Fenster 1
  # Gadget 1.1
  # Gadget 1.2
  # Gadget 1.3
  # Resize
  # Close
# Fenster 2
  # Gadget 2.1
  # Gadget 2.2
  # Gadget 2.3
  # Resize
  # Close
# Fenster 3
  # Gadget 3.1
  # Gadget 3.2
  # Gadget 3.3
  # Resize
  # Close

auch wenn es technisch nicht unbedingt nötig ist?

natürlich, je nach größe, anzahl fenster, layout...
für kleinere projekte ist deine Herangehensweise leichter, schneller, verführerischer.

aber grundsätzlich ist es einfach klarer strukturiert, übergeordnet nach fenster / formular zu unterscheiden,
auch wenn es technisch nicht unbedingt nötig ist.

[HeX0R]

natürlich, je nach größe, anzahl fenster, layout...
für kleinere projekte ist deine Herangehensweise leichter, schneller, verführerischer.

Naja, ich sehe da jetzt keinen Unterschied ob kleine Projekte oder sehr große.
Es geht schlicht und ergreifend um die eigene Sicht der Dinge.

Wenn mir beim 12. Fenster auffällt, dass ich beim Beenden noch was hinzufügen muß, schau ich in meiner Eventschleife nach #PB_Window_CloseWindow (das genau einmal existiert) und gehe zum entsprechenden Fenster.

Genau genommen hat keines von beiden tatsächliche Vor- oder Nachteile es geht nur um das eigene Problemlösungskonzept.

Wenn allerdings meine Gadgetkonstanten wirklich solche Namen hätten wie: #Gadget1.1, #Gadget2.1, ... dann wäre das in der Tat ziemlich unübersichtlich.
Gott sei Dank darf man diesen aber auch eindeutige Namen zuweisen.

Fazit:
Alles ist erlaubt und alles funktioniert.

[Little John]

... und unter Linux kuckt man in die Röhre.

Bei den max. 5% wo eine plattformunabhängige Version überhaupt einen
Sinn macht, kann man dies doch Vernachlässigen.

Hier ist ja ein allgemeines Problem vorgestellt worden, und zunächst wurde dazu nativer PB-Code gepostet. Wenn man dann eine Lösung vorschlägt die nur unter einem Betriebssystem funktioniert, sollte das schon dazugeschrieben werden ... das hatte ich nachgeholt.

Außerdem halte ich die Cross-Plattform-Fähigkeit für einen wichtigen Aspekt von PureBasic, der für meinen Geschmack zu oft vernachlässigt wird.

Die Eventhandler der LinuxAPI machen doch EasyVENT überflüssig.

Diese Eventhandler kenne ich leider nicht. Wo sind die dokumentiert?

Gruß, Little John

[Kaeru Gaman]

Johnny, Tu n'es pas un Ange

[Little John]

Je ne regrette rien

[edel]

Die Eventhandler der LinuxAPI machen doch EasyVENT überflüssig.

Diese Eventhandler kenne ich leider nicht. Wo sind die dokumentiert?

http://library.gnome.org/devel/gdk/2.16/

[Little John]

Vielen Dank!

[Kurzer]

Es müssen dabei maximal nur diese Variablen global sein:

Code: Alles auswählen

  Event
  EventType
  EventWindow
  EventwParam
  EventlParam
  EventGadget
  EventMenu

In dem Beispiel ja. In einem richtigen Programm kann es gut sein dass die verschiedenen Fenster Informationen austauschen. Wenn z.B. eines der Fenster ein Options-Dialog ist in dem der Benutzer 20 Variablen verändern kann, müssen diese Variablen auch in einem oder mehreren der anderen Fenster zugänglich sein, in denen die vom Benutzer gesetzten Werte dann verwendet werden.

Wo siehst Du da Gefahren oder Probleme?

Ich sehe das Problem darin, dass bei zu vielen globalen Variablen die Übersichtlichkeit und damit auch die Wartbarkeit nicht mehr gut ist. Die vermeintlich bessere Übersichtlichkeit durch Prozeduren kann sich dadurch IMHO ins Gegenteil verkehren.
Gruß, Little John

Da ich durch Dich gerade wieder über diesen Beitrag stolpere...

Wollte nur sagen, daß ich solche Sachen wie Programmoptionen (viele Variablen vom benutzer änderbar...) eh immer in einer globalen Struktur speichere.

Beispiel:

Code: Alles auswählen

;Struktur für die Programm-Einstellungen
Structure DCSettings
	;Programmstatus/Version
  sAppdatapath.s												; Pfad zum Settings-Verzeichnis (%APPDATA%/Directchat/)
  sProgramStatus.s											; Programmstatus, wird in der Statuszeile des Mainwindows angezeigt
  sIniFile.s														; Pfad inkl. Dateiname des INI-Files

	;Fehlervariablen
  bNoIniFile.i

	;Programmverhalten
	bSaveWindowPosOnExit.i								; True/False, Sollen die Fensterpositionen beim Beenden gesichert werden?

	; Netzwerk
  sClientname.s													; Name des Clients
  sExternIpUrl.s												; Webseitenaddresse zur Ermittlung der externen IP, z.B. http://www.whatismyIP.com
  bNetworkStatus.i											; True/False kennzeichnet, ob alle Vorraussetzungen für Netzwerkverkehr geschaffen sind
  iInternIP.i														; Lokale IP-Nummer
  iExternIP.i														; Externe IP-Nummer
  iPort.i																; Portnummer für die Client/Server-Verbindung
  iExternIPOrigin.i											; IP wurde ermittelt aus #HEADER = Webseitenheader, #SITE = Webseitenbody
  sFindIPUrl.s													; Internet-Url zum ermitteln der externen IP (z.B. http://checkip.dyndns.org)

  ; FTP-Server
  sFTPServer.s													; Adresse des FTP-Servers inkl. Unterverzeichnisse
  sFTPUser.s														; User
  sFTPPassword.s												; Paßwort
  bFTPPassiv.i													; True/False passive FTP-Übertragung?
  
	; Fenster
  wsMain.Window													; Einstellungen des Settingfensters
  wsSettings.Window											; Einstellungen des Settingfensters
EndStructure
Global ProgramSettings.DCSettings

Diese Daten braucht man eh an den verschiedensten Ecken, da ist es schon sinnvoll diese global erreichbar zu haben.
Und das Verpacken in einer Struktur.. nun äh strukturiert das ganze dann auch wieder ganz prina.

[PMV]

Ich verwende für jedes Fenster eine eigene Includedatei und eine Struktur,
welche alle zugehörigen PB-IDs beinhaltet. (Fenster-ID, Gadgets und
Menüs). Fals öfters benöigt schreib ich das hWnd auch darein.

Für das Eventhandling gibt es also auch für jedes Fenster eine eigene
Prozedur:

Code: Alles auswählen

Procedure xxxEventHandler(Event.i, *Window.WindowStructure)

Im Mainloop wird nur in einem Select-Case abgefragt, welches Fenster das
Event ausgelöst hat und dann die entsprechende Event-Procedur
aufgerufen. Das, was WaitWindowEvent() zurück gegeben hat, wird als
Parameter übergeben. Alle anderen Ereignise ändern sich nach einem Aufruf
des entsprechenden Befehls ja nicht und somit benötigt es dafür keine
Variable zum zwischenspeichern.

Globale Variablen hab ich nicht für jedes Fenster. Ich habe eine
globale Struktur, in welcher auch die Fensterstrukturen gespeichert sind,
sofern diese global benötigt werden. Ähnlich wie es Kurzer macht also.

MFG PMV