Suchergebnisse

Hallo Community, die Fehlermeldung: „Ein in der Formel verwendeter Wert ist vom falschen Datentyp.“ und der Zellen-Inhalt #WERT! bringt mich zur Verzweiflung... Ich habe in Excel 2019 Professional eine VBA-Schnittstelle zu meiner Delphi-DLL. Die VBA besteht im Wesentlichen aus folgenden Teilen: Quellcode (35 Zeilen) Diese Vorgehensweise habe ich in hunderten anderen VBA-Schnittstellen, welche ohne Probleme funktionieren. Nur das hier scheint richtig verhext zu sein. Die Anweisung in der Zeile Qu…

Leider hilft ein Umformatieren der Zelle nicht weiter. Ich hatte auch schon den Windows Defender verdächtigt, aber daran hat es auch nicht gelegen. Bin ziemlich ratlos.

Hallo, Der einzige Rückgabewert ist: Quellcode (1 Zeile) Rohrleitung_Polynom_Koef_Vektor und Pumpe_Polynom_Koef_Vektor sind zwei Input-Vektoren (Array of Double). Array-Parameter verlangen nach meinem Kenntnisstand immer nach ByRef, daher diese Deklaration. Mein Excel 2019 ist eine 32-Bit-Anwendung, ebenso die DLL. Sie laufen unter Windows 10 (64-Bit). Was meinst Du konkret mit „Deklaration mit impliziten Datentypen ist ungewöhnlich …“ ? Den Funktionstype von Quellcode (1 Zeile) habe ich bewußt …

Habe soeben folgende Beobachtung gemacht: Wenn ich die Funktion mit dem Debugger mit <F5>laufen lasse: Quellcode (9 Zeilen) und den Breakpoint in der Zeile Quellcode (1 Zeile) setze, kommt es immer zur Fehlermeldung. Ist der Breakpoint hingegen NUR in der Zeile Quellcode (1 Zeile) gibt es keine Fehlermeldung und es steht das korrekte Ergebnis in der Zelle. Allerdings ist alles wieder futsch, wenn ich die Excel-Arbeitsmappe neu öffne.

Ja es ist meine Delphi-DLL. Die Übergabe von Vektoren (Arrays) von VBA nach Delphi (= zwei total verschiedene Welten) geht leider nur etwas umständlich: Ich muß in VBA das erste Element des Vektors und die Anzahl der Elemente im Vektor als Parameter übermitteln. Ein Delphi-Vektor enthält neben dem eigentlichen Inhalt auch noch Infos über die Länge etc. Und das kann ich in VBA leider anders nicht nachbilden. Darum braucht ein Vektor immer ByRef, weil dadurch eigentlich die Speicheradresse des ers…

Hallo, zunächst die einfachere Antwort: Auf 32-Bit-Ebene sind Delphi’s Integer und VBA’s Long kompatibel. Für den Rest brauch ich etwas Zeit. Danke & Grüße Andreas PS: Die Farben & sonstige Formatierungswerkzeuge sind in meinem Editor leider deaktiviert und ich kann sie (noch) nicht benutzen. Rot habe ich oben spontan per Hand eingefügt. Sorry

Vom Delphi-Debugger aus kann ich die Excel-Anwendung aufrufen und auch schrittweise laufen lassen. Das habe ich mir zum x-ten Male angeschaut und jeden Schritt und jeden Zahlenwert analysiert. Ich kann dabei sehen, wie alle Daten von Excel korrekt in der ChemWings.Flow.dll ankommen, dort alle Berechnungen korrekt ausgeführt werden und das Ergebnis zurück nach Excel geht. In der Variablen V_Strom steht stets das korrekte Ergebnis. Zum Crash kommt es immer dann, wenn nach der DLL-Benutzung mit V_S…

Moment bitte... Anstelle von 70,07 etc steht 71 in der Zelle. PS. Aber beim erneuten Öffnen der Datei steht immer noch #WERT! da Ich werde eine Testanwendung erstellen und die kompletten Dateien im Anhang posten.

Im Anhang befindet sich eine Testanwendung. Danke für Eure Hilfe! Grüße Andreas PS: Lösung: --> Sollwert = 70,074071998727843000

Beim Aufruf der DLL-Funktion mit Vorhanden = BePu(PoKoeff_Rohr(1), 0, PoKoeff_Pumpe(1), 0, V_Strom) und / oder Vorhanden = BePu(PoKoeff_Rohr(1), 1, PoKoeff_Pumpe(1), 1, V_Strom) erhalte ich korrekterweise eine Fehlermeldung aus der DLL (s. Anhang): Fehler! Datenfehler: Länge von Polynom_Koef_Vektor muß im Bereich 1 ... 21 liegen! und im Überwachungsfenster für die Variable V_Strom: V_Strom = 1,#QNAN (= Not a Number), was auch korrekt ist. Die Ergebnisse aus der DLL kommen also in Excel an...

Excel findet eine DLL (leider) nur wenn: a): diese im Verzeichnis C:\Windows\ liegt, oder b): der komplette Pfad angegeben ist. Bitte in Private Declare Function BePu Lib "Kompletter Pfad\ChemWings.Tools.dll" _ den Pfad ergänzen. Grüße, Andreas PS: Die Fehlermeldung der DLL sollte korrekt heißen: Datenfehler: Länge von Polynom_Koef_Vektor muß im Bereich 2 ... 21 liegen!

Zitat: „Hat die DLL weitere, eigene Abhängigkeiten? “ Nein, alles ist in der einen DLL komplett drin. PS: Habe noch eine Idee: Vielleicht muß die DLL im WinExplorer als "vertrauenswürdig" markiert werden, weil sie ja von einem fremden Computer stammt. Im Fenster "Eigenschaften" --> "Allgemein" ganz unten: Sicherheit: --> zulassen

Im Anhang befindet sich ein Konsolen-Programm, um die Funktion BePu der DLL ChemWings.Tools.dll zur Betriebspunkt-Berechnung durch externen Zugriff auf die DLL zu testen. Die Routine BePu der DLL verwendet intern bis zu 200 Nachkommastellen, um Rundungsfehler zu minimieren. Daher können manche Antiviren-Programme fälschlicherweise einen "Virus"-Fehlalarm auslösen. Es ist aber definitiv KEIN Virus! Dieses Test-Programm benötigt ChemWings.Tools.dll als separate Datei auf der Festplatte, entweder a…

Sorry, die Abhängigkeit vom Borland Memory Manager BorlndMM.dll habe ich übersehen. Diese wird hier aber gar nicht benötigt, nur bei der Übergabe von Strings an Excel. Hier hast Du eine aktuelle Version von ChemWings.Tools.dll, die ohne BorlndMM.dll funktioniert. Grüße Andreas

Ändre bitte eine Kleinigkeit an den Zahlenwerten in Excel, um zu sehen, ob die Neuberechnung funktioniert. Oder einfach mit <F2> die Funktion Betriebspunkt noch einmal abschicken. Nicht daß es noch die von Excel gespeicherte Ansicht ist. Denn bei mir kommt immer noch #WERT! Danke & Grüße Andreas

Hallo, das ist zwar ganz toll, ABER es ist nicht normal! Stell Dir vor, die Funktion kommt in einer Excel-Mappe 27-mal vor... Und es ist eh nur ein Zwischenergebnis, mit dem weitergerechnet werden soll... Als "Verzögerung" habe ich auch eine For – Next – Schleife probiert, die aber funktioniert nicht. Deine „Verzögerung“ ist wie das schrittweise Laufenlassen der Routine im Debugger. Dort muss irgendwo der Wurm sein: Das scheint ein Bug in Excel zu sein. Ich habe etliche ähnliche Funktionen, die …

Hallo, soeben habe ich aus Excel’s Feedback einen Verbesserungsvorschlag an MicroSoft geschickt und auf unsere Diskussion hier im VB-Paradise-Forum #WERT! und "Ein in der Formel verwendeter Wert ist vom falschen Datentyp." verwiesen. Mal sehen, ob es diesmal irgendeine Reaktion von MicroSoft darauf gibt. Danke Euch allen für Eure Hilfe! Viele Grüße Andreas

VaporiZed, Du bist Spitze! Im Moment ist es für mich nur noch wichtig, daß es funktioniert. Man muß nicht immer alles verstehen können... Vielen-vielen Dank für Deine Hilfe! Grüße Andreas

Habe gerade die neuesten Office-Updates installiert. Leider (oder erwartungsgemäß?) hat Microsoft den von mir vor 4 Wochen gemeldeten Fehler (bisher) nicht behoben … Andreas

Nur zur Info: auch in den heutigen Office-Updates ist der von mir vor 10 Wochen gemeldete Fehler immer noch nicht behoben … Andreas

Nur zur Info: Auch in den heutigen Office-Updates ist der Fehler immer noch nicht behoben … Andreas