PureBoard

If Gadget = #PB_Any
das ist völlig überflüssung und kann nie ausgeführt werden! Ausser du übergibst
fälschlich -1 an deine Funktion. Das ist aber dann ein Fehler des Programmiers und nur
einer von vielen Möglichen. Das zu prüfen bringt nichts.

Um zu prüfen, ob das eine gülte GadgetNummer ist, geht nur IsGadget()

Noche eine Anmerkung:
CheckGadgetEx_
den Unterstrich würde ich so nicht machen, da Funktionen gefolgt von einem Unterstrich
von PB für direkt integrierte Windows-APIs verwendet wird. Das suggeriert es ist eine WindowsAPI-Funktion.

Es scheint du hast nicht den ganzen Beitrag gelesen SMaag.

Ghosty1967 zielt mit seiner Funktion darauf ab die PB Gadgetfunktionen mit zusätzlichen Parametern für Farbe und Schriftart zu erweitern.
Natürlich muss er dann auch #PB_Any als Parameter erlauben und entsprechend verarbeiten. Das if ist somit keineswegs überflüssig, sondern nötig.

Die Überschneidung mit der API Bezeichnung stimmt. ist eine Stilfrage. Ich denke man kann Funktionen so bezeichnen, wenn man keine API Funktionen im Code verwendet und somit ein Leser nicht verwirrt ist. (Immer dran denken, später ist mans selbst mal unwissender Leser, wenn man das Projekt nach Jahren ausgräbt!) Wobei ich persönlich es auch nicht machen würde.

Ghosty1967 zielt mit seiner Funktion darauf ab die PB Gadgetfunktionen mit zusätzlichen Parametern für Farbe und Schriftart zu erweitern.
Natürlich muss er dann auch #PB_Any als Parameter erlauben und entsprechend verarbeiten. Das if ist somit keineswegs überflüssig, sondern nötig.

Ist dem wirklich so? Wäre mal interessant zu wissen, ob die Prozedur CheckBoxGadget bei Erfolg die übergebene Gadgetnummer zurückliefert oder eher das Windows-Interne Handle. Denn ich glaube nicht, das die Prozedur bei Erfolg noch eine zufällig generierte Nummer erzeugt, die es zurückliefern kann, obwohl eine passende Nummer schon übergeben wurde. Soweit ich weiß liefert die Prozedur bei #PB_Any eine generierte ID zurück und bei Vorgabe einer ID einfach nochmal die selbe. Und dann ist es schon richtig, das die If-Abfrage sinnlos ist. Denn schließlich prüft CheckBoxGadget ja schon selbst auf #PB_Any ab.

Nein, wenn man eine eigene ID vergibt, dann gibt CheckBoxGadget (wie alle anderen Funktionen) nicht diese bei Erfolg zurück.
Einfachstes Gegenargument ohne Test: Man kann Gadgets mit der Nummer 0 erstellen, jedoch ist ein Rückgabewert von 0 ein Fehler bei der Erstellung.

Tatsächlich wird die GadgetsID, also das Handle zurückgegeben. ABER: Das ist nicht dokumentiert, also sollte man nie Code drauf aufbauen, denn es kann sich jederzeit ändern. Und wenn man #PB_Any übergibt stimmt es nicht mehr. Lieber die ID dann mit GadgetID(wert_den_die_gadgetfunktion_zurueckgab) ermitteln. Beim Programmieren zählt Glauben wenig, die Dokumentation und Tests dafür viel.

Bitte testet doch kurz Ideen bevor sie als Aussagen ins Forum kommen, das ist flotter als einen Beitrag zu verfassen.

Macros hat geschrieben: 22.09.2023 11:26Bitte testet doch kurz Ideen bevor sie als Aussagen in Forum kommen, das ist flotter als einen Beitrag zu verfassen.

Na da bin ich ja froh, das ich keine Aussage getroffen habe.

Macros hat geschrieben: 22.09.2023 09:38 Es scheint du hast nicht den ganzen Beitrag gelesen SMaag.

Ghosty1967 zielt mit seiner Funktion darauf ab die PB Gadgetfunktionen mit zusätzlichen Parametern für Farbe und Schriftart zu erweitern.
Natürlich muss er dann auch #PB_Any als Parameter erlauben und entsprechend verarbeiten. Das if ist somit keineswegs überflüssig, sondern nötig.

Danke für den Hinweis. Gelesen schon, aber erst jetzt komplett verstanden.

Noch etwas!
Hat schon mal jemand darüber nachgedacht oder umgesetzt, alle Gadgets in OOP Klassen zu kapseln.

Damit könnte man Standardvorgaben automatisch auf alle Gadgets umsetzen und man könnte eine Gadget-Auflistung implementieren,
Mit der man mit ForEach druch alle Gadgets laufen kann. Sonderfunktionen vor allem für Windows, an die man nur mit Sendmessage kommt
könnte man fest implementieren.

Fontumschaltungen usw. könnte man realtiv einfach auf alle Gadgets umlegen.

Mit Vererbung könnte man dann auch relativ einfach individuelle Methoden hinzufügen.
Ein automatisches andocken z.B., so dass bei einem Resize nur das Master-Gadget verschoben werden muss!

Geh mir weg mit OOP, aber tu Dir keinen Zwang an

Was hast du gegen OOP?

RSBasic hat geschrieben: 22.09.2023 17:50 Was hast du gegen OOP?

Nicht wirklich viel.... Granaten, Gewehre, Pistolen, Hundestaffeln... ich sag ja, nich viel