Vba Function

Option Explicit Public Function summeA(vatTabelle1 As Variant, lngKto As Long) As Double On Error GoTo Step With Worksheets(varTabelle1) summeA = Application.WorksheetFunction.SumIf(.Range("B1:B22"), lngKto, .Range("C1:100")) End With Step: End Function Sub TestIt() Debug.Print summeA(1, 1) Debug.Print summeA("Tabelle1", 1) Debug.Print summeA("KeinenWertGefunden", 1) End Sub

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

Option Explicit Public Function summeA(varTabelle1 As Variant, lngKto As Long) As Double With Worksheets(varTabelle1) summeA = Application.WorksheetFunction.SumIf(.Range("B1:B22"), mid(B1:B22,2,4)=lngKto, . _ Range("C1:C100")) End With End Function Sub TestIt() Debug.Print summeA(1, 1234) End Sub

…wenn man das auch zu einer ordentlichen FehlerBehandlung nutzt, was du nicht tust, Björn!
Der Fehler, der durch deine falsche Argumentierung von .SumIf entsteht, führt zu einem Fehler und der zum Sprung ans PgmEnde, wobei der Wert von summeA natürlich immer noch 0 ist.
Es ist nicht erforderlich, Application.WorksheetFunction.SumIf zu schreiben, WorksheetFunction.SumIf reicht. Falls du dagegen Application.SumIf schreiben würdest, könnte summeA den zurückgegebenen Fehlerwert (wahrscheinlich #BEZUG!) aufnehmen, wenn es nicht As Double, sondern gar nicht deklariert wäre (As Variant). So wie hier würde deine UDF allenfalls den allgemeinen StandardFehlerwert #WERT! zurückgeben, was wenig aussagekräftig wäre. Xl-Standard-Fktt sind deshalb idR nicht explizit deklariert (meine UDFs auch nicht!). Mit der vbFkt CVErr kann man einen passenden Fehlerwert in einen XlStandardFehler umwandeln.
Zu deiner neuen Frage:
Versuche das, was du mit der WorksheetFunction.SumIf vorhast, mal in einer ZellFml! Du wirst schnell merken, dass Xl die Annahme verweigert. Die HptArgumente etlicher nachträglich dem ursprünglichen Xl-Konzept hinzugefügter Fktt* verlangen zwingend ZellBereichsBezüge. Ein Ausdruck (expression) als Argument hat aber keinen bzw verliert ihn, falls es sich dabei um eine Fml handelt, die dann ein Datenfeld (Array) zurückgibt. Dafür reicht schon eine einfache Multiplikation eines Bereichs mit 1, was allerdings nur in einer ZellFml fktionieren würde, nicht in VBA! Außerdem ist zu beachten, dass WorksheetFunctions immer nur im vorgesehenen ArgumentierungsRahmen fktionieren, weil die Unterstützung durch die Xl-Steuerung in VBA idR fehlt (die hat man nur mit vbFkt Evaluate!). D.h., ein skalar vorgesehenes Argument muss auch zwingend ein Einzelwert sein, kein Datenfeld! Man erkennt das an der ArgumentAnzeige des Fml-Assis bzw in der Xl-Hilfe zur jeweiligen Xl-Fkt.
* Das ist höchstwahrscheinlich dem Umstand zu verdanken, dass damit Pgmmierer beauftragt wurden, die in Datenbank-Kategorien dachten oder den in der verwendeten PgmierSprache zusätzlichen Aufwand zur Zulassung von Datenfeldern scheuten. Dadurch ist die schizophrene Situation entstanden, dass es in bestimmten Bereichen 2 Typen von Fktt gibt, die nur auf ZellBereiche zugreifen können, aber keine, die auch Datenfelder verarbeiten könnte, so wie es mit dem ursprünglichen Xl-Konzept vorgesehen war. Das hat MS auch mit den Xl-Vss 12+14 nicht korrigiert!
Gruß, Luc :-?
Besser informiert mit …

Beliebteste Forumthreads (12 Monate)

4 Beiträge zum Forumthread Beiträge zu diesem Forumthread

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

4
Beiträge zum Forumthread

Beiträge zu diesem Forumthread