Nun dies war der Ausgangspunkt für meine Anfrage:
Weswegen ich es ausdrücklich gekennzeichnet hatte (="was ich bevorzugen würde") das es keine Antwort auf Deine Frage ist, sondern nur eine Erläuterung meiner Aussage.
Die Case-Anweisung sollte nach Pit’s Wunsch ggf. wegfallen oder einfacher strukturiert werden.
WENN Letzteres so wäre, wäre das von mir Gesagte zufällig doch eine Antwort, denn mein Beispiel geht davon aus sich die ganzen Einzelmakros zu sparen, was ja, zumindest nach Pit's Logik, als Vereinfachung gilt, da es jeweils 2 Code-Zeilen einspart.
Nebenbeigesagt könnte man es auch optisch anders schreiben, das es ähnlich aussieht als wären es doch einzelne Makros, sofern das jemand besser fände:
Code: Alles auswählen
Sub Start2(par)
Select Case par
Case "Test"
'... tue etwas
Case '....
'...
End Select
End Sub
Wnnn Du hierbei Sub .... Select und End .... End soweit nach rechts rückst das sie 'außerhalb' der Sichtbarkeit in der Basic-IDE sind, sieht es (nach meinem Empfinden) so aus als wäre die Case-Abschnitte einzelne Makros.
ist dies im Prinzip auch ein String.
Nö, denn es ist nicht per Anführungszeichen als String gekennzeichnet.
Welche Mechanismen des Interpreters greifen hier, damit er dies als Anweisung und nicht als String verarbeitet?
Der Interpreter muss im gesamten 'Gültigkeitsbereich' des Makros prüfen ob es keine Makros oder Funktionen gleichen Namens gibt. Da es zur Laufzeit, generell(*) aber auch abhängig von den aktuell geladenen Bibliotheken, hierbei 'Uneindeutigkeiten' geben kann ist es zweckmäßig den Modulnamen beim Aufruf eines Makros immer davor zu schreiben, also Call meinModul.meinMakro und nicht nur Call meinMakro.
(*)
denn es darf in unterschiedlichen Modulen gleichnamige Makros geben
Gruß
Stephan