Excel-Arbeitsblatt und Ausdrucksauswertung

Artikel
04/04/2023

Gilt für: Excel 2013 | Office 2013 | Visual Studio

Der Inhalt der Microsoft Excel-Arbeitsblattzelle wird in einen von vier grundlegenden Datentypen ausgewertet:

Zahlen
Boolescher Wert TRUE oder FALSE
Zeichenfolgen
Fehler

Arrays dieser Typen können auch als Argumente für Funktionen oder als Werte, die sich über mehrere Zellen in einer Arrayformel erstrecken, in Formeln eingegeben werden.

Wenn ein Benutzer (oder ein Befehlsmakro) etwas in eine Zelle eingibt, versucht Excel, die Eingabe zu interpretieren, und zeigt eine Fehlermeldung an, wenn dies nicht möglich ist. Wenn die Eingabe mit einem Zeichenfolgenpräfix (einem einfachen Anführungszeichen) beginnt, platziert Excel alle Eingabezeichen in der Zelle ohne Änderung. (Das Zeichenfolgenpräfix wird nicht angezeigt.) Wenn die Eingabe mit =, +oder -beginnt, versucht Excel, die Eingabe als Formel zu interpretieren. Wenn die Syntax falsch ist oder die Auswertung beendet wird, wird ein Fehler angezeigt, und die Zelle wird in den Bearbeitungsmodus versetzt. Andernfalls versucht Excel, Operatoren und Funktionsnamen und deren Argumente zu identifizieren, zu konvertieren und auszuwerten.

Operanden werden von links nach rechts ausgewertet, bevor der Operator angewendet wird. Funktionen werden beginnend mit den Operatoren mit der höchsten Rangfolge und innersten (am meisten geschachtelt) ausgewertet. Wenn Funktionsargumente oder Operanden nicht in die erwarteten Typen konvertiert werden können, schlägt die Auswertung fehl und führt zu einem #VALUE! -Fehler. Wenn ein Token (bei dem es sich nicht um einen Literalwert handelt) nicht als Funktion oder definierter Name oder Bezeichnung erkannt wird, schlägt die Auswertung fehl und führt zu einem #NAME? -Fehler.

Wenn die Eingabe nicht mit einem dieser Dinge beginnt, überprüft Excel anhand bekannter Eingabemuster wie Datumsangaben, Uhrzeiten, Währungsbeträgen, Prozentsätzen oder Zahlen und interpretiert entsprechend. Dies erfolgt auf gebietsschemaspezifische Weise. Wenn keine dieser Interpretationen sinnvoll ist, wird die Eingabe von Excel als Zeichenfolge betrachtet und unverändert in der Zelle platziert.

Excel unterstützt andere Datentypen, von denen ein Bereichsverweis am sichtbarsten ist. Excel konvertiert Bezüge in die Werte der verwiesenen Zellen, wenn Argumente für Operatoren und Funktionen ausgewertet werden, die keine Verweisargumente annehmen, oder wenn der Ausdruck in einer Zellformel auf einen Verweis reduziert wird.

Excel macht die Möglichkeit verfügbar, alle gültigen Zeichenfolgen mit der XLM-Funktion EVALUATE und dem zugehörigen C-API-Äquivalent xlfEvaluate auf einen der vier grundlegenden Arbeitsblattdatentypen zu reduzieren. Diese Funktion bietet unter anderem eine einfache Möglichkeit, benannte Bereiche im DLL-Code auszuwerten. Diese Funktion unterscheidet sich von dem zuvor beschriebenen Verhalten nur darin, dass sie anstelle von Fehlermeldungen oder aktivieren der Zellbearbeitung einen #VALUE! Fehler zurückgibt, wenn die Ausdrucksauswertung fehlschlägt.

Zahlen

Alle Arbeitsblattnummern in Excel werden intern als Gleitkomma mit doppelter Genauigkeit mit 8 Byte dargestellt, einschließlich aller ganzen Zahlen. Die Implementierung dieser Zahlen in Excel ist jedoch nicht vollständig IEEE-kompatibel, wie in der folgenden Tabelle gezeigt.

Typ	Maximum	Minimum
IEEE 8-Byte Double	1.7976931348623157E+308	2.2250738585072014E-308
Arbeitsblatt (zurückgegeben durch Funktion oder Einfügewert)	1.7976931348623157E+308	2.22507385850721E-308
Arbeitsblatt (manuelle Eingabe)	9,9999999999999999999E+307	2.22507385850721E-308

IEEE-Subnormale Zahlen (d. h. Zahlen im Bereich 2,2250738585072009E-308 bis 4,9406564584124654E-324) werden in Excel-Arbeitsblättern nicht unterstützt, werden jedoch von VBA Doubles unterstützt.

Wenn eine DLL-Funktion IEEE +/- unendlich oder ein ungültiges Double zurückgibt, konvertiert Excel es in #NUM!. Alle unternormalen Zahlen und Zahlen, die kleiner als die minimale positive Normalität in Excel sind, werden in positive 0 (null) konvertiert. Ieee negativer Null wird unterstützt, d. h., es kann von einer DLL-Funktion zurückgegeben werden und wird als -0 angezeigt. (Der < Operator überprüft nicht auf negative Null, und daher wird =A1<0 als TRUE ausgewertet, wenn A1 eine negative Null enthält).

Beachten Sie, dass bestimmte Zahlenformate engere Grenzwerte aufweisen als diese, z. B. Datums- und Uhrzeitangaben. Die Ganzzahlteilung ist in der Tat Gleitkommateilung und kann in Extremfällen zu einem Ergebnis führen, bei dem das genaue Ergebnis eine ganze Zahl sein sollte.

Lange Unicode-Zeichenfolgen

Alle Zeichenfolgen, die dem Benutzer in Excel angezeigt werden, wurden in vielen Versionen nun intern als Unicode-Zeichenfolgen gespeichert. Unicode-Arbeitsblattzeichenfolgen können bis zu 32.767 (2¹⁵ bis 1) Zeichen lang sein und jedes gültige Unicode-Zeichen enthalten.

Als die C-API zum ersten Mal eingeführt wurde, waren Arbeitsblattzeichenfolgen Bytezeichenfolgen, die auf 255 Zeichen beschränkt sind, und die C-API spiegelte diese Einschränkungen wider. In Excel 2007 wird die C-API aktualisiert, um lange Unicode-Zeichenfolgen in Excel zu verarbeiten. Dies bedeutet, dass DLL-Funktionen, die auf die richtige Weise registriert sind, Unicode-Argumente akzeptieren und Unicode-Zeichenfolgen zurückgeben können.

Hinweis

Bytezeichenfolgen werden in der C-API aus Gründen der Abwärtskompatibilität weiterhin vollständig unterstützt. sie haben jedoch immer noch den gleichen Grenzwert von 255 Zeichen.

Zurückgeben von Fehlern

Excel wertet Zellen zu Fehlern aus, bei denen Funktions- oder Operatorargumente nicht in den richtigen Typ konvertiert werden können oder wenn eine Funktion oder ein definierter Name nicht erkannt wird. Beide Szenarien wurden zuvor beschrieben. Wenn die integrierten Arbeitsblattfunktionen und -operatoren fehlschlagen, führen sie auch zu Fehlern, die den Benutzer über die Art des Fehlers informieren. Sie sollten über eigene Add-In-Funktionen verfügen, die Fehler zurückgeben, die mit dem Verhalten in Excel konsistent sind.

#NULL!

Der fehler #NULL! wird von einigen XLM-Informationsfunktionen zurückgegeben. Beispiel: Aufrufen von GET. DOCUMENT(78) oder die entsprechende C-API-Funktion xlfGetDocument mit dem Argument 78, wenn keine Drucker installiert sind, führt dazu, dass dieser Fehler zurückgegeben wird. Es kann auch von einigen Funktionen zurückgegeben werden, wenn sie z. B. eine leere Zeichenfolge auswerten.

Möglicherweise möchten Sie diesen Fehler von Ihrer Add-In-Funktion zurückgeben, wenn keiner der anderen Fehler angemessen erscheint.

#DIV/0!

Der Excel-Divisionsoperator gibt den fehler #DIV/0! zurück, wenn der Nenner 0 (null) ergibt oder eine Zahl zu klein ist, um von Excel als ungleich 0 dargestellt zu werden. Einige Funktionen, die per Definition eine Division umfassen, können diesen Fehler ebenfalls zurückgeben. Beispielsweise gibt AVERAGE diesen Fehler zurück, wenn keine der Eingaben in Zahlen konvertiert werden kann.

Sie sollten nur in Betracht ziehen, diesen Fehler von Ihrer Add-In-Funktion zurückzugeben, um anzugeben, dass eine Division durch 0 (null) erkannt wurde.

#VALUE!

Excel gibt den fehler #VALUE! zurück, wenn eine Funktion oder ein Operatorargument nicht in den erforderlichen Typ konvertiert werden kann. Bei Funktionsargumenten, die nicht konvertiert werden können, z. B =LN("X"). , ruft Excel den Funktionscode nicht auf. Dies ist ein wichtiger Punkt, den Sie beim Schreiben und Debuggen Ihrer eigenen Add-In-Funktionen beachten sollten.

Einige Funktionen geben diesen Fehler zurück, wenn ein Argument nicht innerhalb des Funktionscodes konvertiert werden kann. Beispielsweise schlägt mit diesem Fehler fehl, DATEVALUE("30-Feb-2007") obwohl das Argument den richtigen Typ aufweist. In diesem Fall gibt die Funktion den Fehler aus ihrem Code zurück. Einige Funktionen geben diesen Fehler zurück, obwohl die Werttypen und Bereiche zulässig sind, z. B FIND("a","xyz") . diesen Fehler zurückgeben.

Sie sollten erwägen, diesen Fehler von Ihrer Add-In-Funktion zurückzugeben, um anzugeben, dass die Argumente vom falschen Typ sind, nicht in den richtigen Typ konvertiert werden konnten oder außerhalb des Bereichs liegen, obwohl Sie erwägen sollten, #NUM! für numerische Argumente außerhalb des Bereichs zurückzugeben. Sie sollten auch in Betracht ziehen, diesen Fehler zurückzugeben, wenn Bereichs- oder Arrayargumente die falsche Form oder Größe aufweisen.

#REF!

Excel generiert den #REF! -Fehler innerhalb eines Ausdrucks, wenn er an eine Position kopiert wird, an der der resultierende relative Verweis außerhalb der Grenzen liegt. Wenn z. B. die Zelle B2 die Formel =A1enthält, ergibt das Kopieren in Zelle B1 die Formel =#REF!. Dieser Fehler wird auch in Formeln generiert, die einen Verweis enthalten, der bei einem Ausschneide- und Einfügevorgang überschrieben oder in einer Zeile, Spalte oder einem Löschvorgang eines Arbeitsblatts gelöscht wird. Einige Funktionen, die Verweise zurückgeben können, können diesen Fehler zurückgeben, z. B OFFSET(A1,-1,-1). . Arbeitsblattnamen, deren Definitionen ungültige Verweise enthalten, werden auf diesen Fehler ausgewertet.

Wenn Ihre Add-In-Funktion Verweisargumente akzeptiert, sollten Sie in Betracht ziehen, diesen Fehler zurückzugeben, wenn die Verweise ungültig sind oder wenn Ihnen ein Verweisfehler übergeben wird. Im Abschnitt zu XLOPER/XLOPER12s in der Speicherverwaltung in Excel wird beschrieben, wie Funktionen erstellt werden, die Verweisargumente akzeptieren und zurückgeben können.

#NAME?

Excel generiert den #NAME? -Fehler, wenn ein Ausdruck ein Token enthält, das nicht als Funktion oder definierter Name erkannt wird. Wenn Ihre Add-In-Funktion versucht, auf einen definierten Namen zuzugreifen, und dieser nicht definiert ist, sollten Sie erwägen, diesen Fehler zurückzugeben.

#NUM!

Viele der integrierten numerischen und mathematischen Funktionen in Excel geben den #NUM! Fehler zurück, wenn eine numerische Eingabe außerhalb des zulässigen Bereichs liegt, LN(0)z. B. . Sie sollten erwägen, diesen Fehler von Ihrer Add-In-Funktion zurückzugeben, um anzugeben, dass eine numerische Eingabe ungültig oder außerhalb des gültigen Bereichs war.

#N/A

Der #N/A-Fehler wird häufig zurückgegeben, um anzuzeigen, dass ein erfolgreiches oder aussagekräftiges Ergebnis nicht verfügbar ist. Beispielsweise gibt MATCH mit dem dritten Argument 0 (null) diesen Fehler zurück, wenn keine genaue Übereinstimmung gefunden werden kann. Dieser Fehler kann auch mithilfe der Funktion NA generiert und speziell mit der Funktion ISNA erkannt werden. Es handelt sich daher um einen häufig verwendeten Fehler in Arbeitsblättern, um einen Bereich von anwendungsspezifischen Bedingungen anzugeben.