Seite 1 von 2
macro problem
Verfasst: 10.06.2011 21:24
von kevv
Code: Alles auswählen
Procedure.s a10()
A$="123"
Debug "jeee"
ProcedureReturn A$
EndProcedure
Macro UMsgBox(Title, Body, test)
;If test = A.l :test = 10 :EndIf
MessageRequester(Title, Body, 0)
MessageRequester("testinhalt", Str(test), 0)
a#test() ;test = A.l
EndMacro
A.l=10
UMsgBox("Hello", "World",A.l)
;UMsgBox("Hello", "World",10) ; funzt
Wie kommt es das aus test=A.l wird, obwohl ich dem A den Wert 10 zugewiesen hab
und sobald ich die a#test() Zeile auskommentiere wird aus test=10
Re: macro problem
Verfasst: 10.06.2011 22:07
von STARGÅTE
Macro-Parameter werden zu Kompilerzeiten ersetzt!
Das heißt, das programm läuft dann noch garnicht.
Bei Macros werden einfach nur "beliebige Zeichen" für die Parameter eingesetzt.
Macros sind keine Prozeduren!
Wenn du "A.l" an das Macro übergibst, wird über all "A.l" eingesetzt
Re: macro problem
Verfasst: 10.06.2011 23:07
von kevv
STARGÅTE hat geschrieben:Macro-Parameter werden zu Kompilerzeiten ersetzt!
Das heißt, das programm läuft dann noch garnicht.
Bei Macros werden einfach nur "beliebige Zeichen" für die Parameter eingesetzt.
Macros sind keine Prozeduren!
Wenn du "A.l" an das Macro übergibst, wird über all "A.l" eingesetzt
hmm, ich übergebe aber nicht A.l sondern die Zahl 10 an das macro
der zweite massagerequester zeigt es ja an
Nur wenn ich a#test() dazuschreibe wird plötzlich aus der Zahl 10 A.l ???
ich will eine Zahl an das Marco übergeben die ich bei comp. noch nicht weis
die wird erst ermittelt wen die Anwendung läuft
Re: macro problem
Verfasst: 10.06.2011 23:26
von STARGÅTE
ich will eine Zahl an das Marco übergeben die ich bei comp. noch nicht weis
Dann ist ein Macro an dieser Stelle falsch! Da ein Macro ja nach dem Kompilieren garnicht mehr existiert, weil es halt ersetzt wurde.
Macros haben Platzhalter, die zum Zeitpunkt der kompilierung alle mit dem übergebenen "Zeichen" ersetzt werden.
Für den Kompiler übergibst du A.l an das Macro, weil A.l nur Zeichen sind für den Kompiler ...
Was du machen möchtest, benötigt zum Beispiel Prototypes
Code: Alles auswählen
Procedure A1()
Debug "A1"
EndProcedure
Procedure A2()
Debug "A2"
EndProcedure
Prototype Beispiel()
Structure ProzedurListe
Beispiel.Beispiel[3]
EndStructure
Define ProzedurListe.ProzedurListe
ProzedurListe\Beispiel[1] = @A1()
ProzedurListe\Beispiel[2] = @A2()
; Nun kannst du sowas machen:
A = 2
ProzedurListe\Beispiel[A]()
ProzedurListe\Beispiel[2-1]()
Re: macro problem
Verfasst: 11.06.2011 11:46
von Bisonte
@Stargate:
Also wenn ich dein Snippet richtig verstanden habe, kann man auf diese Art und Weise Prozeduren
direkt anspringen... ?
Würde so etwas auch in DLL's/UserLibs funktionieren ?
Also aus der DLL heraus eine Prozedure aufrufen die im
aufrufenden Programm ist, wenn man die Adresse der
Prozedur als Parameter an die DLL übergibt ?
Dann könnte man Prozeduren aufrufen die in der DLL gar nicht vorhanden sein müssen...
(z.B. eine Eventloop, in der DLL, und die Ergebnisse werden dann im aufrufenden Programm
verarbeitet)
Re: macro problem
Verfasst: 11.06.2011 12:29
von STARGÅTE
Wenn ich es richtig verstanden hab, Ja.
Wenn die DLL so aussieht:
Code: Alles auswählen
Prototype.i Event(Parameter1.i)
ProcedureDLL Beispiel(Pointer.Event, Parameter1.i)
ProcedureReturn Pointer(Parameter1)
EndProcedure
kann ich im Programm über Beispiel() eine belibige Funktion ausführen lassen.
Code: Alles auswählen
Procedure.i Test(Wert.i)
ProcedureReturn Wert*100
EndProcedure
OpenLibrary(1, "Event.dll")
Debug CallFunction(1, "Beispiel", @Test(), 123)
An Beispiel wird der Pointer zu Test() übergeben und die Zahl 123.
Beispiel in der DLL ruft dann dieses Test() mit 123 auf.
Im Programm wird 123*100 genommen und 12300 zurückgegeben.
Diesen Rückgabewert gibt dann auch Beispiel zurück.
PS: auch hier sollte man aber nach möglichkeit Import verwenden
Re: macro problem
Verfasst: 11.06.2011 12:57
von Bisonte
So ungefähr war mein gedankensprung
Also geht das, wunderbar.
Nur was meinst du mit
PS: auch hier sollte man aber nach möglichkeit Import verwenden
Mein Wissen ist da leider sehr begrenzt. Ich bin schon froh, dass ich mit Tailbite eine simple Userlib hinbekomme
Re: macro problem
Verfasst: 11.06.2011 13:09
von STARGÅTE
Ich meine damit, du solltest lieber (die von PB mit erstellte) *.lib nutzen:
Code: Alles auswählen
Procedure.i Test(Wert.i)
ProcedureReturn Wert*100
EndProcedure
Import "Event.lib"
Beispiel(*Pointer, Parameter.i)
EndImport
Debug Beispiel(@Test(), 123)
Zitat:
"Dieses Feature kann die OpenLibrary()/CallFunction() Sequenz ersetzen, da sie einige Vorteile bietet: es erfolgt eine Typen-Überprüfung, die Anzahl an Parametern wird geprüft. Nicht wie bei CallFunction() können ohne Probleme Doubles, Fließkomma und Quad Variablen verarbeitet werden."
Die Event.dll muss natürlich trotzdem dabei sein.
PS: eine *.DLL+*.lib erstellst du mit PB mit dem Kompilerformat: Shared Dll
Re: macro problem
Verfasst: 11.06.2011 13:18
von ts-soft
Ich habe auch schon eine DLL erstellt, die lediglich eine Funktion, zum ermitteln der
Funktionsadressen der anderen Funktionen, exportiert. Dadurch werden dann die
enthaltenen Funktionen etwas verschleiert
Gruß
Thomas
Re: macro problem
Verfasst: 11.06.2011 13:30
von Bisonte
Ok. Soweit so gut...
Braucht man das mit dem Import auch wenn es sich nur um eine Userlib handelt ?
(Ich hatte DLL gesagt, weil es sich ja laut PBHilfe programmiertechnisch um das
gleiche handelt)
Edit:
Ich dachte da an eine Server Eventloop in einer Userlib, wo die Events abgeholt werden,
und da die Weiterverarbeitung ja nicht immer gleich ist, wäre es dann praktisch,
wenn man der Userlib halt die Prozeduren so übergibt, damit dorthin gesprungen wird,
wenn das entsprechende Event anliegt. Ich bau gleich mal ein Beispiel und mach nen neuen Thread auf,
das wandert doch erheblich von diesem Topic ab
Edit2 : hier gehts weiter :
http://purebasic.fr/german/viewtopic.ph ... 65#p291665