Seite 2 von 4
Verfasst: 21.08.2006 00:40
von edel
ts-soft hat geschrieben:Die Structure steht in Gadget.h im Librariy-SDK. Ist auch nur im
Zusammenhang von Libraries, die Gadgets erstellen, sinnvoll einsetzbar.[...]
Erklaer mir mal bitte warum das nur mit Libs sinnvoll waere.
Verfasst: 21.08.2006 00:49
von ts-soft
edel hat geschrieben:ts-soft hat geschrieben:Die Structure steht in Gadget.h im Librariy-SDK. Ist auch nur im
Zusammenhang von Libraries, die Gadgets erstellen, sinnvoll einsetzbar.[...]
Erklaer mir mal bitte warum das nur mit Libs sinnvoll waere.
Bei welcher Art von Anwendungen ist es denn sonst noch Sinnvoll?
Wird in > 99,9 % aller Anwendungsfälle nicht benötigt
Verfasst: 21.08.2006 02:01
von edel
Was spricht denn dagegen ?
Beispiel :
Code: Alles auswählen
Structure PBWindow
hwnd.l
EndStructure
Structure PBGadget
hwnd.l
*vt
Userdata.l
EndStructure
Structure PBImage
Handle.l
cx.w
cy.w
d.w
EndStructure
Structure Application
*Window.PBWindow
*Image.PBImage
*Button1.PBGadget
*ImageGD.PBGadget
Event.l
delay.l
EndStructure
Global App.Application
App\Window = OpenWindow(#PB_Any,0,0,300,300,"")
App\delay = #PB_Default
CreateGadgetList(App\Window\hwnd)
App\image = CreateImage(#PB_Any,200,100,32)
App\Button1 = ButtonGadget(#PB_Any,10,10,100,25 ,"Button1")
App\image = ImageGadget(#PB_Any,10,40,App\image\cx,App\image\cy,App\image\Handle)
Repeat
App\Event = WaitWindowEvent(App\delay)
Debug App\Event
If App\Event = #PB_Event_Gadget
Select EventGadget()
Case App\Button1
If App\delay = 10
App\delay = #PB_Default
Else
App\delay = 10
EndIf
EndSelect
EndIf
Until App\Event = #WM_CLOSE
Verfasst: 21.08.2006 02:24
von freak
Interne PB Strukturen sind nicht dafür gedacht in PB code verwendet zu werden.
Das hat mehrere Gründe:
- Der Inhalt oder die Funktion der Strukturen kann sich jederzeit ändern. Hacks basierend auf internen Informationen sind in
der Vergangenheit oft im Forum geposted worden. Für den Moment funktionieren die ja ganz gut,
aber mit dem nächsten PB Update kommen dann die ganzen Anfragen warum dies oder jenes nicht mehr funktioniert.
- Sie (gut) zu dokumentieren und vorallem up to date zu halten kostet viel Zeit, die wir nicht haben.
Auserdem muss man auch für alles was man dokumentiert auch einen gewissen Grad an Support leisten.
Wir wollen nicht unsere Zeit mit Anfragen/Problemen verschwenden, die Sachen betreffen,
die eigentlich auser uns niemanden angehen.
- Diese Strukturen sind auf jedem OS mit dem PB funktioniert anders.
Ich weis das viele hier außer der Windows Version nichts interessiert, aber das PB
Konzept ist eben das Entwickeln von Programmen für mehrere Systeme, und das
Veröffentlichen dieser Daten steht da im Konflikt dazu.
- Die enthaltenen Informationen sind für normalen PB code nicht von Nutzen.
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.
Bestes Beispiel ist dieser Thread hier. Für die gestellte Frage ist die Lösung über die intene
Gadget Struktur absoluter Overkill, weil die GadgetID() funktion genau das gleiche Ergebnis
liefert, und das ist eine einfache, offizielle dokumentierte funktion. Das verwenden der
Struktur direkt ist hier nichts mehr als eine potentielle Problemquelle mit dem nächsten Update.
Die meisten derartigen Hacks die man so in den Foren sieht würden sich mit ein paar mehr
Zeilen auch in reinem PB code lösen. Trotzdem greifen viele (auch Anfänger) zu solchen
codes wenn sie einmal im Forum sind, und wenn es dann nach dem Update nicht mehr
klappt haben sie keine Ahnung wiso.
Der ursprüngliche Gedanke für die dokumentation einiger solcher Strukturen in früheren
Versionen war der das es Programmierern von Userlibs die Chance geben sollte Funktionen
zu schreiben, die mit PB Objekten umgehen können und dabei sich wie PB's eigene Funktionen
verhalten.
Das wurde aber fast gar nicht genutzt, sondern die Informationen wurden eben nur für derartige Hacks verwendet.
Zu welchen Problemen das führt hat man mit dem v4 Update gut gesehen.
Wenn jemand derartige Infos braucht um eine Lib zu schreiben kann er sich gerne direkt
an uns wenden und wir können die benötigten Informationen dann gerne herrausgeben,
aber nicht mehr einfach als eine Liste von Strukturen so wie früher.
@edel:
Ich verstehe den Sinn dieser Art zu programmieren ganz und gar nicht. Für alles was du da machst
gibt es Funktionen in PB. Wozu also das Risiko eingehen das mit dem nächsten Update
gar nichts mehr funktioniert, wenn es doch gar nicht sein muss ?
Der Code den du da geposted hast bräuchte nur geringfügige Änderungen und keine
der Strukturen wäre nötig.
Das ist genau das was wir verhindern wollen, weil es eben nur Probleme schafft und keinen
Nutzen bringt.
Wenn dir die Art wie die PB Objekte gehandhabt werden nicht gefällt, warum dann überhaupt diese
Objekte verwenden und nicht gleich direktes API ?
Verfasst: 21.08.2006 03:02
von ts-soft
Leider fehlen in PB noch entsprechende Funktionen, um selber Gadgets zu
registrieren, bzw. um eigene UserLibs zu erstellen. Wenn sowas von Hause
aus unterstützt wäre, bräuchte man die Strukturen nicht und es würde keine
Konflikte geben.
Wäre auf jedenfall wünschenswert, wenns in dieser Richtung offizielle
Erweiterungen geben würde. Solange es die nicht gibt, muß man eben auf
solche Dinge zurückgreifen, obwohl es früher oder später zu problemen
führen kann.
Die Nutzung nur der Syntax wegen, da sehe ich auch keinen Sinn drinn.
Gerade wegen der einfachen einheitlichen Syntax mag ich PB ja
Verfasst: 21.08.2006 03:14
von edel
@freak
Ich kann deine Argumente zwar nachvollziehen, aber mir macht
dieser Code (zugegeben, er ist etwas uebertrieben) mehr Spass.
Warum sollte ich noch extra eine Funktion bemuehen, wenn die
Informationen doch schon vorhanden sind ...?
Wie gesagt, du hast natuerlich Recht. Ich fuer meinen Teil
poste ja schon gar keinen 'Hallodri-Code' mehr. Solch ein Code
wirft nur zuviel Fragen auf, die ich ja selber kaum beantworten
kann.
Verfasst: 21.08.2006 03:41
von PMV
Warum sollte ich noch extra eine Funktion bemuehen, wenn die
Informationen doch schon vorhanden sind
... das kann ich nicht nachvollziehen
Funktionen sind dafür da, um Werte zurück zu geben. Daher ruft man sie
auch auf
... es handelt sich dabei auch oft einfach nur um einen Wert
der irgend wo im Speicher steht. Damit man sich aber nicht immer darum
kümmern muss, wo er steht, hat man die Funktion. Seit PB 4.0 kann man
natürlich für diesen zweck nun besser Macros benutzt. Aber ansonnsten
ist das gang und gebe.
Du solltest dir deinen "Spaß" schnell wieder
abgewöhnen, sonnst wirst du wohl bald richtigen Spaß mit deinen Codes
haben
(nur nen Tipp
)
MFG PMV
Verfasst: 21.08.2006 03:56
von edel
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.
Verfasst: 21.08.2006 10:12
von Konne
Was ich sehr gut fände wäre eine Doku darüber was eine PB Funktion ist und was ein MAcro ist. zB wäre ien macro für RGB() oder soetwas ja sehr sinnvoll.
Verfasst: 21.08.2006 11:29
von Leonhard
freak hat geschrieben:- Die enthaltenen Informationen sind für normalen PB code nicht von Nutzen.
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.
Wo bekomme ich den DC- (Device Context) Handle von einer 2D-Zeichnung??? Ich mein mit einer normalen Funktion und nicht mit der Rückgabe von StartDrawing().