Global Procedure Include

[TroaX]

Das einzige Problem das ich da gerade sehe - es ist schon etwas umständlich...

Es ist sehr umständlich und ich würde den Quark auch garnicht mitmachen. Entweder gibt es ein zentrales gekapseltes Repo, wo kein Admin oder Mod nach irgendwelchen "Regeln" wie einen festen Programmierstil über veröffentlichen oder nicht veröffentlichen entscheidet oder ich persönlich werde es einfach nicht nutzen. Wenn ich seit Jahren nach einem eigenen Stil schreibe und dieser nicht mit den Regeln der "Master-Repo" konform ist, dann fange ich definitiv nicht damit an, meine Codes umzubasteln.Design follows functions. Entweder man frisst den funktionierenden Code oder lässte es bleiben oder wartet auf jemanden, der die gleiche Funktion in die gewüschten rosa Schleifchen packt.

Dafür nicht nach 3 Tagen wieder offline

Das kommt natürlich ganz auf die Person an, die den Webspace stellt. Ich denke mal, das RSBasic da aber sehr zuverlässig sein dürfte (ich glaube er hatte es angeboten).

Ich halte Github auch für recht unübersichtlich. Dann können wir im Grunde auch gleich ein Forum nehmen.

[NicTheQuick]

Ich find's gut. Wird außerdem eh mal Zeit, dass die IDE ein neues GIT- und SVN-Werkzeug bekommt. Mag keiner schnell eins schreiben?

[GPI]

Ach die PureArea ist auch nicht offline - nur hoffnungslos veraltet.

@TroaX
Die "Designrules" sollten schon allgemein gehalten sein. Ein Header ist nahezu unerlässlich, um die Übersicht zu behalten. Das sind nur ein paar Kommentarzeilen.
Das mit Compilerif #pb_compiler_ismaincode ist folgendermaßen gedacht: Die einzelnen Module/Proceduren soll man einfach per XIncludeFile einfügen können. Es empfiehlt sich aber immer ein Beispiel mitzugeben, wie man den Code am besten nutzen kann. Es gibt dann zwei Möglichkeiten: Entweder man macht zwei Dateien - einmal die IncludeDatei und einmal das Beispiel - oder man kombiniert beide. Dann klappt aber das mit dem Include nur, wenn es mit Compilerif automatisch entfernt wird.
Meinetwegen könnte man auch die Dateien in Englisch und Deutsch verfassen - ich kann beides ausreichend - nur bei Französisch setzt es halt aus. Und es ist nunmal so, das Englisch die Weltsprache ist und gerade beim Programmieren eh sehr viel nur in Englisch vorhanden ist. Deshalb sollte man halt Procedurennamen etc. in Englisch gehalten sein und nicht Französisch oder Deutsch. Das passt auch zum Syntax von PB, das auch nur englische Begriffe verwendet. Wenn mal ein deutscher Kommentar in Quellcode drin ist, wäre das nicht zwingend störend. Es sollte halt vermieden werden.

Wenn man aber einen Code einreicht und bspw. #pb_any konsequent ignoriert, sollte man damit rechnen, das einer den Code überarbeitet und das mit #pb_any löst. Ich würde auch rechnen, das irgendwer das ganze auf Module umschreibt, da die einfach flexibler sind. So kann man leichter mehrere verschiedene Include-Dateien einfügen, ohne auf irgendwas acht geben zu müssen.

Ohne Mods und Admins wird es aber auf keinen Fall gehen. Sonst wächst das Ding wie Kraut und Rüben und keiner kennt sich mehr aus und das ganze wird ziemlich nutzlos. Auch braucht es von einem Beispiel/Code nicht 10 Varianten, nur um jeden Programmierstiel gerecht zu werden. Hier müssen sich die Mods notfalls absprechen.

"Freie Liebe" klappt halt nur so lang, bis alle Frauen Schwanger sind oder sich die Geschlechtskrankheiten alle dahinraffen

Meine Sorge ist mehr, das der Anmeldungsprozess und Softwareinstallation schlicht zu kompliziert für viele sind....

@nic
Wenn das Zeug leichter verständlich wäre gerne

[ts-soft]

Module sind schon mal gut, da hab ich auch gleich einen Vorschlag für.
Z.B. gemeinsame Constanten, damit diese immer zur Verfügung stehen. Also, diejenigen, die #PB_Any überflüssig machen.

Code: Alles auswählen

DeclareModule CommonConstants
  ; Form
  Enumeration FormWindow
  EndEnumeration
  Enumeration FormGadget
  EndEnumeration
  Enumeration FormMenu
  EndEnumeration
  Enumeration FormImage
  EndEnumeration
  ; Event
  Enumeration EventCustom #PB_Event_FirstCustomValue
  EndEnumeration
  Enumeration EventTypeCustom #PB_EventType_FirstCustomValue
  EndEnumeration
EndDeclareModule

Module CommonConstants
EndModule

UseModule CommonConstants

In jedem Modul einfügen und man kann Gadgets usw. mit Constanten numerieren:

Code: Alles auswählen

Enumeration FormGadget
  #MyModule_MyGadget
EndEnumeration

Allerdings von Änderungen an meinen Modulen halte ich nicht viel, die würde ich, wenn gut, selber vornehmen, weil die
Wünsche aller User blähen das evtl. nur auf oder sind nicht so passend. Ich denke mal, so werden die meisten denken.

Gruß
Thomas

[GPI]

Sowas wie Common-Module werden kaum gehen. Die einzelnen Codes/IncludeDateien sollen natürlich möglichst unabhängig von den anderen bleiben. Von daher wird es nichts mit einem globalen Common.

Aber die Grundidee ist von den ganzen doch, das man seinen Code der Community (blödes Wort) zur Verfügung stellt und diese ihn natürlich auch pflegen wird. Aber ich denke nicht, das jemand deinen Code nimmt und sie zur Weltformel aufbläht. Mit Fehlerkorrekturen und kleinen Erweiterungen muss man aber immer rechnen.

Eventuell sollten wir uns auch erstmal unterhalten, was das Ding darstellen soll.

Wäre auch nett, wenn ein paar andere sich noch zu Wort melden. Irgendwie komm ich mir gerade ein bischen wie ein Alleinunterhalter vor

[ts-soft]

Sowas wie Common-Module werden kaum gehen. Die einzelnen Codes/IncludeDateien sollen natürlich möglichst unabhängig von den anderen bleiben. Von daher wird es nichts mit einem globalen Common.

Naja, dann wird es auch nichts ohne #PB_Any

Ich habe auch schon div. Module gesehen, die auf z.B. #PB_Event_FirstCustomValue angewiesen sind, die muß man alle
händisch anpassen

Hierin habe ich eigentlich den einzigen Sinn gesehen. Ein paar grundsätzliche Regeln und auch Module, weil so kann ich meine
Module, so wie bisher veröffentlichen und brauche das ganze nicht.

Bin dann wieder raus. Von globalen Proceduren halte ich immer noch nichts.

[GPI]

Naja, dann wird es auch nichts ohne #PB_Any

Imo eh die bessere Lösung

Ich habe auch schon div. Module gesehen, die auf z.B. #PB_Event_FirstCustomValue angewiesen sind, die muß man alle
händisch anpassen

Wird man wohl nie 100% vermeiden lassen.

Wobei das ist ein Problem, das sich tatsächlich lösen lässt:

Code: Alles auswählen

CompilerIf Defined(common,#PB_Module) 
  CompilerIf  Defined(common::CustomEventList,#PB_Enumeration)
    Debug "gibt eine common-liste"
    Enumeration common::CustomEventList
  CompilerElse
    Debug "gibt common, aber keine Liste"
    Enumeration CustomEventList #PB_Event_FirstCustomValue
  CompilerEndIf
CompilerElse
  Debug "gibt kein common-modul"
  Enumeration CustomEventList #PB_Event_FirstCustomValue
CompilerEndIf
#myevent_blablabla
EndEnumeration

Ja, sieht auf den ersten Blick etwas unübersichtlich aus. Der Code überprüft, ob es ein Modul common gibt. Wenn ja, ob es eine Enumeration CustomEventList gibt. Wenn ja, wird sie weitergeführt, ansonsten eine neue erstellt (die leider dann nicht global ist). Ergebnis: Jeder kann sich ein Common-Modul schreiben, so das es sich automatisch erweitert. Das blöde ist, das Module einfach zu sehr schwarze Löcher sind.
Eventuell sollte man bei Fred anregen, das man sowas eigentlich überhaupt nicht mehr erlauben sollte, das man Events mit RegisterEvent() anmelden muss, ansonsten darf man sie nicht nutzen. Da wäre das Problem komplett aus der Welt geschafft.

Das ist halt so eine Sache, die ein Mod/Admin konsequent in die Codes reineditieren müsste.

Hierin habe ich eigentlich den einzigen Sinn gesehen. Ein paar grundsätzliche Regeln und auch Module, weil so kann ich meine
Module, so wie bisher veröffentlichen und brauche das ganze nicht.

Bin dann wieder raus. Von globalen Proceduren halte ich immer noch nichts.

Seh es dann als Codesammlung. Kennst du das CodeArchiv von PureArea? Ich suche heute immer noch gerne da mal nach Lösungen für meine Probleme. Nur leider wird das nicht mehr gepflegt und ist veraltet.
Mein persönliches Ziel wäre es halt, genau dieses zu ersetzen und auf eine moderne Basis zu setzen.

Oder schau doch mal ins Forum? Wieviele gute Codes versumpfen in Code, Tipps und Tricks? Die gepinnten Threads sind imo auch keine gute Lösung. Sowas muss man Katalogisieren und Sortieren. Dann kann man es gut nutzen. Das ist imo das Ziel.

Sämtliche Probleme zu lösen wird man natürlich nicht können. Einige lassen sich abfangen, wie das mit FirstCustomEvent. Dazu müsste man mal sammeln, was für Probleme es überhaupt gibt. Wo sowas zwingend gebraucht wird.

Es müssen ja nicht nur IncludeDateien sein, sondern auch Beispiele. Einfach Codebeispiele, wie man was lösen kann. Wie bspw. der AtomicWebserver, der in den Beispielen von PureBasic finden kann (und viele garantiert nicht gefunden haben - den könnte man auch mal auf aktuellen Stand bringen. Ich finde das Ding durchaus praktisch, um in eigenen Netzwerk eine einfache Steuerung von Programmen zu bieten. HTML-Browser hat jedes Smartphone. Niemand sagt, das man nur WebDateien übertragen muss. Wenn man "Datei" "xyz" per Web anfragt, dann kann man auch eine Funktion des Programms aufrufen.

Da steckt imo viel Potential drin. Einfach mal über den eigenen Schatten springen.
p.s.: Wie gesagt alleinunterhalter ....

[ts-soft]

Ich hoffe mal, Du hast bemerkt, das meine CommonConstants lediglich eingebunden werden müssen, aber nicht gefüllt o. ä.
Die bleibt, wie sie ist. Lediglich die Namen der Enumeration sind in den Modulen zu übernehmen und pro Modul ein
UseModule CommonConstants.

Ich jedenfalls finde die Lösung Genial

[GPI]

Ich hoffe mal, Du hast bemerkt, das meine CommonConstants lediglich eingebunden werden müssen, aber nicht gefüllt o. ä.
Die bleibt, wie sie ist. Lediglich die Namen der Enumeration sind in den Modulen zu übernehmen und pro Modul ein
UseModule CommonConstants.

Ich jedenfalls finde die Lösung Genial

Doch ist es. Ich hab halt das mit mit definied überprüft, ob es ein Common-Modul gibt und eine "Common"-Enumeration. So läuft das ganze halt mit einen common-module, aber auch ohne.

Wie gesagt, mein persönlicher Gedankengang ist, das alles so funktionieren sollte, ohne das man eine "common.pbi" includen muss. Ich würde eh empfehlen, wenn man was findet, das man die Datei in aktuellen Projektordner kopiert.

[RSBasic]

Kennst du das CodeArchiv von PureArea? Ich suche heute immer noch gerne da mal nach Lösungen für meine Probleme. Nur leider wird das nicht mehr gepflegt und ist veraltet.
Mein persönliches Ziel wäre es halt, genau dieses zu ersetzen und auf eine moderne Basis zu setzen.

Diese Idee hatte ich auch, aber das war noch vor Einführung der Module. Da wollte ich grundsätzlich alle Codes einheitlicher gestalten, überall EnableExplicit einfügen, Variablen korrekt definieren, nicht funktionierende Codes verbessern u.ä.
Aber das Prüfen und Verbessern aller Codes des CodeArchivs ist bei 1.894 Beispielcodes sehr zeitaufwendig.