Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen

Das ist eine Java-Exception in Folge eines Programmierfehlers - unter

Am 05.09.2017 um 08:00 schrieb Edzard Egberts:

Interessant.

In der dll LoadUFOS wurde ein Fehler erkannt und gemeldet (Exception = Methode zur nicht lokalen Fehlerbearbeitung), aber nicht von der "eigentlichen" Software (die diese Bibliothek aufruft) abgefangen,

Programmiersprache sein, aber mir ist eben nur von Java bekannt, dass eine nicht bearbeitete Exception gemeldet wird, statt zu einem

Gibt es auch in C++. Da es eine DLL ist, ist das auch wahrscheinlicher, wenn der Herrsteller nicht eins der Programme verwendet hat, was Java Klassen in DLLs verpacken kann.

den Typ der Exception, den Klassennamen, Zeilennummer wo es aufgetreten ist und einen kompletten Call-Stack.

Exceptions abfangen und anzeigen, aber nur als letzten Schritt vor dem Exit, weil ein C++-Programm mit nicht bearbeiteter, unbekannter

werden sollte. Dass eine Software Fehler wirft und trotzdem weiter

eingebauten Speicherverwaltung, unter C++ kann man nicht einfach mal irgend ein Programmteil abwickeln.

Doch, das geht genauso in C++. Der Fehler trat beim Import auf. Man kann dort genauso ein try/catch um die Import-Anweisung schreiben, wie in der

auch weiter. Da das hier eine "EConvertError" Exception war, ist das

Erkennung des eigenen Formats gab, was kein gutes Licht auf die Software

Line3 nicht erkannt" oder so), hat der Programmierer einfach eine EConvertError-Exception geworfen.

usw. ab. Aber da es in C++ keinen Speicherschutz wie in Java gibt, ist

Programm beenden.

Nein, man *muss* den try um die Import-Anweisung legen, denn bis die Exception im Main angelangt ist, kann schon der gesamte Import-Teil

herkommt und wie der zu beheben ist.

Und gibt auch keine seltsamen Meldungen aus.

Genau davon habe ich geredet.

Zur Fehlermeldung kann ich nichts sagen, aber falls sich keine Datenrettung hinbekommen laesst: M.W. wurde Assembleon von Kulicke & Soffa gekauft. In der Hoffung, dass sie aeltere Anlagen und SW weiterpflegen, koenntest Du die vielleicht bitten, Dein Projekt probehalber zu laden. Dann weisst Du zumindest, ob der Defekt bei Deinen Daten oder der installierten Software liegt.

Unwahrscheinlich, waere aber ein Hingucken wert: EConvertError passieren in Buchhaltungs-Software schonmal, wenn auf dem Computer, wo die Software neu installiert wurde, das Datums- oder Zeitformat anders eingestellt ist als auf dem, wo die Daten erzeugt wurden.

Hallo Edzard,

Du schriebst am Tue, 5 Sep 2017 16:04:57 +0200:

Vielleicht, indem die "Lokalisierung" des Systems von wahrscheinlich Deutsch auf Englisch umgestellt wird?

Am 05.09.2017 um 08:00 schrieb Edzard Egberts:

Das Programm ist glaube von 2002.

Aber bei dem Alter ist das ja auch nicht sooo verwunderlich. Aber ob das damals schon Java war... Sieht von der GUI eher nicht so aus.

Am 05.09.2017 um 16:34 schrieb Joerg:

dem OS exportiert worden. Das funktioniert auch soweit.

mehr im Programm machen kann - nur noch im Editor oder an der Maschine.

aber bei jedem Import knallt es dann.

Komische Sache das, echt.

Wenn dies am gleichen PC passiert, sieht es nach Software Bug aus und wie Edzard schrieb, waere V1.6 faellig.

Nicht unbedingt. Solche Software wird nur fuer einen ganz kleinen Markt geschrieben. Das stecken die Firmen nicht beliebig viel in der Validation Phase. Einige sehr grosse Firmen tun das auch bei Software fuer die breite Masse nicht ...

MfG

Sieghard Schicktanz schrieb:

ein Kunde verwendet, die der Entwickler aber nicht vorhergesehen hat.

getrennt von der Sprachen-Lokalisierung so Sachen wie das

Aber ein Fehler ist es wahrscheinlich trotzdem, weil beim Import der eigenen Dateien die gleichen Einstellungen wie beim Export benutzt werden sollten.

fallen einem dabei seltsame Sachen auf.

Ich war mal davon ausgegangen, dass in der Zeit zwischen Datei-Erstellung und Lesen keine Formate geaendert wurden.

Irgendetwas in der Richtung wird's vermutlich sein. Leider ist die Fehlermeldung zu unspezifisch, um dem OP einen Fingerzeig zu geben.

MfG

Das ist auch ein guter Hinweis. NXP hat etwa die schlechte Angewohnheit, bei Bauteilnamen gelegentlich Kommata reinzusetzen wie z.B. bei "BSS123,215". Wenn die aus irgendeinem Gund mit in die Pick&Place Files geraten (sollten sie eigentlich nicht), dann kann es rumms machen.

Das hat Bjoern offenbar eingehalten und dennoch laedt es nicht korrekt.

Auch den zugrundeliegenden XYRS File und die Netlist ansehen, die kann man rasch querlesen. Ich hatte mit Layoutern und Bestueckern schonmal Malessen, weil deren Software irgendein Zeichen nicht frass. Oder sie bekamen eine Meldung a la "Corrupt File", waehrend der hier sauber fluppte.

Hi Ihr.... ICH HABS, ICH HABS :D

Mir ist gerade eben aufgefallen, dass bei der Nutzenerstellung die von der Software selbst eingetragenen Werte angemeckert werden. Als ich dann die Punkte sah, dachte ich an das selbe wie Ihr grade eben (Hab Euren Post aber erst jetzt entdeckt).

mit Punkte gewechselt -> Es tut!

Witzig: Intern meckert die Software die Punkte in den Textfeldern an und beim Laden meckert die Software dann die Kommas an, lach.

Genial. Aber jOErg, das mit den Umlauten ist schon ein Krampf - Kenn ich ganz gut ;)

bjOErn