Module und globale Variablen aus dem Hauptprogramm

[NicTheQuick]

Bloß wäre dazu erst mal ein Gadget und damit ein Window notwendig und das Modul müsste auch noch wissen von welches Gadget es die Daten auslesen soll. Quasi ein Henne-Ei-Problem.

[walbus]

[STARGÅTE]

Man könnte zB mit Set/GetEnvironmentVariable() arbeiten, wobei hier die Gefahr besteht, dass man ein Namenskonfikt hat.

[walbus]

[Nino]

Was Ihr hier mit Gadgets und Umgebungsvariablen vorschlagt, ist unnötig umständlich. Außerdem untergräbt es den Sinn von Modulen.

[walbus]

[Nino]

Ach so, dann hatte ich das falsch verstanden. Sorry, dass ich "Vorschlag" geeschrieben habe.

[walbus]

[helpy]

@STARGÅTE: Du hast vollkommen Recht.
Bei mir ist es so, dass ich im Hauptprogramm einen Wert aus einer Konfigurationsdatei einlese und dieser dann innerhalb des Moduls zu unterschiedlichen Schritten verzweigt.
Gibt es nicht noch einen Trick o.ä.?

Ich würde grundsätzlich Module so schreiben, dass Sie nicht auf Daten im Hauptprogramm zugreifen müssen.
Vor der Verwendung der Hauptfunktionen des Moduls kannst Du den Konfigurationswert einfach an das Modul übergeben.
Eine Möglichkeit, das umzusetzen:

Code: Alles auswählen

;- Modul MyModule
DeclareModule MyModule
	EnableExplicit
	
	Global configSmartCopy.i
	
	Declare AnyFunction()
	;...
EndDeclareModule

Module MyModule
	EnableExplicit
	
	Procedure AnyFunction()
		Select configSmartCopy
			Case 1
			Case 2
			Default
		EndSelect
	EndProcedure
	;...
EndModule


;- Hauptprogramm
Global smartcopy.i

; Konfigurationswert einlesen
smartcopy = ReadConfigValueSmartCopy()

MyModule::configSmartCopy = smartcopy
MyModule::AnyFunction()

;...

End

Damit bleibt das Modul in sich gekapselt. Was das Modul für eine ordnungsgemäße Funktion brauchte, sollte man diesem auch auf die eine oder andere Art übergeben.
Das ist für mich der logischere Weg und in meinen Augen die sauberste Lösung.

Den Weg über ein Commom-Modul finde ich persönlich nicht so gut (wenn es sich vermeiden lässt).

cu,
guido

[walbus]