Office: Umgang mit (optionalen) ByRef-Parametern / "NULL"-Referenz?

Hallo!

Mein Code sei

Code:

Beim ersten Aufruf von T wird ja B nicht mitübergeben. Von daher ist es sinnlos/kontraproduktiv, den entsprechenden Wert für B bereitzustellen. Wie müsste also in Machwas die Parameterdefinition bzw. die mit '...' gekennzeichnete Prüfung aussehen, um festzustellen, ob B nun mit übergeben wurde oder nicht?

Ein MachWasA, MachWasB, ... MachWasZ würde ich gerne vermeiden. Das Interface ufert ansonsten aus.

:)

 

Hallo AnaMark,

ein kleines Zitat aus der Excel-VBA-Hilfe sollte dich hier weiterbringen: *wink.gif*

Code:

 

Hallo, IngGi!

Leider nein. Ich zitiere aus ebendieser Hilfe:

"Anmerkung IsMissing funktioniert nicht mit einfachen Datentypen (wie Integer oder Double), [...]"

Beispiel:

Code:

--> Die MsgBox erscheint in beiden Fällen.

 

Hallo AnaMark,

äääh, ja - wer lesen kann und davon auch Gebrauch macht, ist klar im Vorteil!

Wäre die Vorgabe von Dummywerten eine gangbare Alternative?
Code:

 

Abend auch,

oder nimm anstatt:

Code:

sowas:

Code:

Dann funktioniert die Unterscheidung schon.

cu, Bernd
--
Code:

 

Hallo, IngGi und bst!

Eure beiden Ideen hatte ich auch schon, habe sie aber verworfen, da:

1) Ich beide Vorgehensweisen für schlechten Programmierstil halte. (Sorry, soll kein Vorwurf an einen von euch beiden sein; Ich habe schon an größeren Projekten mitgearbeitet; und da ist vieles, was für ein kleines 10-Zeilen-Makro noch O.K. ist, ein absolutes No-No. Außerdem geht es hier auch nicht um ein 10-Zeilen-Makro.)

2) Dummywerte: Es gibt nicht in jedem Fall einfach festzulegende Werte, bei denen man in Zukunft garantieren kann, dass sie nicht vorkommen. Bei jedem Parameter im Vorfeld eine "Untersuchung" durchzuführen, welcher Parameter kommen kann und welcher garantiert nicht kommen wird, ist eigentlich nicht machbar. Anders ausgedrückt: Ich sehe es jetzt schon kommen, dass diese Variante in Zukunft für arge Probleme sorgen wird.

3) Variant: Dann tu' ich ja tausendmal hin- und herkonvertieren und muss in jeder Fitzelsubroutine eine Prüfung auf den korrekten Typ machen mit Fehlerroutine etc.pp.. Bei einem Long ist klar, was er enthält. Damit kann man optimiert arbeiten, Datenfelder sind effizient. Bei einem Variant muss ich jedesmal auf den Typ prüfen (Vertraue keinen fremden Daten...), die Arbeit mit Variants benötigt viel mehr Ressourcen.

...aber so langsam habe ich den Eindruck, dass VBA alles ist, nur keine gescheite Programmiersprache. Die einfachsten Dinge, die man von vernünftigen (Makro-)Programmiersprachen gewöhnt ist, sind in VBA schlicht nicht gescheit lösbar. Microsoft hat sich hier wohl den gleichen Murks zusammengecoded wie im ganzen Rest ihrer Produkte... Und der Benutzer muss die irrsinnigsten Verrenkungen machen, um deren Versäumnisse auszugleichen. Aber leider habe ich hier keine andere Wahl und muss mit MS-Office... *frown.gif*

 

Hi,

Wenn es denn um mehrere 1000 Zeilen Code oder noch (viel) mehr gehen sollte ist IMHO VBA sowieso nicht mehr das geeignete Werkzeug. Nimm dann besser C++, C# und VSTO o.ä.

cu, Bernd