Urwigo - persönlich meist-gefürchteter Super-GAU eingetreten

[Schnatterfleck]

Es gab immer eine Befürchtung, die mir bei der Benutzung von Urwigo etwas Bauchweh bereitet hat:
Es gibt meines Wissens keine Alternative, die mit den Projekten was anfangen kann; zum Anzeigen und Editieren bin ich also auf das Programm festgelegt.

Sollte aber einmal irgendwas damit Schiefgehen (nicht rückwärts-kompatible Änderungen am Programm, Installationsfehler, Probleme mit den benutzten Bibliotheken, Fehler beim Erstellen des .urwigo-Files,...) stände ich da mit einem (im schlimmsten Fall halbfertigen) .urwigo, das ich nicht mehr abändern kann.

Jetzt ist genau der Fall bei mir eingetreten: Ich habe einen alten WIG, bei dem ich etwas ändern will. Öffnen lässt er sich auch. Versuche ich aber nun, bei einem vorhandenen Command den Handler anzuklicken, hängt sich Urwigo komplett auf (Last auf einem der CPU-Kerne geht auf 100%, Urwigo reagiert gar nicht mehr).

Hat einer von Euch schon einmal ähnliche Probleme gehabt? (Und vielleicht sogar gelöst...? )

Im Moment habe ich es geschafft, die gewünschten paar kleineren Änderungen an der Cartridge über eine direkte Manipulation des xml-Codes im .urwigo zu berwerkstelligen, aber bei komplexeren Änderungen geht das natürlich nicht mehr...

 

[jonny65]

Probleme mit dem Schnurrer ?

So viele Klicks und noch keine Antworten...vermutlich hatte noch niemand ein vergleichbares Problem, ich ja auch nicht, aber schreib trotzdem mal irgendwas. :/

Ich sag jetz einfach, daß das nicht an Urwigo liegt und wenn doch indirekt, dann sind es "äußere" Einflüsse wie korrupte Installation oder Sourcen. Aber dafür kann Urwigo ja nix, wenn z.b eine DLL auf der Festplatte geschrottet ist. Und abwärts kompatibel war es immer. Ich hab meinen 1. Wherigo im GC Builder angefangen und dann in Urwigo importiert, das war mit der Steinzeitversion 1.12.4091.37853. Diese Sourcen lassen sich auch jetzt einlesen mit der aktuellsten Version.

Einziges Phänomen war mal, als mir jemand seine Sourcen per EMail geschickt hat, daß die 1. Zeile so aussah :

?<?xml version="1.0" encoding="utf-8"?>

statt so :

<?xml version="1.0" encoding="utf-8"?>

Nur dieses "?" zu viel reicht ja, um die Sourcen nicht mehr öffnen zu können. Aber auch hier war natürlich Urwigo nicht die Ursache.

Es ist doch aber bei jeder Applikation so, daß sie eine Datei nicht öffnen kann, wenn sie fehlerhaft ist oder auch umgekehrt und keine andere Applikation, die das gleiche Format lesen kann, könnte diese defekte Datei öffnen. Wenn ein JPG Bild binär geschrottet ist, dann geht es nicht auf, egal in welchem Viewer.

Wäre auch mal interessant, was sich denn verändert hat bzw. was in der XML geändert werden musste, damit sie sich wieder öffnen ließe. Oder kannst die Sourcen mal anhängen ? Wenn bei anderen alles ok ist, dann ist definitiv deine Urwigo Installation korrupt.

Eine 2.Urwigo Installation, evtl. sogar mit einer anderen Version z.b in einer virtuellen Maschine kann auch ganz nützlich sein.

 

[Schnatterfleck]

Probleme mit dem Schnurrer ?

Miau... äääääh... ja.

Wäre auch mal interessant, was sich denn verändert hat

Änderungen am Sourcecode kann ich ausschliessen. Ich verwende ein Versionskontrollsystem (svn) zur Sourcecodeverwaltung. Es ist exakt die selbe Version, die vor einem Jahr noch problemlos tat...

Wobei das Schnurrer-Projekt zwar schon ziemlich durcheinander ist (war halt mein erster WIG-Versuch...) - Allerdings treten ähnliche Probleme auch bei einem anderen Projekt auf. Dort fängt sich das dann aber nach 'ner halben Minute wieder und danach geht's dann.

Ich bin mir deshalb sehr sicher, dass es nicht am Sourcecode selbst liegt (Parsen kann Urwigo ihn ja anscheinend und kompilieren funktioniert auch problemlos...), sondern das beim Versuch der Darstellung bestimmter Dinge irgendwas schief geht.

Insgesamt sieht mir das ein bisschen nach einem "busy-waiting"-Effekt aus, bei dem nicht auf einen timeout überprüft wird oder womöglich Rückgabewerte nicht vollständig ausgewertet werden.
Und das kann dann schon an Urwigo liegen. Oder evtl. an einer der Libraries, die Urwigo einbindet (wobei ich davon ausgehe, dass externe Libraries praktisch immer besser getestet sind als die Anwendungen, die darauf aufsetzen...).

Ich habe halt womöglich das Pech, dass zufällig nur auf meiner alten Kiste eine ungünstige Timing-/Rückgabewert-/Sonstwas-Kombination auftritt, die halt nicht abgefangen ist aber ausser mich sonst niemanden stört.

Inzwischen nutze ich übrigens unter anderem wegen dieser Single-Point-of-Failure-Problematik wieder den Groundspeak'schen Editor.
(Ein anderer Grund ist z.B. auch die mäßige Eignung von Urwigo-Projekten für die Änderungskontrolle)

Solange ich also nur Kleinigkeiten an meinen bestehenden mit Urwigo erstellten Cartridges vornehmen muss, kann ich notfalls damit leben.
Aber besser wäre natürlich schon, den Fehler zu finden

 

[Charlenni]

Es bleibt bei der Antwort noch die Frage offen, ob Du es schon einmal auf einem anderen Computer versucht hast. Eventuell auch mit einem anderen Betriebssystem. Einfach um auszuschließen, dass es an irgendwelchen Einstellungen liegt. Vielleicht den Vorschlag von Jonny65 annehmen und die Urwigo-Datei jemand anderem zur Begutachtung schicken? Wenn nicht Jonny65, dann mir . Vertraulichkeit garantiert.

Und das mit der Versionsverwaltung und Urwigo verstehe ich nicht ganz. Ich habe bis jetzt geglaubt, dass es sich bei der Urwigo-Datei um eine reine XML-Datei handelt, die so eigentlich bestens geeignet sein sollte. Aber vielleicht habe ich ja etwas übersehen.

 

[Schnatterfleck]

Es bleibt bei der Antwort noch die Frage offen, ob Du es schon einmal auf einem anderen Computer versucht hast.

Ich bin mir zwar schon sehr sicher, dass es vom Rechner abhängig ist.
Leider (oder auch nicht ) läuft auf meinem zweiten Rechner seit letztem Jahr nicht mehr Windows sondern Linux - da ist schlecht mit ausprobieren.
Um eine Abhängigkeit vom Projekt doch ausschliessen zu können, kann ich Jonny65 und Dir aber gerne mal das alte Projekt zusenden, sobald ich dazu komme.
Ist nicht geheim

[..]Versionsverwaltung und Urwigo[..] Ich habe bis jetzt geglaubt, dass es sich bei der Urwigo-Datei um eine reine XML-Datei handelt, die so eigentlich bestens geeignet sein sollte.

Jain. An sich ist XML natürlich schon mal besser als ein Binärformat.
Allerdings wird die XML-Datei von Urwigo jedesmal komplett neu aufgebaut, sobald Du etwas größeres änderst (z.B. etwas einfügst). Dabei werden auch die Keys der Objekte neu verteilt.
Dadurch hast Du quer über die gesamte Datei verstreut Differenzen zwischen den Versionen, die aber eigentlich nichts zu sagen haben und gar nichts mit der eigentlichen Änderung zu tun haben.

Das macht ein Diff zwischen Versionen aber schon mal deutlich schwerer lesbar (ist mit dem XML sowieso schon nicht so doll...).
Und komplexere Sachen, wie z.B. Merges zwischen parallelen Varianten-Branches kannst Du im Prinzip komplett vergessen...

 

[azteke]

Ich habe seit einem der letzten Updates das Problem, dass Urwigo beim Öffnen von etwas komplexeren Fenstern endlos braucht, bis etwas passiert, vielleicht ist dein Problem ähnlich? Auf meinem PC läuft Win7 Pro 64, der Prozessor ist ein i7 Q720, 8 GB RAM, sollte also eigentlich kein Problem sein. Allerdings habe ich das Problem dann über VirtualPC und den XP-Mode in den Griff bekommen, jetzt läuft alles so wie es sollte. Ich hatte vor längerer Zeit mal den Programmierer von Urwigo angeschrieben, der meinte es könnte mit irgendwelchen Grafik-Bibliotheken zusammen hängen, aber letztendlich lösen konnte er das Problem auch nicht.

 

[Schnatterfleck]

Ich habe seit einem der letzten Updates das Problem, dass Urwigo beim Öffnen von etwas komplexeren Fenstern endlos braucht, bis etwas passiert, vielleicht ist dein Problem ähnlich?

Exakt genauso ist es bei mir. Allerdings schon länger. Und bei einem Projekt kommt er jetzt seit neuestem halt gar nicht mehr aus dem Warten raus.

Auf meinem PC läuft Win7 Pro 64, der Prozessor ist ein i7 Q720, 8 GB RAM, sollte also eigentlich kein Problem sein.

Ich habe hier nen Core-2-Duo mit zwo Gig und Win7 Home Premium (auch 64 Bit).
Wahrscheinlich ist das Problem wegen der geringeren Leistungsfähigkeit schon etwas früher aufgefallen.
Andererseits haben unsere Systeme dann auf den ersten Blick nichts gemein, liegen ja quasi ganze Hardware-Generationen dazwischen.

Allerdings habe ich das Problem dann über VirtualPC und den XP-Mode in den Griff bekommen, jetzt läuft alles so wie es sollte.

Die Möglichkeit habe ich mit der Home-Variante ja leider nicht. (Und um dafür eine "echte" VM z.b. mit Virtualbox zu erstellen, fehlt mir die Leistungsfähige Hardware sowie die Motivation...)
Ich hoffe halt, dass der alte WIG nur noch kleine Anpassungen braucht, für die ich direkt die xml-Datei manipulieren kann...

Ich hatte vor längerer Zeit mal den Programmierer von Urwigo angeschrieben, der meinte es könnte mit irgendwelchen Grafik-Bibliotheken zusammen hängen, aber letztendlich lösen konnte er das Problem auch nicht.

Habe ich ja auch schon vermutet... Irgendwelche Probleme mit Bibliotheken, die er benutzt. Vielleicht liegen die zufällig auf unseren Systemen in einer problematischen Version vor...

Am abgespeicherten Projekt selbst liegt es übrigens definitiv nicht. Jonny65 war so freundlich, sich mehrere Versionen meines Projektes auf seinem Rechner anzuschauen. Dabei sind bei ihm keine der von mir beobachteten Probleme aufgetreten.
(Danke noch mal an Jonny65 für die Unterstützung!)