LAMBDA Bug Test

[maninweb]

Moin,

mir scheint es so, dass ein Bug in LET und LAMBDA vorhanden ist und zwar wenn LAMBDAs an weitere LAMBDAs übergeben werden.
Bevor ich das jedoch an das Excel-Team weitergebe, möchte ich euch zunächst fragen, ob das bei euch ebenfalls auftritt.
Wenn ihr das testet, bitte keine weiteren Excel-Dateien offen haben, denn der Fehler kann zum Excel-Absturz führen

Im ersten Schritt bitte eine neue Datei erstellen und im Bereich A1 bis A3 die drei Zahlen 1, 2 und 3 eintragen.
Danach einmal folgende LAMBDA-Funktion z.B. in B1 eingeben.

Code:

=LAMBDA(Data;LET(V;Data;D;LAMBDA(V;V-1);S;LAMBDA(V;V+1);M;LAMBDA(X;Y;D(X)*S(Y));Result;M(V;V);Result))($A$1:$A$3)

Es wird ein dynamisches Array angezeigt, funktioniert also. Die Datei nun speichern, als Dateiformat XLSB wählen.
Danach Excel komplett schließen. Und die Datei wieder öffnen. Das müsste danach wie folgt aussehen. 
Ist das bei euch der Fall?

   

Wenn dann versucht wird, die Datei zu speichern, erscheint eine Fehlermeldung oder Excel verabschiedet sich.
Die Datei ist hinüber, solange man die LAMBDA nicht löscht.

Gruß

[LCohen]

Hallo maninweb,

ich denke mal, dass die bei MS noch daran arbeiten. Auch die Rekursionstiefe soll ja noch nicht sonderlich groß sein. Die Verschachtelung von LAMBDA in anderen LAMBDA bedeutet doch auf den ersten Blick, dass man eine mögliche Modularisierung aufgibt, die man hätte, wenn man auf externe andere LAMBDAs zugreift (natürlich jeweils mit dem Nachteil, dass man alle LAMBDAs in der Datei definieren muss).

Ansonsten kann ich Deine Beobachtungen nachstellen. .XLSB zeigt nur ein =, .XLSX weiterhin die ganze Formel.

[maninweb]

Hi LCohen,

vielen Dank für den Test!

Schon richtig, zumal die LAMBDAs ja noch Beta sind. Meine Tendenz wäre nicht ganz, anzunehmen, ob die Modularisierung dadurch hinüber wäre, aber vielleicht täusche ich mich da ja.
Ich hatte das Problem beim Experimentieren mit JSON.TORANGE gefunden, wo die Idee ursprünglich war, 2 LAMBDAs als Hilfsfunktionen X und Y auf höhere Ebene zu erstellen und diese
dann innerhalb von mehreren weiteren LAMBDAs zu verwenden. Excel parst das ja auch korrekt zum Zeitpunkt der Erstellung, beim Einlesen scheint es dann zu haken.

Gruß

[Kuwer]

Hallo,

ich kann es zwar nicht testen, aber da das Problem nur in Makrodateien auftritt, könnte es ja vielleicht Konflikte mit Excel4-Makros geben?

Gruß Uwe

[maninweb]

Moin Uwe,

nee, hat wohl eher nichts mit Makros zu tun. LAMBDAs sind reine Excel-Funktionskonstrukte. Es empfiehlt sich (derzeit) XLSB für LAMBDAs deswegen zu verwenden,
weil es eine Limitation für LAMBDAs gibt, was die Länge einer möglichen Formel betrifft. Das kann XLSB besser handeln als XLSX. Sollte sich aber später nach der
Beta dann ändern.

Gruß

[maninweb]

Moin,

es handelt sich um einen Bug. Das Excel-Team schaut sich das nun detaillierter an und wird es dann beheben :-)

Gruß

[LCohen]

Kuwers Excel4Makrofunktionen-Hinweis war nicht schlecht:

Man kann bei einer geöffneten .xlsx auch ein LAMBDA mit Excel4Makro-Funktion (wie etwa AUSWERTEN) benennen (unbenannt geht es dann nicht) und sogar nutzen. Vermutlich durch den Versuch des automatischen Speicherns (was ja dann nicht funktionieren darf) entsteht jedoch das einzelne = (Gleichheitszeichen) im Namen-Definieren-"bezieht-sich-auf".

Beim anschließenden "Irgendwas-Tun" nach erneutem Öffnen stürzt die Datei dann ab.

Wird aber vermutlich, während ich dies hier schreibe, schon repariert. Das automatische Speichern dürfte halt bei einer .xlsx mit XL4M nicht sein.

[maninweb]

Moin,

das ist sehr interessant. Klingt für mich zusätzlich auch so, als wäre das noch ein weiterer Bug. Ich muss das mal bei mir auch ausprobieren.

Hast Du schon die neue Option im Trust-Center, wo man die Excel 4.0 Makros abschalten kann? Wäre interessant rauszufinden, ob die
Option Einfluss auf die Lambdas hat. Hinweis: bei einigen Usern kann es sein, dass die Option sich genau gegenteilig zu dem verhält,
wie der Text der Option suggeriert.

Gruß