Hi,
man soll es kaum glauben. Ich habe mir ein UPdate der Subscription zugelegt und eingespielt. Dummerweise bekomme ich jetzt beim Kompilieren einen Fehler mit dem ich nichts anfangen kann ...
Hallo Werner,
ich habe ja nichts verändert und komp. ohne die WB direkt auf der CMD-Ebene mittels Batchdatei. Der Fehler tritt aber sowohl mit der WB als auch auf der CMD Ebene auf.
Mit der Version 2.00.554 gehts noch (2. Rechner). Ich bin mir allerdings nicht ganz sicher, ob ich nach dem WIn10 Upgrade auf 1803 Build 17134.48 schon mal komp. hatte.
Die Fehlermeldung ist immer die Gleiche. Sieht so wie ein Win-Problem aus... Vielleicht keine Schreibrechte auf TEMP, aber ich bin ja der Admin ...
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Das Schreiben passiert im Userverzeichnis von wbogo!
Wenn Du die Workbench als Administrator (der extra Eintrag im Startmenü!) gestartet hast, hast Du dort keinen Zugriff.
Ich habe hier das gleiche Problem anders herum - ich nutze die Workbench als Hauptbenutzer. Wenn ich aber 3pp-DLLs neu bauen muss (XClass++), muss ich das als Admin tun, da ich sonst in dem ProgramFiles-Verzeichnis, in dem die erzeugt werden, keine ausreichenden Rechte habe. Wenn ich die Admin-Workbench starte, werde ich immer angemotzt, dass ich mit einer nicht-aktivierten Version arbeiten würde (was ja nicht ganz korrekt ist, aber egal).
Lange Rede kurzer Sinn: Wenn Du als wbogo die Workbench startest, dann klappt das bei dir auch! Es sei denn, ein Virenscanner funkt dazwischen...
Hallo Martin,
der Fehler tritt auch auf wenn ich ohne die Workbench auf der CMD-Ebene mit einer Batch-Datei kompiliere (wie ich das schon immer getan habe).
Der WIN-user ist immer der gleiche (ist halt einer mit Admin-Rechten wie man es halt immer macht (und nicht machen sollte ..))
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
mit dem UPdate-Manager in der Workbench hatte ich nur den Build 918 runtergeladen und installiert aber nicht alle Vorgänger wie 888, 906 usw. Könnte es daran liegen? Müßte ich alle Builds nachladen?
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Wolfgang_B hat geschrieben: ↑So, 27. Mai 2018 21:41
mit dem UPdate-Manager in der Workbench hatte ich nur den Build 918 runtergeladen und installiert aber nicht alle Vorgänger wie 888, 906 usw. Könnte es daran liegen? Müßte ich alle Builds nachladen?
ich kenne die Fehlermeldung anders bezw. an anderer Stelle, im Debugger in einer Zeile mit DLLLOAD(), die EXE ohne Debugger stürzt ohne Meldung einfach ab. DLLLOAD() versucht eine DLL zu laden die ich seit Jahren verwende.
Ich bin dann von 918 zu 886 zurück das schien mir z.Z. einfacher als den Support zu fragen. Das braucht auch immer Zeit ....
ich habe jetzt mal die Builds durchprobiert. Bis zum Build 623 funktionierts. Ab Build 644 kommt der Fehler. Schon sehr seltsam. Warum nur bei mir? Der Build 644 stammt vom 10.12.2015! Anscheinend hängt das doch mit WIN10 1803 zusammen?!
Ich werde mal Alaska kontaktieren ..
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
Hi Werner,
für mich war die ehemalige CMD jetzt die Powershell. Deswegen hat das nicht geklappt. Der Alaska-Support hat mich dann auf meinen Fehler gebracht. Dann kam die entsprechende Fehlermeldung.
Der Support sagt das gleiche wie Du. Ich solle alles deinstallieren und komplett neu installieren. Hab ich gemacht und siehe da -> der gleiche Fehler. Ich rufe keine eigenen DLL auf (hab ich gar nicht!). Habe dann nochmals alles deinstalliert und mir die Version 2.0 906 von Alaska runtergeladen. Hat aber nichts genutzt. Fehler immer noch da.
Bis einschl. Build 2.0 623 funktionierts ja. Nur ab da nicht mehr.
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
wie kann man denn herausfinden, ob und in welcher DLL sich eine Funktion befindet?
Ich mach das mit dem Total-Commander indem ich nach der Funktions-Zeichenkette in *.DLL suche.
Ob die DLL dann diese Funktion auch "exportiert", kann man zb. mittels DLL-Export-Viewer von NirSofer feststellen: http://www.nirsoft.net/utils/dll_export_viewer.html
so, Problem mit Hilfe des Alaska-Supports gelöst. (Übrigens ein sehr netter und hilfsbereiter Supporter).
Asche auf mein Haupt!!!
War alles meine Schuld. Ich hatte die alte Runtime sowie den Compiler, Linker in meinem aktuellen Arbeitsverzeichnis. Damit griff "pbuild" natürlich auf meinen "alten" Compiler zu und nicht auf den im Alaska-Verzeichnis. Jetzt funktioniert alles wieder.
Danke an alle Hilfsversuchende
Beste Grüße
Wolfgang
Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück