Schlagwort: 4NT

ExitInstance gibt für dialogbasierende MFC Anwendungen Unfug zurück

Wer eine dialogbasierende Anwendung mal mit etwas mehr Aufmerksamkeit debuggt oder analysiert wird feststellen, dass der Returncode der Anwendung irgendwie ziemlich zufällig ist. Beobachtet man dies genauer dann stellt man folgendes fest:

  • Beendet man die Anwendung mit der Maus (Klick auf X) oder OK/Cancel so ist der Returncode 0
  • Hält man die Strg-Taste beim Klick fest ist der Returncode 8
  • Beendet man die Anwendung mit Alt+F4 bekommen wir 2.
  • Und jedermann kann jetzt schon mal raten was passiert, wenn wir die Umschalttaste festhalten. Genau dann bekommen wir 4 als Returncode.

Die Mystik hinter dem Ganzen ist die Behandlung von (Afx)PostQuitMessage. Eigentlich sollte mit dieser Nachricht auch der Exitcode gesetzt werden, der mit WM_QUIT versendet wird. Und wenn eben bei einer MDI/SDI Anwendung alles normal läuft, dann ist diese Nachricht die letzte, die aus der Messsagequeue gezogen wird. Und was passiert in CWinApp::ExitInstance? Genau… aus dem statischen Thread Puffer für die Windowsnachrichten wird mit  AfxGetCurrentMessage die letzte Windowsnachricht (normalerweise WM_QUIT) geholt und der wParam Wert bestimmt. Dieser wird dann zurückgegeben.

Leider ist aber WM_QUIT in manchen Fällen aber nicht die letzte Nachricht, die zum Beenden eines Programms führt. Ganz besonders eben nicht bei einer dialogbasierenden MFC-Anwendung. Da ist die letzte Nachricht ist dann eben ein WM_COMMAND oder ein WM_LBUTTONUP der das Schließen der Anwendung auslöst ❗ Und der wParam Wert ist eben entsprechend dieser Nachricht belegt!

Gleiches passiert natürlich, wenn man nach dem Beenden der Messageloop noch andere interne Fenster zerstört. Auch in diesem Fall kann noch mal die interne AfxWndProc durchlaufen werden und dann wird der Returncode auch wieder verändert.

Wer also wirklich Wert auf den Returncode legt (im wahrsten Sinne des Wortes), der sollte sich nie auf den Wert verlassen, der durch CWinApp::ExitInstance zurückgegeben wird oder den Wert, den man selbst mit AfxPostQuitMessage evtl. versucht zu setzen. Eine Variable in CWinApp tut hier einen besseren Dienst. Ebenfalls sollte man ExitInstance überschreiben und immer 0 zurückgeben, wenn man sowieso keine Verwendung für den Returncode des Prozesses hat oder haben möchte.

BTW:
Die Geschichte, wie ich darauf gekommen bin ist schon eigentümlich genug.
Ich habe komplexere Batch-Dateien, die die gesamte Erstellung einer produktiv-Version regelt. Darin kommen im Problemfall auch ein paar Userinteraktionen vor. Diese werden durch Windows Anwendungen ausgelöst, die evtl. einen Dialog anzeigen. Jedem ist klar, dass ohne Dialog und ohne Fenster keine Nachricht abgearbeitet wird. Der Returncode ist also 0! Der Batch verwendet 4NT Syntax und dort kann man ON ERROR definieren und somit sofort eine Fehlerbehandlung auslösen, wenn der Returncode eines Programms nicht 0 ist.
Nun kann sich jeder schon denken was passiert ist. Die Userinteraktion wurde ausgelöst. Der Benutzer machte eine Angabe und… der Batch terminierte erstaunlicherweise mit einem Fehler… (s.o.)

CMD.EXE versteht keine Unicode oder UTF-8 Batch Dateien

Ich habe für einen Deployment Prozess noch einen etwas größere komplexe Batch-Datei. Die BAT Datei enthielt auch zum Teil eben Umlaute die ja nicht ANSI sein dürfen. Zudem auch einige der Verzeichnisse neuerdings Umlaute enthalten, dachte ich mir: „Was soll es, Du speicherst das einfach als Unicode Datei!“ Die Vista CMD.EXE wird ja anhand der BOM erkennen was los ist.

😯 Pustekucken ❗ CMD.EXE mag in keiner Art und Weise Unicode oder UTF-8 in Batch-Dateien.

No chance at all. Einzig zur Unicode-Ausgabe kann man die CMD.EXE verleiten.
Eigentümlich ist das schon, weil TYPE z.B. BOMs korrekt berücksichtigt.

Da merke ich mal wieder wie verwöhnt ich mit 4NT bin.

PS: Ich weiß das es in Zeiten der Powershell andere Möglichkeiten gibt.
Man kann mich mit entsprechenden Kommentaren also gerne verschonen. 😉

CLIP.EXE der nette kleine Helfer unter Vista

Wer wollte nicht schon mal ganz schnell die Ausgabe eines Befehlszeilen Tools in der Zwischenablage haben. OK man kann einen Bereich mit dr Maus im Konsolenfenster markieren, aber was macht man wenn es um eine 2000 Zeilen Ausgabe geht?

Unter Vista ist das ganz einfach, man benützt einfach eine Pipe und CLIP.EXE!

DIR | CLIP

Siehe da. Man hat den gesamten Text in die Zwischenablage gepipet.
Was CLIP macht verrät es wenn man einfach mal CLIP /? ausführt.

CLIP

Beschreibung:
    Leitet die Ausgabe von Befehlszeilenprgrammen in die
    Windows-Zwischenablage um.
    Diese Textausgabe kann in andere Programme eingefügt werden.

Parameterliste:
    /?                  Zeigt diese Hilfe an.

Beispiele:
    DIR | CLIP     Erstellt eine Kopie des aktuellen Verzeichnis-
                         inhalts in der Windows-Zwischenablage.

    CLIP < README.TXT   Erstellt eine Textkopie von readme.txt
                         in der Windows-Zwischenablage.

BTW: Jeder 4NT bzw. TCC/LE Nutzer kennt natürlich schon längst den CLIP: Device! Diejenigen mussten auf solch ein Helferlein auch nicht bis Vista warten. Damit kann man das ganze auch einfach so

DIR > CLIP:

machen.

Abgespecktes 4NT als TCC/LE von JP-Software als Freeware

Ich bin seit Jahren ein begeisterter Fan von 4NT (kennengelernt habe ich es noch als 4DOS unter DOS 4.0).
Was man so alles vermisst wenn man mal mit CMD.EXE arbeitet merke ich immer sofort, wenn ich ein DIR oder COPY ausführe und die komplexen Ranges, die 4NT bietet , sofort vermisse.
Ganz zu schweigen von netten Befehlen wie LIST, SELECT und anderem.

Auf den großen Bruder Take Command habe ich bisher immer verzichtet.
Ich verwende 4NT gerade auch da, wo ich komplexe Batchfiles für den gesamten Weg vom Build bis zum Setup benötige. All‘ das Kopieren von Dateien und Tools anwerfen, die dann irgendwann ein fertiges SETUP Paket erzeugen. Es ist einfach unschlagbar von den internen Funktionen, die hier geboten werden.

Jetzt hat mich JP-Software überrascht:

  1. Negativ: 4NT als Produkt alleine gibt es nicht mehr. Man kann den gesamten Funktionsumfang nur noch als Take Command erhalten.
  2. Positiv: Es gibt 4NT in etwas abgespeckter Form nun als TCC/LE (Take Command Console LE) kostenlos ❗

Soweit ich das sehe fehlt nur der Batch-Debugger und der Batch-Compiler, die ich sowieso kaum nutze, sonst sind alle meine gliebten Befehlszeilenfunktionen vorhanden.
In den internen Funktionen wird man evtl. die Datums- und Zeitfunktionen vermissen, die komplett herausgenommen wurden. Gleichfalls wie einige andere Funktionen.
Selbst mit den eingeschränkten Funktionen: TCC/LE ist ein Muss ❗

Download hier: http://www.jpsoft.com/tccledes.htm

VS-Tipps & Tricks: Command-Prompt öffnen im Projektverzeichnis

Es ist oft genug sinnvoll direkt im Projektverzeichnis eine Eingabe-Konsole zu öffnen. Ich persönliche verwende 4NT von JP-Soft, damit lassen sich viele Sachen weitaus schneller erledigen als mit dem Explorer.

Um schnell eine Eingabefenster zu öffnen kann man sich ein eigenes Tool einrichten.

  • Man klickt auf Tools -> External Tools…
  • Add Schalter anklicken
  • Dem Tool einen Namen geben (z.B. 4NT im Projektverzeichnis)
  • Als Command gibt man %COMSPEC% an
  • Als Argument /k „%VS80COMNTOOLS%\..\..\VC\vcvarsall.bat“ x86
    Durch diese Eingabe werden alle Environment Variablen gesetzt, die z.B. die Tools von VS2005 benötigen oder eben auch der Compiler. Dadurch kann man sofort alle Tools aus VS direkt von der Befehlszeile öffnen.
  • Bei Initial directory gibt man jetzt noch den Makro $(ProjectDir) an

Die entsprechenden Makros und Environment Variablen garantieren, dass die entsprechenden Batchfiles und auch der korrekte Befehlszeileninterpreter gefunden wird. Bei mir eben 4NT und nicht CMD.EXE. Durch die Verwendung von %VS80COMNTOOLS% wird auch der entsprechende Batchfile gefunden, egal wie das Programmverzeichnis heißt.

Der Aufruf von vcvarsall.bat setzt PATH, INCLUDE und LIB Environment-Variablen. Damit kann man alle VS-Tools diekt aus der Befehlszeile nutzen.

Warum ich diese komplizierte Methode gewählt habe? Ich liebe einfach universelle Angaben die man auf jeden Rechner übernehmen kann, egal wo die entsprechenden Softwarekomponenten installiert sind.