#WERT! und "Ein in der Formel verwendeter Wert ist vom falschen Datentyp."

  • Excel

Es gibt 32 Antworten in diesem Thema. Der letzte Beitrag () ist von Andreas_500.

    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): im selben Verzeichnis, wo dieses Programm liegt, ...
    oder
    b): im Suchpfad von Windows.

    ChemWings.Tools.dll wird zuerst im Verzeichnis dieser Exe gesucht, erst danach im Suchpfad.
    "Lokal" hat also eine höhere Priorität bei der Suche als "Global"!

    Der komplette Pfad und Name der verwendeten DLL wird zur Information ausgedruckt.

    Das Test-Programm verwendet für die Berechnung die festen Eingabedaten, die bereits aus der Excel-Tabelle bekannt sind und gibt den Betriebspunkt auf Excel’s Double gerundet aus.

    Grüße

    Andreas

    Exe-Dateien sind außerhalb des Showrooms nicht erlaubt, Anhang wurde daher entfernt ~VaporiZed
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „VaporiZed“ ()

    Mein SandBox-PC hat da aber was gegen den Programmablauf der EXE einzuwenden.
    Bilder
    • Error.png

      8,1 kB, 418×175, 68 mal angesehen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    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
    Dateien
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius
    Aah! Und plötzlich funktioniert die DLL auch in Excel bei mir und ich bekomm ein Ergebnis ;)
    Bilder
    • Result.png

      9,17 kB, 1.029×376, 66 mal angesehen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Ä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
    Bilder
    • Bei mir ist es immer noch fehlerhaft.jpg

      30,95 kB, 1.280×720, 65 mal angesehen
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Andreas_500“ ()

    Habe a0 auf 25 geändert und bekomme das im Anhang. Wenn ich eine Verzögerung einbaue, funktioniert es, sonst nicht:
    Verzögerung 1:

    Visual Basic-Quellcode

    1. If BePu(PoKoeff_Rohr(1), n_Rohr, PoKoeff_Pumpe(1), n_Pumpe, V_Strom) Then
    2. MsgBox ""
    3. Betriebspunkt = V_Strom
    4. Else
    5. Betriebspunkt = "NV"
    6. End If


    Verzögerung 2 (sinnfreier)

    Visual Basic-Quellcode

    1. If BePu(PoKoeff_Rohr(1), n_Rohr, PoKoeff_Pumpe(1), n_Pumpe, V_Strom) Then
    2. Stop
    3. Betriebspunkt = V_Strom
    4. Else
    5. Betriebspunkt = "NV"
    6. End If
    Bilder
    • Result.png

      9,24 kB, 1.023×337, 66 mal angesehen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Hallo,
    das ist zwar ganz toll, :thumbsup: ABER es ist nicht normal!

    Stell Dir vor, die Funktion kommt in einer Excel-Mappe 27-mal vor... :thumbdown: 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 in Excel reibungslos laufen. Habe die Berechnung bereits mit Excel 2010, 2016 und 2019 ausprobiert: Überall dasselbe Fehlverhalten, aber nur bei dieser einen einzigen eigenen VBA-Funktion.

    Ich habe auch den Export-Namen in der DLL zig-mal geändert, um Namenskonflikte (??) zu vermeiden, die Routine aus der ursprünglichen DLL in andere verschoben. Ohne Erfolg.

    Diese eine Funktion ist richtig verhext oder erst jetzt kommt ein bisher nicht gesehener Excel-Bug zum Vorschein.

    Was könnte ich noch machen, denn das ist so recht unbefriedigend?

    Danke & Grüße :thumbup:

    Andreas
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Andreas_500“ ()

    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! :saint:

    Viele Grüße :)

    Andreas
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Andreas_500“ ()

    Ich konnte zumindest vorhin erfolgreich ein VB.NET-Testprogramm schreiben, welches keine Verzögerung benötigt. Es scheint also tendenziell eher an Excel zu liegen.

    ##########

    Damit geht's:

    Visual Basic-Quellcode

    1. Vorhanden = BePu(PoKoeff_Rohr(1), n_Rohr, PoKoeff_Pumpe(1), n_Pumpe, V_Strom)
    2. Application.Wait 0
    Aber ich weiß nicht, warum …
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „VaporiZed“ ()

    VaporiZed, Du bist Spitze! :thumbsup: :thumbsup:

    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! :saint:

    Grüße
    Andreas
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius
    Habe gerade die neuesten Office-Updates installiert.
    Leider (oder erwartungsgemäß?) hat Microsoft den von mir vor 4 Wochen gemeldeten Fehler (bisher) nicht behoben … :(

    Andreas
    Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
    John C. Cornelius