TabBarGadget - Tabs wie im Browser

[Lambda]

wo ist also die Falschaussage?

Besonders nützlich wird es, wenn Du eigene Gadgets z.B. auf Basis des CanvasGadget entwirfst
und die notwendige Ereignisverhandlung für Dein Gadget "unauffällig" bearbeiten möchtest.

Aber das jetzt nicht hier ausweiten, worauf ich hinaus wollte ist im Thread ja ersichtlich.

[NicTheQuick]

Wenn ihr hier noch weiter über den EM diskutiert, dann schiebe ich eure Threads einfach in den entsprechenden EM-Thread.

[ts-soft]

Schieb es bitte in den Müll, danke

[STARGÅTE]

@ts-soft:
Die Idee an sich ist gut, allerdings ist die Methode des ErsetzungsMacros etwas zu "schmutzig".
Damit will ich sagen, die Idee ist super aber ich packe sowas ungern in Includes hinein, weil die Programmierer ja meist selber ihre eigenen Ersetzungs-Macros haben was dann zu Fehlern führt.
Ich habe auch schon viele PB-Sachen ersetzt, um die Befehle zu erweitern aber halt nur privat.

@NicTheQuick:
Theoretisch hast du recht, im Thread würde ja nur alle 50ms PostEvent() ausgeführt werden, was selbst keine String enthält.

[STARGÅTE]

Im Zuge von PB 5.20 bietet es sich auch an, das TabBarGadget-Include auf die neuen Befehle zu verbessern.

Ich bin nun am Überlegen auch den Namen zu ändern: von xxxTabBarGadgetxxx zu nur xxxTabBarxxx.
Das Include und die Handhabung würde ich dann so abändern, dass die TabBar nicht mehr unter die Gadgets fällt, sondern ein eigenen Objekttyp darstellt.
Es würde dann #PB_Event_TabBar und EventTabBar() mit EventType() hinzukommen um die Events zu verwalten.

Code: Alles auswählen

CreateTabBar(#TabBar, ...)

Select WaitWindowEvent()
	Case #PB_Event_TabBar
		Select EventTabBar()
			Case #TabBar_Main
				Select EventType()
					Case #TabBar_EventType_NewTab
					Case #TabBar_EventType_CloseTab
						RemoveTabBarItem(#TabBar, #TabBarItem_Used)
				EndSelect
		EndSelect
EndSelect

Eine Registerkarteleiste (in der Form) ist ja schon etwas anderes als ein normales Gadget, und es würde alle Prozedurnamen dann etwas kürzer werden.

Was meint ihr dazu?

[ts-soft]

Da nach solch einer Änderung ja in jedem Falle bei der Anwendung änderungen fällig sind, würde ich das ganze
in ein Modul packen, getrennt in 2 Dateien, eine mit der Declaration und eine mit der eigentlichen Implementation.

Wichtig sind dann nur noch die Namen in DeclareModule, aber konflikte sind weitgehend ausgeschlossen.

[STARGÅTE]

Ich weiß irgendwie nicht, was ihr alle an den Modulen habt.

Ich finde Sachen wie: TabBar::Create() und TabBar::GetState() schlimm, weil sie einfach nicht in den Namensraum von PB passen.
Module sind n klasse Sache für Projekte, aber nicht für Includes wie dieses hier, welches sich an den PB-Stil halten soll.

Ich bin auch der Meinung, dass mein Include keine Namenskonflikte erzeugt, da alle Namen ein TabBarGadget enthalten.

[Derren]

Na, wo ist denn (für den Anwender einer Include) der Unterschied zwischen TabBar::Create() und TabBar_Create()?
Lass doch den User entscheiden ob er UseModule benutzen will oder die komplette "URI" (oder UCI, unified command identifier). Wenn UseModule nicht benutzt wird sollten auch keine Namenskonflikte auftreten. Und auch sonst nicht wenn der End-Anwender deiner Include sauber arbeitet. Aber das muss er ja wie gesagt selber wissen.

an den PB-Stil halten

Na der hat sich doch mit der Einführung von Module geändert, bzw. er wurde erweitert. Die Notation Gruppe::Befehl() ist jetzt ebenso gültig wie Gruppe_Befehl() vorher war.

Ich hab mir die neue Beta noch nicht gezogen und muss erst noch schauen welche Vorteile ich konkret aus Modulen ziehen kann. Aber die werde ja nicht nur zur optischen "Verschönerung" (A_B() -> A::B()) eingebaut worden sein.

Klar ist es Arbeit ein Include auf Module umzuschreiben, aber es zwingt dich ja keiner dazu. Ich seh nur nicht wo der Nachteil sein sollte von jetzt an Module zu verwenden.

[ts-soft]

@STARGÅTE
Ich hab nichts gegen die Syntax
Okay, Deine Include wird nicht so leicht kollidieren und auch Define.s wirft sie nicht aus der Bahn, in sofern
ist es nicht unbedingt notwendig es in ein Modul zu packen, aber alleine das EnableExplicit in der Include
ändert evtl. eine Einstellung im Code, desjenigen, der es nutzt, und auch ein DisableExplicit am Ende behebt diese
Einschränkung nicht, sondern führt eine Änderung bei denjenigen aus, die EnableExplicit nutzen möchten.

Ist nur eine Kleinigkeit, vernachlässigbar, aber IMHO warum sollte man es vernachlässigen, wenn es doch Module
gibt

Ich möchte Dich aber nicht beeinflussen, um gottes willen. Deine Include ist Spitzenmässig

Gruß
Thomas

[STARGÅTE]

PureBasic verwendet in seinen Funktionen meist eine Suffix-Notation: CreateImage, FreeImage.
Diese möchte ich auch in meinen Includes (die von dieser Art sind) beibehalten.
Module erzwingen hingegen eine Präfix-Notation: Image::Create, Image::Free
Diese Diskussion existiert bereits seit der ersten Programiersprache.
Vielleicht stellt PB auch irgendwann die eigenen Funktionen auf die Präfix-Notation um. dann werde ich da sicher mitgehen.

Aber zurück zur eigentlichen Frage: Soll die TabBar weiter als Gadget existieren, oder ein eigenes Objekt werden?