wer ist "wir"?
Als vorhin ein Kollege davon sprach, dass "wir" uns beim Frühstück zurückgehalten hätten, musste ich folgende Frage einfach loswerden:
"Sprecht Ihr schon im Majestätsplural, Hoheit?"
Ein anderer Kollege, der dabei stand (aber beim Frühstück nicht dabei gewesen war), hatte hörbar Schwierigkeiten, weil sein Kakao dringend durch seine Nase wollte. :biggrin:
sprechende Benennung
Nun gibt es in der User32.dll eine Funktion mit dem einladenden Namen CloseWindow. Also denke ich mir so, dass die wohl dafür gedacht ist, wenn man ein Fenster schließen will. Wäre ja irgendwie logisch. Aber nein, wenn man der CloseWindow-Funktion ein Fensterhandle reicht, dann minimiert die das Fenster nur. Naja, irgendwie so ganz offen ist das Fenster zwar nicht, aber naja. Also habe ich weitergesucht, und die martialisch klingende Funktion DestroyWindow gefunden. Wenn man mal von der Assoziation absieht, dass mein Programm dann mit einem Raketenwerfer das 'feindliche' Fenster bearbeitet, könnte man ja annehmen, dass nach der Zerstörung eines Fensters eben dieses weg wäre. Also habe ich auch das getestet, aber ohne jeglichen Erfolg. Das zu Testzwecken verwendete Notepad hat sich von den Angriffen gänzlich unbeeindruckt gezeigt.
Nach weiterer Recherche bin ich dann über ein Codebeispiel gestolpert, bei dem dem betreffenden Fenster eine Meldung WM_CLOSE geschickt wird, wonach sich das Fenster dann üblicherweise schließt. In der Dokumentation, die ich mir dann zu dem Thema noch verabreicht habe, stand dann noch, dass die Standardimplementation der Nachrichtenbehandlung nach Erhalt der WM_CLOSE-Meldung einen DestroyWindow-Aufruf absetzen würde. Hmm, okay, dann darf sich ein Programm wohl nur selbst wegbomben. Naja, solange es funktioniert.
Der testweise behandelte Editor hat sich dann auch brav beendet, und im Fall von ungespeicherten Eingaben den Nutzer mit einer Rückfrage auf den Umstand hingewiesen. Okay, works as planned. Dass sich hingegen ein bei weiteren Tests herangezogenes Explorerfenster gegenüber dem Schließungswunsch völlig verschließt, verwundert dann schon. Aber vielleicht wäre dort ja ein CloseWindow angemessener?
Streik nervt
Das 3-W-Spiel
Besonders bemerkenswert fand ich, dass sich ein ehemaliger Vorgesetzter in meinem Büro eingefunden hat, um mir persönlich die Pfote zu schütteln, während dessen Nachfolger mir telefonisch zu meinem fortschreitenden Alter gratuliert hat. Dass mein Vorgesetzter eine Ebene höher sich heute weder per Mail, Telefon oder gar persönlich gemeldet hat, finde ich allerdings schade.
Dafür ist einigen der externen Kollegen nicht aufgefallen, dass ich heute eine größere Anzahl Süßkram auf meinem Bürotisch bereitgestellt hatte. Aber einen Keks haben sich die Kollegen dann nach kurzer Gedächtnisstütze doch verdient. :biggrin:
Da kommt was zusammen
Sperrig
Heute auf Arbeit durfte ich mich den ganzen Tag damit rumschlagen, dass aus unbekannten Gründen mein User in der produktiven Windows-Umgebung immer wieder gesperrt wurde. Nun kann man ja meinen, dass das egal ist, schließlich haben wir unsere eigene Entwicklungsumgebung. Aber das ist leider etwas kurz gedacht: Jeder Internetzugriff läuft bei uns über einen Proxy, der zur Authentifizierung den produktiven Windows-Account verwendet. So stand ich vor der Wahl, ständig den User (zum Glück automatisiert) freischalten zu lassen, oder eben nicht ins Netz gelangen zu können. Zum Glück konnte ich die Programmierung ohne Netzzugriff erledigen, aber die ständige Sperrung nervt dann doch.
Warum kann der Mist nicht einfach mal funktionieren?
Fehlersuchtag
Heute habe ich den ganzen Arbeitstag damit verbracht, dass ich versucht habe herauszufinden, warum ein bestimmter, für die Anmeldung sehr wichtiger Aufruf in unserer Anwendung auf meinem Rechner (und auch nur dort) nicht funktionierte. Zuerst hatte ich ja die Gegenseite des Aufrufs im Verdacht, aber das dortige Log zeigte nicht einmal, dass mein Rechner irgendwas mit dem System gemacht hätte, geschweige denn, dass dort ein Fehler passieren würde. Dann habe ich das Serverprofil komplett gelöscht und neu aus dem Repository geholt, auch ohne jeden Erfolg. Auch mehrfaches neukompilieren aller beteiligten Klassen brachte mich nicht weiter, genau wie wiederholtes Veröffentlichen (publishen, wie man wohl in Denglish sagt) der Anwendung brachte nichts. Dann habe ich mir einen der externen Kollegen dazugeholt, weil der letzte Woche noch im Umkreis der Aufrufe etwas geändert hatte, aber auch der konnte keine Ursache für das Problem erkennen. Zwischenzeitig fiel der Verdacht noch auf Windows-Patches, die ich heute morgen installiert hatte, aber auch das führte bei den Kollegen zu keinen Problemen.
Kurz vor Feierabend fiel mir dann noch ein, dass ich zur Behebung eines anderen (aber ähnlichen) Fehlers im Zusammenhang mit einer völlig anderen Java-Anwendung ein paar Dateien in ein bestimmtes Verzeichnis des RAD kopieren musste. Kaum hatte ich die Dateien dort entfernt, lief auch alles wieder. Es sieht so aus, als hätte ein FixPack, was wir letzte Woche alle installiert haben in Zusammenhang mit diesem alten Fix zu einem neuen Problem geführt. Und das erklärt dann auch, warum ich der einzige Betroffene war: Die anderen Kollegen hatten die Dateien ja nicht als Fehlerbehebung führ andere Anwendungen einspielen müssen, und folglich trat bei denen das Problem nicht auf.
Sollte mir mal irgendwann langweilig werden, kann ich ja einfach die Dateien dort wieder hinkopieren und abwarten, bis die ersten Aufrufe der Anwendung wieder fehlschlagen.
Die Tischkante, in die ich vorhin gebissen habe, hätte mit einem Schoko-Überzug aber bestimmt besser geschmeckt.
Weichware kaputtmachen
Genug Zeitmord
So verhältnismäßig einfach bin ich das Zeit-Totschlags-Thema losgeworden. Dafür durfte ich mich dann nochmal damit beschäftigen, warum die aktuelle Projektanwendung nicht funktionieren wollte, was aber deutlich weniger Zeit in Anspruch genommen hat. Ab Montag kann ich dann auch wieder meine ganze Zeit dem Projekt zuwenden. Ist vielleicht auch besser so.
Zeit erschlagen?
Heute habe ich den ganzen Tag damit zugebracht, eine Anwendung, die im Test unter bestimmten Umständen intern eine Exception wirft (lies: Es taucht in der Logdatei eine Fehlermeldung auf, die aber weder einen offensichtlichen Grund, noch erkennbare Auswirkungen hat), auf meinem Arbeitsplatzrechner (wieder) zum Laufen bringen. Seit inzwischen zwei Monaten bin ich in einem neuen Projekt beschäftigt, was mir in der Zwischenzeit eine Neuinstallation meines Rechners eingebracht hat. Die Anwendung, die vorher auf dem Rechner eingerichtet war, habe ich mir seitdem nicht wieder aufgesetzt, dafür gibt es ja zentrale Testserver. Zum Debuggen von (unerklärlich) geworfenen Exceptions sind die zentralen Server allerdings einigermaßen ungeeignet.
Nachdem ich mehrere Stunden damit zugebracht habe, erst den lokalen WebSphere-Server einzurichten, die Verbindungen zu den entsprechenden Datenbanken zu erstellen (was aus irgend einem unbekannten Grund deutlich schwieriger war, als ich erwartet hatte, und Unterstützung von unseren Datenbänkern benötigte), gab es dann noch einen Patch, den ich einspielen musste, weil ich sonst beim Start der Anwendung ganz andere Exceptions um die Ohren geschmissen bekomme. Warum die Anwendung zum Schluss immernoch meinte, sie müsste sich von alleine anmelden (was nicht funktioniert, weil das nicht vorgesehen ist), werde ich dann wohl morgen erst herausfinden.
Und das alles, um eine eigentlich harmlose Exception zu beseitigen.