RagTime-Forum
Pdf-Erzeugung mit dem Distiller
Fehlernummer -2145413096, Datei kann nicht geöffnet werden.
Hallo Allerseits.
Zunächst vorweg folgende Anmerkung, dass dieses Problem schon öfters hier im Forum angesprochen wurde – z.B. hier:
http://experts.ragtime.de/ex
http://experts.ragtime.de/ex
http://experts.ragtime.de/exp
Jetzt zu meiner akuten Fallbeschreibung – ein Bekannter (Mac OS X, RT 6), fragte mich wegen dieses Problems nach Hilfe. RagTime war seinen Beschreibungen nach, während der Bearbeitung einer Datei abgestürtzt. Danach ließ sich diese Datei dann nicht mehr öffnen. Ich habe zunächst natürlich einfach versucht, die betreffende Datei mit der aktuellen 6.0.2 Version als auch mit der noch in der Beta-Phase befindlichen 6.5er Version zu öffnen. Dann habe ich auch den Weg über die Vorratskammer versucht, aber leider ohne Erfolg, die Fehlermeldung mit der obene genannten Fehlernummer blieb in allen Fällen immer gleich.
Was kan man jetzt noch machen? Gibt es nicht ein Möglichkeit den Inhalt mit einem anderen Programm auszulesen oder den Import solcher Dateien in RagTIme zu erzwingen?
Unabhängig von etwaigen Lösungsansätzen stelle ich hier aber mal die Frage, wie es zu solchen eklatanten Datenverlust überhaupt kommen kann? Ist es nicht seitens der Programmierung möglich solche preventiv und aktiv zu verhindern?
Ich stelle mir dazu jetzt mal ganz laienhaft folgenden Workflow vor:
Angenommen man öffnet eine RT-Datei mit dem Zustand -A-. Jetzt fängt man an darin Bearbeitungen zu machen. Nach einer Weile speichert man die Datei ab, wobei die Änderungen samt dem vorher vorhanden Inhalt in eine neue temporäre Datei geschrieben werden. Erst, wenn das speichern dieser neuen temporären Datei als Zustand -B- erfolgreich abgeschlossen wurde, wird Zustand -A- definitiv durch den Zustand -B- ersetzt.
Jetzt betrachte ich dazu die evtl. auftretenden Störungen:
Störung Z1: Mitten beim Speichern gibt es einen Stromausfall. Nach meiner oben beschrieben Logik sind natürlich die letzen Änderungen verloren, jedoch ist ja der Zustand -A- ja immer noch unangetastet vorhanden, so dass diese ohne Problem wieder geöffnet werden könnte.
Störung Z2: Der Absturz/Stromausfall passiert just in dem Moment, wo die temporäre Datei als Zustand -B- als erfolgreich gespeichert registriert wurde, jedoch das Ersetzen mit dem Zustand -A- noch nicht gänzlich durchgeführt wurde. Auch in diesem Fall muss es eine vollständig intakte RT-Datei Version geben, die jedoch noch den Status einer Temp-Datei trägt, sprich wahrscheinlich als unsichtbare Datei existiert!? In diesem Fall müsste man diese Datei nur manuell finden können, aber für den User bedeutete das, dass es eigentlich keine "ganzen" Dateiverluste geben kann.
Ausgehend davon, dass mein hier vorgestellter Workflow theoretisch, wie praktisch funktionieren würde, frage ich mich also, wie das Speichermanagement seitens RT gelöst ist? Ist es nicht die wichtigste Aufgabe eines Programms, eine redundante Speicherung vorzuhalten? Gerade RT-Dateien werden sehr oft wohl auch wichtige Geschäftszahlen, Kundenkontakte und andere sensible Daten enthalten, so dass einem der totale Verlust einer solchen Datei schon schwer "treffen" kann. Bei meinem Bekannten waren es z.B. die Daten zu den laufenden Aufträgen dieses Jahres. Wie kann es also passieren, dass dieser hier beschriebene Datenverlust unter RT überhaupt immer wieder passiert?
Andere Programme bieten heute üblicherweise die Möglichkeit, dass man ein festes Interval zum automatischen Speichern einstellen kann. Keine Frage, der Eine mag sowas, der Andere nicht. Aber als optionale Einstellung sollte es evtl. auhc bei RT vorhanden sein.
In der "RagTime Referenz" steht zum Thema "Sichern" folgendes:
«Sie sollten Ihre Arbeit in regelmäßigen Abständen und vor Änderungen, die Sie eventuell nicht behalten möchten, abspeichern. Es ist außerdem empfehlenswert, besonders wichtige Dokumente zusätzlich als „Backup“ auf einer separaten Diskette oder in einem für diesen Zweck
reservierten Server-Ordner zu speichern.»
Zugegeben hat diese Empfehlung ntürlich immer und unabhängig von RT seine Berechtigung, denoch glaube ich, dass RT hier beim speichern scheinbar einen unsicheren, schwebenden Zustand von Dateizuständen zulässt, was eigentlich nicht sein dürfte, oder?!
Ich arbeite u.a. auch viel mit anderen Programmen, wo ich es eigetnlich noch nicht erlebt habe, dass ein Prgramm selber seine eigenen Dateien "zerschießt". Wo liegt also der Fehler hier. Beim User oder beim Programm?
Ich würde mir wünschen, wenn man dazu hier mal ein offizielles Statement bekommen würde, denn wie schon geschrieben, ist dieses Verhalten schon seiten längerem existent und wurde auch des öfteren hier beschrieben. Jedoch bisher ohne wirkliche Lösung.
Vielen Dank an dieser Stelle für Eure Hilfe.
Mit freundlichen Grüßen,
Andreas (Appletiser)
Rechenblatt im Rechenblatt
Feststellen des Pfades einer geöffneten RT-Datei innerhalb von AppleScript
Re: Besondere Seite durch Druckknopf anzeigen
SetzeZelle & RechneText
Ich habe bei folgendem Script staendig einen Absturz, wenn ich es mit 'RechneText' ausfuehren lasse:
Text('SetzeZelle(Verbinden(Ze
Habe Ragtime 6.0.2 mit den Erweiterungen als Demo
Wenn ich den Errechneten Text als Formel eingebe:
SetzeZelle(Verbinden(Zeichen(
funktioniert alles!
Hmmm wieder so ein RagTime Problem - schade, dass das Programm so 'sensibel' auf alles reagiert.
Thomas
Besondere Seite durch Druckknopf anzuzeigen
Wunsch für automatische Fenstergröße
Hallo Allerseits.
Wie seht Ihr das? Ich nutze RT 6.x am Mac (OS X) und seit jeher stolpere ich über das Fensterverhalten von RT, u.a. wenn ich z.B. bei einem Rechenblatfenster den kleinen grünen Knopf zur automtischen Größenanpassung klicke.
Dann nämlich wird dieses Fenster abzüglich der Programm-Menüleiste sowie der RT-Werkzeugleiste über den gesamten Monitor vergrößert, was soweit vom Grundsatz her ja auch richtig ist.
Standardmäßig hat man jedoch zu 99% das Formatierungsfenster geöffnet, das von der Bedeutung/Wertigkeit her eigentlich doch absolut gleichzusetzen ist wie dei RT-Werkzeugleiste, da sie ebenfalls immer im Vordergrund gehalten wird. Und daher wünschte ich mir RT würde das bei der Fenstervergrößerung entsprechend erkennen und das Rechenblattfenster auch nur max. bis zum Formatierungsfenster skalieren - je nach dem auf welcher Seite das Rchenblattfenster zum Formatierungsfenster liegt.
Denn, wenn dieses Formatierungsfenster, welches wahrscheinlich zudem meistens ganz rechts auf dem Monitor liegt auch über die gesamte Höhe des Monitors läuft ist es am Mac immer sehr umständlich die dahinter liegenden Fenster zu verkleinern. Mac-User werden wissen wo von ich rede.
Im Zweifelsfall sollte man evtl. die Möglichkeit bieten das Formatierungsfenster fest an den Monitorrand andocken zu können, so dass es wirklich identisch zu behandeln ist wie die Werkzeugleiste.
In dem Zuammenhang möchte ich auch noch das Paletten-Sammelfenster erwähnen, die z.B. oft verwendete Hilfsmittel temporär aufnehmen kann. Bei den sammelbaren Fenster sind meist nur der rote und der grüne Button in den jeweiligen Fenstertitelleisten aktiv. Meiner Meinung nach wäre es jedoch von der Bedeutung her sinnvoller nicht den grünen Button zur Verkleinerung in die Palette zu verwenden, sondern eher den gelben. Zudem sollte die Palette selber noch einen Funtkionknopf bekommen, mit dem man gerade geöffnet "Hilfsmittel" einsammeln kann. Das würde einem das Aufräumen in manchen Situation sehr erleichtern ;-)
Oder RT verhält sich Funktional mit den Hilfsmitteln so wie es Apple beim Finder anbietet - um z.B. mehrere Fenster auf einmal ins Dock zu legen, hält man beim Klicken einfach gleichzeitig die "ALT" Taste gedrückt.
Noch eine Bemerkung am Rande - warum wird der Genie-Effekt nur beim Wiederherstellen der Hilfsmittel aus der Palette verwendet. Beim verkleinern in die Palette verschwindet das jeweilige Fenster einfach. Das geht doch bestimmt auch in die Richtung schöner und unterstützt damit merklich die interaktion mit dem User.
Apple macht solche Dinge ja nicht zum Spaß ;-)
Herzlich Grüße,
Andreas - Appletiser
–––––––––––––––––––––––––––––
:: Apple MacBook Pro 2.2GHz/4GB Ram ::
:: OS X 10.5.6 :: RagTime 6.0.2 (1632) ::
automatische Zeilenhöhe
Apple-Script zur PDF-Erzeugung
