Ich bin am Kochen und muss das mal eben loswerden. (Der Thread kann ruhig gelöscht werden, ich muss nur gerade einfach meine Wut in die Tastatur kanalisieren, um nicht Elkos die Beinchen rauszureissen, mit dem 5Kg-Hammer zu Atmel zu fahren oder eine Oma auf der Straße zu verprügeln. ;-) Ich bin heute Nacht um etwa 2:30 aufgewacht und konnte nicht wieder einschlafen. Also ab an den Rechner, um am Source meiner Trenntrafo-Anzeige zu hacken. Um etwa 4:30 habe ich eingesehen, dass das mit dem Pennen wohl nichts mehr wird, habe gespeichert, mir erst mal einen Leckerkaffee gemacht und dabei über die Realisierung der Ausgabe sinniert. Dann bekam ich einen Hackflash der bis eben andauerte. Die ganze Zeit wie in Trance bis zum ersten "fertig" durchgehackt. Dann auf den Button zum Kompilieren geklickt, auf den ersten Fehler (fehlendes Semikolon) geklickt, und da war Plötzlich der Source, wie ich ihn vor meinem Kaffee abgespeichert hatte. - Der ganze Hackflash ist nach /dev/null gegangen. AVR Studio 4 hat wohl das automatische Speichern übersprungen, und beim Klicken auf den Fehler die Alte Datei in das Editorfenster geladen. Megamöööp :-( (Gibt es eigentlich einen Smiley für "sich in den Sack beißen"?)
Nachtrag: Nachdem ich alles neu eingehackt und gesichert hatte, bemerkte ich, dass mein Editorfenster den Dateinamen komplett in Kleinbuchstaben hatte, während meine Datei gemischte groß- und Kleinbuchstaben hat. Dort war die Datei, die ich vorhin vermisst hatte. :-D
Guten Morgen Manchmal sollte man doch etwas schlafen, dann bekommt man auch wieder mal die Augen auf. Namaste
Fuer sowas hat man ueblicherweise Versionskontrollsysteme oder man drueckt oefter mal "Speichern". Selber schuld.
Winfried J. schrieb: > Manchmal sollte man doch etwas schlafen, dann bekommt man auch wieder > mal die Augen auf. Eigentlich sind die nächtlichen Hacks die besten. :) Markus Müller schrieb: > Oder man nimmt besser gleich Windoof. Gibt es AVR Studio auch für etwas anderes? - Der Ursprung des Problems scheint ja irgendwie in der Unfähigkeit von Windows, zwischen Groß- und Kleinbuchstaben unterscheiden zu können, bei gleichzeitiger Fähigkeit, Dateinamen mit Groß- und Kleinbuchstaben anlegen zu können, begründet zu sein. Icke ®. schrieb: > Immer die Packungsbeilagen lesen! Blos nicht! Dann bekommt man doch die Nebenwirkungen! ( http://de.wikipedia.org/wiki/Nocebo-Effekt ) Michael G. schrieb: > Fuer sowas hat man ueblicherweise Versionskontrollsysteme oder man > drueckt oefter mal "Speichern". Selber schuld. RCS ist etwas feines, nur wenn man nicht speichert, hilft es wenig. :-D Übrigens: Man ist immer selber schuld.
Philipp Klostermann schrieb: > Eigentlich sind die nächtlichen Hacks die besten. :) Das schon aber bevor man einschläft sollte speichern und sich dann schlafen legen. Namaste
Da hilft keine Versionsverwaltung nix. AVR Studio hat bei mir manchmal die Meise, dass es einfach nebenbei zum Compilieren eine alte Version öffnet, statt die neue vor dem Compilieren zu speichern. Erstmal muss man merken, warum die Änderungen nix bewirken. Und wenn man dann nicht tierisch aufpasst, hat man schnell seine Änderungen überschrieben...
Eines meiner ersten MFC-Programme mit Wuschelzeh 1.0 war eines, dass sich das Fenster von der IDE schnappt und dem sein File/Save Kommando schickt. Ich habe das gerade gesucht und nicht wieder gefunden. Eine Neuimplementierung war aber schnell erledigt. Diese implementierung sendet alle 30 Sekunden die Nachricht an das Hauptfenster von AVR Studio 4.0, die das Fenster erhält, wenn der User File/Save aufruft. Wenn kein solches Fenster gefunden wird, weil AVR Studio gerade nicht offen ist, passiert nichts. Ich habe die .exe mal angehangen. Wer mir nicht traut, kann sich das auch selbst kompilieren. Einfach ein leeres Dialog-Applikation-Projekt erzeugen, per Class-Wizard um einen WM_TIMER-Handler erweitern und den Code wie folgt ergänzen oder das .zip entpacken. Es kann sein, dass der Klassenname und das Kommando bei anderen (Sub-)Versionen vom AVR Studio anderes ist, aber das ist mit Spy oder Spy++ schnell herausgefunden.
1 | BOOL CSendfilesavecmdDlg::OnInitDialog() |
2 | {
|
3 | ...
|
4 | if (!SetTimer(1, 30000, NULL)) |
5 | {
|
6 | MessageBox(_T("Keine Timer-Resource bekommen. :-("), _T("Fehler")); |
7 | }
|
8 | ShowWindow(SW_MINIMIZE); |
9 | ...
|
10 | }
|
11 | |
12 | ...
|
13 | |
14 | void CSendfilesavecmdDlg::OnTimer(UINT nIDEvent) |
15 | {
|
16 | CWnd* pWnd = FindWindow("Afx:00400000:8:00010011:00000000:00060C9D", NULL); |
17 | if (pWnd) |
18 | {
|
19 | pWnd->SendMessage(WM_COMMAND, 57603, 0); |
20 | }
|
21 | CDialog::OnTimer(nIDEvent); |
22 | }
|
Eine Kleinigkeit hatte ich vergessen: Wenn man gar nichts geändert hat, gerade im Debugegr ist und trotzdem gesichert wird, fragt er mitten in der Debug-Session, ob er das Projekt neu bauen soll. Ich habe das jetzt so geändert, dass das Kommando nur gesendet wird, wenn in der Titelleiste des Fensters ein "*" (geändert) ist:
1 | void CSendfilesavecmdDlg::OnTimer(UINT nIDEvent) |
2 | {
|
3 | CWnd* pWnd = FindWindow("Afx:00400000:8:00010011:00000000:00060C9D", NULL); |
4 | if (pWnd) |
5 | {
|
6 | CString s; |
7 | pWnd->GetWindowText(s); |
8 | if (s.Find(_T('*'), 0) >= 0) |
9 | {
|
10 | pWnd->SendMessage(WM_COMMAND, 57603, 0); |
11 | }
|
12 | }
|
13 | CDialog::OnTimer(nIDEvent); |
14 | }
|
Timm Thaler schrieb: > Erstmal muss man merken, warum die Änderungen nix bewirken. Und wenn > man dann nicht tierisch aufpasst, hat man schnell seine Änderungen > überschrieben... Bei mir ist das Abspeichern von Änderungen von dem Wechsel zwischen Editorfenstern oder vor dem Übersetzen längst zum Reflex geworden. Aber nicht wegen Atmel, sondern generell.
Philipp Klostermann schrieb: > Diese implementierung sendet alle 30 Sekunden die Nachricht an das > Hauptfenster von AVR Studio 4.0, die das Fenster erhält, wenn der User > File/Save aufruft. Das ist aber auch nicht ganz ungefährlich: Wenn das AVR-Studio auf Grund eines Bugs in einen fehlerhaften Zustand gerät, aber noch in der Lage ist, die File-Save-Nachricht zu empfangen und auszuführen, wird u.U. eine verhunzte Datei gespeichert, wodurch nicht nur die letzten Änderun- gen verloren gehen, sondern gleich die geamte Arbeit. Ich habe das mit einer früheren Version von Excel leider schon erlebt. Nachdem das Programm erkennbar verrückt gespielt hat, ist wohl noch einmal ein Autosave getriggert worden. Die Datei exisitierte danach zwar noch und enthielt auch Daten. Beim Versuch sie zu laden, meckerte Excel aber jedesmal, dass es sich um keine gültige Excel-Datei handle. Seither deaktiviere ich bei zweifelhaften Programmen (und das sind für mich fast alle) grundsätzlich die Autosave-Funktion. Auf Grund dieser Problematik speichern bessere und neuere Programme den Autosave unter einem anderen Dateinamen ab, so dass im Fehlerfall wenigstens nur die Änderungen seit dem letzten manuellen Speichern verloren gehen. Den "humangetriggerten" Autosave, der vor dem Kompilieren, vor einem Wechsel in eine andere Anwendung und vor längeren Denkpausen die Datei speichert, halte ich aber nach wie vor für die bessere Lösung. Mich schüttelt es immer wieder, wenn ich Kollegen sehe, die mehrere Word-, Excel- und Powerpoint-Dateien gleichzeitig und ungespeichert offen haben und dann Mittagessen gehen =8-[
Yalu X. schrieb: > Wenn das AVR-Studio auf Grund > eines Bugs in einen fehlerhaften Zustand gerät, aber noch in der Lage > ist, die File-Save-Nachricht zu empfangen und auszuführen, wird u.U. > eine verhunzte Datei gespeichert, wodurch nicht nur die letzten Änderun- > gen verloren gehen, sondern gleich die geamte Arbeit. Den kannte ich noch nicht, weil der bei mir noch nicht aufgetreten ist, sondern nur der andere, den ich eingangs beschrieben habe. Danke für den Hinweis. Kann ich diesen fehlerhaften Zustand irgendwie erkennen, so dass ich dann mein Programm (vielleicht noch rechtzeitig) beenden kann?
Philipp Klostermann schrieb: > Den kannte ich noch nicht, weil der bei mir noch nicht aufgetreten ist, > sondern nur der andere, den ich eingangs beschrieben habe. Das ist kein spezifischer, bekannter Bug, sondern ein hypothetischer, bei dem du aber nicht sicher sein kannst, dass er nicht exisitiert. Jede komplexere Software (außer TeX natürlich ;-)) ist, wie wir alle wissen, fehlerhaft. Fehler wie Pufferüberläufe u.ä. führen oft dazu, dass Datenstrukturen im Speicher überschrieben werden. Wird der Inhalt dieser versaubeutelten Strukturen in eine Datei gespeichert, ist diese ebenfalls versaubeutelt. Ich gehe deswegen immer folgendermaßen vor: Wenn ich feststelle, dass sich eine Anwendung irgendwie seltsam verhält (überlange Reaktionszei- ten, Fehler in der Bildschirmdarstellung usw.), versuche ich, das aktuelle Dokument unter einem neuen Namen abzuspeichern, und starte die Anwendung (oder ggf. den gesamten PC) neu. Mit etwas Glück kann ich dann die zuletzt geschriebene Datei wieder einlesen. Wenn nicht (weil sie aus o.g. Gründen versaubeutelt ist), habe ich immer noch die Version mit dem ursprünglichen Dateinamen, die zwar die letzten Änderungen noch nicht enthält, aber immerhin den ganzen Rest der Arbeit. Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder — wie bei dir — von extern getriggert), die beim Speichern die Original- datei überschreibt, besteht eben die Gefahr, dass man hinterher nur noch eine versaubeutelte Datei übrig hat.
Yalu X. schrieb: > Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder — > wie bei dir — von extern getriggert), die beim Speichern die Original- > datei überschreibt, besteht eben die Gefahr, dass man hinterher nur > noch eine versaubeutelte Datei übrig hat. Wie A.K. es schon oben beschrieb, ist bei mir die Sicherung auch schon eine Art Reflex. Ich mache das mit einem Command-File (Batch), welches wirklich das gesamte Projekt zippt, mit Projektnamen und Zeitstempel im Dateinamen, und die Datei wird auch an einen ganz anderen Ort geschoben. So wird auch nie eine vorherige Datei überschrieben. Den Zeitstempel im Dateinamen deswegen, damit ich im Sicherungsverzeichnis nach Namen und Datum gemeinsam sortieren kann. Das geht doch heute in Sekundenbruchteilen, wo man früher dem Zipper noch minutenlang bei der Arbeit zuschauen konnte. Aber das kann ja jeder machen, wie er will. Die Sicherung wird sowohl bei jedem Compilerlauf ausgelöst, als auch mit einem Button unten in der Taskleiste. OK, man muß mal etwas Zeit investieren, um das Batch-File aufzusetzen, und die Tools, die darin verwendet werden. Aber das macht man ja nur ein mal. Mir half vor Jahren mal ein Softwerker dabei, der sich auch gut mit Schleifen in Batch-Files auskannte. Das war schon ein paar Stunden Arbeit, bis alles lief. Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte vielleicht 2. Aber da gibt es auch böse Überraschungen: Eine for-Schleife für Dateilöschung in einem Arbeitsverzeichnis, die einen Syntaxfehler hatte, löschte mir auf der Arbeit mal das komplette Laufwerk D, die zweite Partition auf der Festplatte. Natürlich ohne Verwendung des Papierkorbes. Dort war alles drauf, was mit meiner Arbeit zu tun hatte, wie Projektverzeichnisse, Datenblätter aus Recherchen, usw.. Glücklicherweise war die Arbeit aber auf dem zentralen Server, und so war der Schaden nur die 2 letzten Stunden Arbeit. MPLAB hat sogar einen extra Button nur zum Zippen und Sichern. Überschreibt leider aber auch die alte Datei. Genau wie Philipp versaubeutelte sich ein Kommilitone mal das Programmierprojekt fürs Studium, wo 3 Wochen Arbeit drin steckten. Er meinte nach einer Party in guter Bierlaune, noch ein Stündchen daran arbeiten zu müssen. So schnell wie nach dieser Aktion wurde der seit dem wohl nie wieder schlagartig nüchtern. Diese Geschichte vergesse ich nie mehr.
Yalu X. schrieb: > Bei jeder Autosave-Funktion (egal, ob in die Software integriert oder — > wie bei dir — von extern getriggert), die beim Speichern die Original- > datei überschreibt, besteht eben die Gefahr, dass man hinterher nur > noch eine versaubeutelte Datei übrig hat. Das lässt sich vielleicht lösen, wenn man das Backup-Konzept von Wilhelm mit der Autosave-Funktion kombiniert. Etwa so: - senfilesavecmd.exe wird um folgende Punkte erweitert: 1. Eine Liste von Verzeichnissen, per .ini-File (hierfür ist die Registry unpraktischer) konfigurierbar und per UI editierbar. (Listbox mit Kontextmenü, Handeingabe und "Verzeichnis Suchen"-Dialog) 2. Eine konfigurierbare Liste von Aktionen mit Platzhaltern für Pfad und Datei, die als Backup-Prozess ausgeführt werden. Aus einem Thread heraus werden diese Verzeichnisse per FindFirstChangeNotification()/FindNextChangeNotification() beobachtet, ihr Inhalt wird bei Änderungen mit einer Liste pro Verzeichnis ver- und abgeglichen und und bei Änderungen wird für jede geänderte Datei der Backupprozess mit diesem Verzeichnis und dieser Datei als Parameter gestartet. Hat jemand einen besseren/alternativen Vorschlag?
Wilhelm Ferkes schrieb: > ... > Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn > die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte > vielleicht 2. Und genau dafür sind Revision Control Systems (RCS) gut.
Simon K. schrieb: > Wilhelm Ferkes schrieb: >> ... >> Hinterher habe ich zwar 30 Zip-Files am Tag in einem Ordner, und wenn >> die Arbeit erfolgreich war, lösche ich 28 überflüssige, und behalte >> vielleicht 2. > Und genau dafür sind Revision Control Systems (RCS) gut. Ja, stimmt. Aber hier im Hobby habe ich im Augenblick keinen Bock darauf. Hauptsache, es sind funktionierende Projekte mit allen Ständen überhaupt irgendwo gesichert. Außer dem Erstellen des Command-Files brauchte ich weiter nichts, aber noch einen Satz Unix-Tools, die man sich bei Sourceforge herunter laden kann, die das Datum und die Uhrzeit in den Dateinamen einfügen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.