PureBoard

Hallo freak,

ich kann Deine Argumente gegen eine Offenlegung der PB-Strukturen in gewisser Weise schon verstehen.
Wo ich jedoch nicht mit Dir übereinstimme ist die Aussage, dass PB bereits für alle Informationen die man aus diesen Strukturen erhalten könnte entsprechende Funktionen bereit stellt.
In diesem Punkt muss ich also ts-soft ganz klar zustimmen - da fehlt leider noch so einiges. Vor allem im Bereich Gadgets. Aber auch so Dinge wie "wo liegt der SpecialEffects-Buffer" oder "ist StartDrawing() bereits aufgerufen worden" oder "auf welchen OutputBuffer greift StartDrawing() momentan zu" bleiben ohne die Strukturen unbeantwortet.
Und solche Dinge sind eben nicht nur für Libraries interessant, sondern auch schon für eigene, etwas allgemein gehaltenere Prozeduren.

Nehmen wir an, ich möchte eine allgemeingültige Prozedur schreiben, die Zugriff auf alle Windows und Gadgets des Programms haben muss (soll heissen, dass sie automatisch alle Gadgets ansprechen und deren Details abrufen kann).
Momentan ist es in reinem PB-Code nicht möglich an diese Informationen zu gelangen, da man halt keinen Zugriff auf die Liste aller Gadgets hat.
Da ich mal annehme, das PB intern diese Informationen bereits in einer Liste speichert, wäre es ein leichtes, diese Informationen mit Hilfe de der Strukturen abzurufen.
Die einzige momentane Alternative wäre nur, das mit großem API Aufwand zu machen - wodurch man dann wieder jenseits von PB programmieren müsste und wieder nur an Windows gebunden wäre.

Und genau in diesem Punkt stimme ich Dir dann wieder zu, dass das Konzept von PB eben die Platformunabhängigkeit ist.
Denn genau aus diesem Grunde habe zum Beispiel ich mich extra FÜR PureBasic entschieden.
Nur leider stößt man bei der Entwicklung zumindest etwas anspruchsvollerer Anwendungen mangels vorhandener PB-Befehle immer wieder auf einige Schwachstellen, wo man dann doch wieder nicht umhin kommt die API zu bemühen.
Dies macht PB in meinen Augen (zumindest momentan) leider zu einer reinen Einzel-Plattform Sprache - und das finde ich sehr schade.

Das ihr nicht komplett jede API-Funktion in einen PB-Befehl nachbilden könnt ist klar, aber gerade da würde dann der Zugriff auf die PB-Strukturen zumindest ein weinig weiterhelfen. Da man dann für viele Dinge die man so noch benötigen würde eben NICHT eine OS-spezifische Funktion bemühen müsste, sondern durch Zugriff auf die Strukturen innerhalb von PB bleiben könnte.

Wenn Du eine Liste mit Funktionen haben möchtest, die im Grunde in PB noch so alle fehlen, kann man ja gerne mal eine zusammen stellen.
In der Hauptsache werden es wohl fehlende Get-Befehle sein, also Befehle, wodurch man Informationen abfragen kann (und genau das könnte man dann ja selber, wenn man Zugriff auf die Strukturen hätte).
Aber diese Liste umzusetzen würde für Euch wohl viel Aufwand bedeuten, und mangels Zeit wohl auch noch etliche Monate dauern.

Ich frage mich, wo liegt denn wirklich das Problem, interessierten Usern die benötigten Strukturen mitzuteilen? Das sowas dann unsupported ist und sich die Strukturen ggfl. ändern können dürfte doch jedem klar sein. Aber ohne diese Strukturen bleiben einem (zumindest den etwas ambitionierteren PB-Usern) halt leider viele Möglichkeiten, die man mit ihnen hätte, verschlossen.

Also meine Bitte lautet nach wie vor: Stellt doch den fortgeschrittenen Usern diese Strukturen zur Verfügung. Auch wenn es nur auf explizite Anfrage ist.
Macht es dann aber bitte so, dass dann auch aufstrebende Neuling und evtl. angehende PB-PowerUser erfahren können, dass es solche Strukturen gibt und wo man diese erfragen kann.
Ich befürchte nur, dass diese Einzelanfragen Euch mehr Arbeit machen würden, als wenn Ihr die Strukturen einfach im SDK-Verzeichnis mitliefern würdet.

In diesem Sinnne noch einen schönen Gruß,
PL.

freak hat geschrieben:Sie sind ja nur dazu da, Daten für die PB Funktionen zu speichern, d.h. alles was da drin ist und für
PB code interessant ist, kann auch durch eine PB funktion erhalten werden.

wenn das 100%ig zutreffen würde, wärs ja schick.

edel hat geschrieben:

Code: Alles auswählen

Procedure Test()
  ProcedureReturn 10
EndProcedure

var = 10
var = Test()

Ich hoffe dir faellt auf, dass das Bloedsinn ist ?
Daher schreibe ich es halt lieber so :

Code: Alles auswählen

*win.Long = OpenWindow(-1,0,0,100,100,"")

CreateGadgetList(*win\l)

*button.Long = ButtonGadget(-1,3,3,100,20,"")

Repeat : Until WaitWindowEvent()    = #WM_CLOSE

Was den Spass betrifft so programmiere ich nicht wie Fred, Freak
oder ein PMV es gerne moechten. Und Probleme hatte ich bis jetzt
nur mit '_PB_Gadget_CurrentObject' und PB4. Der Rest funktioniert
so auch unter <V4.

Du vergleichst Äpfel mit Birnen ... was hat das eine mit dem anderen zu tun? ...
Dass das so schwachsinn ist, ist klar ... dafür verwendet man Konstanten,
aber du willst ja keinen konstanten Wert zurück haben. In größeren
Projekten sind aber manchmal einfache Funktionen (Macros) besser
geeignet. Der Rückgabewert wird durch die Parameter bestimmt.
Der PB-Befehl RGB() z.B. gibt auch nur einen Wert zurück. Str(), Val()
machen auch nicht sehr viel und doch sind sie unabdingbar. GadgetID(),
WindowID() usw. lesen auch nur einen einzellnen Wert aus. Und wenn
sich mal herrausstellt, das die Struktur von PB geändert werden muss,
dann funktionieren diese trotzdem.
Aber mir ist das doch egal was du machst ... ich benutzte deine
Programme ja vermutlich eh nicht. ... warum schreib ich hier
eigentlich ... sorry, mein fehler, ich hätte inzwischen merken müssen das
du deinen eigenen Kopf hast, nächste mal halt ich mich zurück

@Leonhard
Mit StartDrawing() wird doch erst ein DC erstellt, oder seh ich das falsch?
Und StartDrawing() ist eine Funktion ... aber naja ein zusätzlicher
Befehl dafür würd auch nicht schaden, wenn er auch nicht benötigt
wird. Wobei als Macro würde sich das eventuell doch lohnen. Oder
überseh ich da was?

MFG PMV

PMV hat geschrieben: Du vergleichst Äpfel mit Birnen ... was hat das eine mit dem anderen zu tun? ...
Dass das so schwachsinn ist, ist klar ... dafür verwendet man Konstanten,
aber du willst ja keinen konstanten Wert zurück haben. In größeren
Projekten sind aber manchmal einfache Funktionen (Macros) besser
geeignet. Der Rückgabewert wird durch die Parameter bestimmt.
Der PB-Befehl RGB() z.B. gibt auch nur einen Wert zurück. Str(), Val()
machen auch nicht sehr viel und doch sind sie unabdingbar. GadgetID(),
WindowID() usw. lesen auch nur einen einzellnen Wert aus. Und wenn
sich mal herrausstellt, das die Struktur von PB geändert werden muss,
dann funktionieren diese trotzdem.
Aber mir ist das doch egal was du machst ... ich benutzte deine
Programme ja vermutlich eh nicht. ... warum schreib ich hier
eigentlich ... sorry, mein fehler, ich hätte inzwischen merken müssen das
du deinen eigenen Kopf hast, nächste mal halt ich mich zurück

Entweder habe ich mich bloed ausgedrueckt oder du hast es nicht
verstanden.... Wenn ich den Wert X schon habe (Fensterhandle) ist ein
Funktionsaufruf (in diesem Fall WindowID([])) total ueberfluessig.
Was du jetzt allerdings mit Macro willst, versteh ich wiederrum nicht.


Was die Fehleranfaelligkeit betrifft (nach einem Update z.B.), behaupte
ich einfach mal, dass sich an der Struktur in den naechsten 100
Versionen nichts aendern wird, zumindest was das Handle betrifft.

Natuerlich musst du meine Programme nicht benutzen, was das aber
mit der Struktur zu tun hat, weiss ich nicht. Einem kompiliertes
Programm ist es voellig egal, ob da *win\l oder WindowID() steht.

Im uebrigen faende ich es recht schlimm keinen eigenen Kopf zu haben.
Ich wuesste ja gar nicht was ich machen sollte wenn ich diesen wieder
zurueckgeben muesste ...

ja wenn du der Meinung bist, es macht sinn die Internen Sturkturen von
PB zu verwenden, dann tu das doch. Aber das ist kein Grund, warum Fred
oder Freak diese fein säuberlich Dokumentieren sollen. Es ist nicht
vorgesehen. Wenn du irgend wie an die Strukturen kommst. Gut. Wenn
sie so bleiben wie sie sind. Gut. Wenn sie sich doch mal ändern und du
das sofort beheben kannst. Gut. Wenn nicht, dein pech. Aber das ist dann
deine sache und nicht von Fred oder Freak . Und darum gehts hier
ja wohl ... um deine Bitte, das Fred oder Freak die internen Strukturen
dokumentieren.

Der einzige Einwand, dem ich beipflichte ist der von PureLust ... soweit
ich jetzt nicht wieder wen vergessen hab Und das finde ich wichtiger
als wegen anderen unvorsichtigen das weg zu lassen. Sollte sich von
denen am ende doch wer beschweren würd ich das schlicht und
ergreifend ignorieren. Selber schuld.

MFG PMV

Edel hat wenn es um das Prinzip geht nicht unrecht. letztendlich gehts ja nicht um "Nimm es so wie es ist", sondern darum, was man aus etwas machen kann. Siehe die OOP Welle (wenn man dies so nennen kann). Ist nicht in PB nativ integriert aber mit Tricks geht es, obwohl Fred dies gar nicht anbieten will/wollte. Viele Ideen mancher User welche nicht nativ angeboten wurden sind jetzt als reguläre PB Commands wiederzufinden.

Und was heisst Strukturen veröffentlichen oder nicht? Diese Strukturen waren (oder sind es gar noch) im Library SDK Ordner in einem Textfile (Descriptor o.ä) vorzufinden, daher waren/sind sie kein Geheimnis.

Unzählige Codes hier im Forum sind eh API basiert, daher kann man was die Codes hier angeht eh nicht von einer generellen Platformunabhängigkeit reden.

Also warum so eine Welle machen, derjenige der jene Strukturen nutzen will und die Äuglein aufmacht findets heraus und es tut keinem weh (auch dem PB Author nicht).

Mein lieber PMV, ich habe nicht eine Zeile geschrieben wo steht das hier
Irgendjemand was auch immer auflisten soll. Nicht das ich es schlecht
finden wuerde, allerdings wuerden mich weniger die Internen PB Befehle
oder Strukturen interessieren. Eine bessere Dokumentation des Kompilers
faende ich viel wichtiger.

ich gieße mal ein Löffelchen Öl in euer Feuer:

wer behauptet denn, dass WindowID() eine funktion ist?

vielleicht ist es ja ein compilermacro...

Kaeru Gaman hat geschrieben: wer behauptet denn, dass WindowID() eine funktion ist?

vielleicht ist es ja ein compilermacro...

Aus Sicht des Programmieres ist es in jedemfall eine Funktion
Die Funktion befindet sich in der Windows Lib neben 40 weiteren (sowie 6
versteckten). Wenn der Code dieser Funktion ein Macro aufruft, so wird es
trotzdem eine Funktion bleiben.

Feuer im Keime erstickt

edel hat geschrieben:Mein lieber PMV, ich habe nicht eine Zeile geschrieben wo steht das hier
Irgendjemand was auch immer auflisten soll. Nicht das ich es schlecht
finden wuerde, allerdings wuerden mich weniger die Internen PB Befehle
oder Strukturen interessieren. Eine bessere Dokumentation des Kompilers
faende ich viel wichtiger.

Und warum postest du dann überhaupt hier? ... darum geht es in
diesem Thread ... die Dokumentation der internen PB-Befehle.

Naja gut, dann nehm ich das halt wieder zurück^^
Damit war unsere Diskusion ja noch sinnloser als angenommen

Und was verstehst du unter einer "besseren" Dokumentation des
Compilers? ... diese Doku braucht doch nur Fred? ...

MFG PMV