Parameter bei CallFunctionFast

[Vera]

Hi Nino,

klar, gar keine Frage, dass es in der PB-Hilfe & Compiler gut angebracht wäre. Doch bis dahin ...
Aber der Vorteil der Board-FAQ ist, die können wir selber RuckZuck ändern und erweitern.

Gruß ~ Vera
(wir haben übrigen zeitgleich die Postings editiert)

Nachtrag für Blackskyliner (s.u.): Die FAQ erscheint auch, wenn man die Board-Suche nutzt !!!

[ralle]

Hallo alle zusammen!

Ich muss mich entschuldigen. Ich kenne es halt so aus anderen Foren, dass Threads nach Klärung einer Frage zum Antworten gesperrt werden, um unnötige Vermüllung, etc zu vermeiden. Wenn das hier nicht so gehandhabt wird belassen wir es einfach so . Und ich gebe deinem Standpunkt hierzu auch einfach mal uneingeschränkt Recht, da das jedes Forum halt anders regelt .

Hier mal ein funktionierendes Beispiel mit Prototype und MapÜbergabe

Code: Alles auswählen

Prototype testPrototype(name.s, Map par.s())

Structure testS
    method.testPrototype
    Map testP.s()
EndStructure

*test.testS = AllocateMemory(SizeOf(testS))
InitializeStructure(*test, testS)

Procedure testMapParam(text.s, Map arg.s())
    Debug "Speichere Key, text = " + text
    
    If FindMapElement(arg(), text) = 0
        arg(text) = "element hinzugefügt"
    EndIf
EndProcedure

*test\method = @testMapParam()
*test\method("test1", *test\testP())
*test\method("test2", *test\testP())
*test\method("test3", *test\testP())
*test\method("test4", *test\testP())
*test\method("test5", *test\testP())

ResetMap(*test\testP())
ForEach *test\testP()
    Debug "Key = " + MapKey(*test\testP())    
Next

End

Ich gebe zu, viel Sinn ergibt das Beispiel in der Anwendung nicht, aber ich hoffe es verdeutlicht, wie Prototypen angewendet werden können und mit Maps als Parameter funktionieren.

mfG
Ralle

[ralle]

Und bevor noch diverse Fragen kommen, wozu das Ganze; In meinem speziellen Fall hatte ich vor 2 Jahren mal eine Graphical User Interface Engine in PB geschrieben und war heutzutage mit dem Ergebnis in der Anwendung nicht mehr zufrieden. Diesbezüglich entsteht das Projekt gerade neu. Prototypen werden jetzt eingesetzt, um EventHandler zu realisieren. So sah die alte Engine aus:

Ist komplett skinningfähig (d.h. für eine andere Optik mussten nur die Grafiken und eine config angepasst werden, ohne was am Code zu verändern), sogar Skinwechsel zur Laufzeit im Programm war drin und alle hier sichtbaren Elemente waren voll funktional.

Die GUI-Engine sollte mir einfach bei zukünftigen Entwicklungen das lästige "Ich fange mit den Menüs an"-Programmieren auf wenige Zeilen vereinfachen .

mfG
Ralle

[NicTheQuick]

Ein 'ResetMap()' vor einer 'ForEach'-Schleife ist nicht notwendig, aber macht natürlich auch nichts kaputt.

[a14xerus]

...Graphical User Interface Engine in PB geschrieben...

Das sieht ja echt super aus.

Freue mich schon auf das Ergebniss

[Vera]

Hi ralle,

ich sag' schonmal Danke

und herzlich Willkommen
(das Du mit dem Registriedatum von 2004 dieses Forum nicht kennst, konnte ich kaum annehmen)

Auch die GUI sieht schick aus - viel Erfolg bei Deinem weiten Vorhaben.

cheers ~ Vera

[Blackskyliner]

Hi Nino,

klar, gar keine Frage, dass es in der PB-Hilfe & Compiler gut angebracht wäre. Doch bis dahin ...
Aber der Vorteil der Board-FAQ ist, die können wir selber RuckZuck ändern und erweitern.

Gruß ~ Vera
(wir haben übrigen zeitgleich die Postings editiert)

Auch wenns Teil-OT ist, aber welcher "Anfänger" oder suchende schaut denn bitte zuerst in die Board-FAQ?
Mal davon abgesehen, ob ich nun sage "Schau da und da nach" anstatt zu sagen "Nimm Prototypes." Ist am ende gleich lang und somit keine Ersparnis im Aufwand...

Hoffe das diese GUIEngine als Include kommt

[ralle]

Hoffe das diese GUIEngine als Include kommt

Diese eher weniger, wenn dann die neue Fassung, welche andere Ansätze verfolgt und insgesamt flexibler Ressourcensparender wird. Auch wenn die bisherige Version nicht ganz so spektakulär aussieht

Bisher gibt es:
- Environment
(verwaltet globale Listings mit allen erzeugten Objecten und Konstanten)
- Object
(Implementiert alle Basisfunktionen, welche von allen Elementen einer GUI benötigt werden)
- Desktop:Object
(Eine direkte Ableitung von Object mit anderer Draw und Calc Methode, welche den Hauptbildschirm darstellt)

Es dürfen beliebig viele Desktops existieren, mit beliebig vielen Elementen als Childs. Geplant sind wie bei der alten Engine
- Window:Object
- Dialoge:Window
- Button:Object
- CheckBox:Object
- Text:Object
- TextInput:Object
- alles was halt noch so an Objecten anfällt.

Im besten Falle wird pro DrawingCylce nur ein Sprite (+noch ein Sprite für den Cursor) gezeichnet (der des gerenderten Desktops), was die Rechenlast im Verhältnis zur alten Fassung erheblich verringert.

Die GUI wird wie die erste einen "Objektorientierten" Ansatz implementieren, d.h. es wird mit Strukturen und Interfaces nicht gespart, um Polymorphie zu "emulieren". Hat bei solch einem Projekt aus meiner Sicht nur Vorteile. Aber bis das neue Projekt die Funktionalität des alten bietet wirds wohl noch dauern und dann werde ich es sicherlich auch mal vorstellen.

mfG
Ralle