VS-Tipps & Tricks: Direkte Befehlseingabe über Schnellsuche

Das Command-Window kennt man wahrscheinlich schon (Strg+Alt+A).
Man kann hier direkt über die Tastatur und mit Hilfe von Intellisense, das gesamte Visual Studio steuern. Das ist aber nicht unbedingt unbekannt wird aber selten benutzt.

Interessant ist, dass man sehr schnell ohne ein weiteres Fenster diese Befehlseingabe auch so benutzen kann. Über das Schnellsuch-Fenster.

Drückt man Strg+D, landet man in dem bekannten Eingabefenster im Toolbar in dem man nun nach etwas suchen kann. Aber dieses Fenster kann mehr. Gibt man nun das Größer-als-Zeichen > ein, dann kann man nun auch hier direkt einen Befehl mit der Zusatzhilfe von Intellisense ausführen.

Die Tastenkombination Strg+D > op Eingabetaste öffnet den Datei-Öffnen Dialog.
Mit der Tastenkombination Strg+D > va . opt kommt man an den VA Options Dialog.

VS-Tipps & Tricks: Kontextmenü auf Karteireitern

In der Newsgroup microsoft.public.de.vc kam die Frage auf, ob es eine Seite mit speziellen Tipps und Tricks gibt für Visual Studio. Meines Wissens nach gibt es so etwas leider nicht. Deshalb habe ich mir vorgenommen demnächst einzelne Tipps & Tricks hier zu veröffentlichen.
Eine komplette Sammlung und Übersicht ist dann über diese Seite oder über die Kategorie-Auswahl in meinem Blog möglich.

Wer etwas beizusteuern hat, kann gerne eine Email an mich senden.

Aber nun zum ersten Tipp: Kontextmenü auf Karteireitern

Es lohnt sich einen Blick auf das Kontext-Menü zu öffnen, das sich öffnet, wenn man mit der rechten Maus auf den Karteireiter einer offenen Datei im Visual Studio klickt. Dort gibt es drei äußerst nette Helferlein, die man leicht übersieht:

  1. Close All But This
    Schließt alle Fenster bis auf das aktive. Besonders gut noch einer Debugging Session um wieder etwas Übersicht zu bekommen.
  2. Copy Full Path
    Kopiert den kompletten Pfad der Datei auf die Zwischenablage.
  3. Open Containing Folder (Mein Favorit) ❗
    Netter und schneller kann man den entsprechenden Projekt Ordner im Explorer nicht öffnen. Besonders, wenn man seine Projektdateien in Unterverzeichnisse gegliedert hat kommt man hier ganz schnell an das entsprechende Explorer-Fenster.

Command Routing der MFC bei Kontext Menüs mit TrackPopupMenu

Kontext Menüs  gehören zum State of  the Art.

Es ist auch nicht weiter schwer ein Menü zu laden ünd per TrackPopupMenu auf den Bildschirm zu zaubern. Entsprechender Code sieht dann meistens so aus:

void CMyView::OnContextMenu(CWnd* pWnd, CPoint pt)
{
    // Get the menu
    CMenu popups;
    if (!popups.LoadMenu(_T("AGV-IDR_MACRO_EDITOR_CONTEXT")))
        AfxThrowResourceException();
    CMenu* pSubMenu= popups.GetSubMenu(0);
    ASSERT(pSubMenu);
    if (!pSubMenu)
        AfxThrowResourceException();
    pSubMenu->TrackPopupMenu(0,pt.x,pt.y,this);
}

Oft sind in dem Menü einfache IDs von Commands verwendet worden, die irgendwo im View, Dokument, Frame oder der Applikation implementiert sind. Der Programmierer wundert sich nun warum seine Menüpunkte nicht ausgegraut werden. Alle Menüpunkte für alle IDs sind aktiv. Und man wundert sich noch mehr. Manche Commands (außerhalb des Views) werden nicht ausgeführt.

Was läuft hier falsch?

❗ Die Antwort liegt einzig und alleine im Aufruf von TrackPopupMenu! Der letzte Parameter gibt an, an wen die entsprechenden Nachrichten (WM_COMMAND, WM_INITPOPUPMENU und andere) gesendet werden. Naheliegender Weise gibt der Entwickler hier das Fenster an, in dem er das Popup Menü anzeigen will. Hier liegt der Hase im Pfeffer.
Ein normales Fenster und ein View hat keine Verwendung (Handler) für WM_INITPOPUPMENU. Solch ein Handler wäre aber für das Command Routing der MFC notwendig um die Menu-Items ein- und auszuschalten.

Das CMainFrame hat solch einen Handler, und kann damit umgehen. Also einfach das CMainFrame als Zeiger übergeben und … es funktioniert wie erwartet. Warum auch nicht. Die IDs aus dem normalen Menü werden ja auch über genau den selben Weg des Command Routings behandelt.
Die entscheidende Codezeile sieht dann so aus:

pSubMenu->TrackPopupMenu(0,pt.x,pt.y,AfxGetMainWnd());

RTM für VS-2008 Orcas doch zum Ende des Jahres

Sorry für meinen etwas schnellen Blog-Eintrag:
http://blog.m-ri.de/index.php/2007/07/16/vs-2008orcas-kommt-jetzt-doch-erst-im-februar-2008/

Ich habe Launch und RTM (Release to Market) durcheinandergebracht. Sorry!

Wie es aussieht ist es doch schon Ende des Jahres soweit: 

http://blogs.msdn.com/dseven/archive/2007/07/10/windows-server-2008-visual-studio-2008-and-microsoft-sql-server-2008-joint-launch-announced.aspx

„While the launch events are scheduled to kick off on February 27, 2008, Visual Studio 2008 will be released before the end of the year.“

http://blogs.msdn.com/somasegar/archive/2007/07/13/it-all-begins-february-27th.aspx

„While we will be launching our products together in February, we are still aiming to release Visual Studio 2008 and .NET FX 3.5 by the end of this year based on your feedbackso far.“

VS-2008/Orcas kommt jetzt doch erst im Februar 2008

KORREKTUR zu diesem Artikel hier
http://blog.m-ri.de/index.php/2007/07/17/rtm-fuer-vs-2008-orcas-doch-zum-ende-des-jahres/
Ich habe Launch und RTM durcheinander gebracht. Sorry!

„VS-2008/Orcas kommt jetzt doch erst im Februar 2008“ weiterlesen

Erstaunlich: const BYTE * != const LPBYTE

Erstaunlich! Wenn man die folgende Funktion kompiliert erhält man keine Fehlermeldung: 

void foo(const LPBYTE data)
{
    *data = 0; 
}

Man könnte denken, dass diese Funktion identisch wäre zu: 

void foo(const BYTE * data)
{
    *data = 0;        // Compiler Error
}

Ist es aber nicht! Die Funktion

void foo(const LPBYTE data);

ist identisch zu

void foo(BYTE * const data);

und eben nicht zu

void foo(const BYTE * data);

Der typedef darf selbst kein Zeiger sein! Er muss ein Basis Typ sein, nur dann führt const X * zum gewünschten Effekt.
Das ist das eigentliche Problem. Das entspricht auch mit dem Sample im Kapitel 5.4 der Stroustrup „C++ Bibel“.

Siehe auch Diskussion hier:
http://groups.google.de/group/microsoft.public.de.vc/browse_thread/thread/2568531dcf1c1d7e/215ead7f070e23d0

Wie kann ich das Visual Source Safe Kennwort zurücksetzen?

Ja! Dieses Kennwort braucht man selten, aber wenn man es braucht hat man es vergessen.
Aber die UM.DAT zu hacken ist ziemlich simpel. Es gibt einige Anleitungen im Netz dazu.
Hier meine Vaiante die man mit jedem x-beibigen Hexeditor verwenden kann

  • Man sucht an den Adressen 0x84, 0xC4, 0x104, etc. den Benutzernamen Admin.
  • Hat man die Adresse gefunden z.B. 0x84 (was meistens der erste Benutzer Eintrag ist), dann geht man 0x20 Bytes weiter. In meinen Beispiel gelangen wir nun an die Adresse 0xA4.
  • Hier ersetzen wir einfach die nächsten 4 Bytes durch:
    0x90 0x6e 0x00 0x00

Das Kennwort ist nun leer! Man kann ein neues vergeben. 

PS: Es gibt andere Tipps, die ersetzen hier 6 Zeichen. Das sollte man unterlassen, denn die nächsten beiden Zeichen sind eine interne user ID.

PPS: Die extreme Sicherheit des Source Safe Kennwortes ist erkennbar an dem immens sicheren Hasing auf 32bit! 😀 Eine Brute Force Attacke per Batch zu betreiben sollte auch kein Problem sein…

BTW: Der Hack ist natürlich auf eigene Gefahr und sollte nur gemacht werden, wenn man auch eine Sicherung der UM.DAT hat!

VSS Undo Checkout für einen Anwender den es nicht mehr gibt…

Da ist eine Datei die man ändern will. Man checkt sie aus und bekommt gesagt, dass diese Datei vom Benutzer „Wareinmal“ ausgecheckt ist.  😕 „Wareinmal“ war einmal bei uns beschäftigt… Lange her. Rechner wurde schon recycled.

Im Source Safe Explorer bekomme ich einen Undo Checkout für diese Dateien nicht angeboten. Und nun?
Im Dunkeln erinnere ich mich an ein Admin Kennwort für Visual Source Safe.

  • Also Source Safe Explorer so starten:
    SSEXP -yAdmin
  • Kennwort eingeben.
  • Datei suchen.
  • Undo Checkout…

Fertig!

Code Monkeys auch überall bei uns…

Über den Code Project newsletter habe ich diesen Blog-Eintrag gefunden:
http://geekswithblogs.net/sdorman/archive/2007/06/29/Programming-for-the-masses.aspx

Ich sehe auch in den Deutschen Foren, in denen ich mich tummle genau die gleichen Tendenzen. Die Szene in den Online Foren und in den NNTP Gruppen hat sich ziemlich verändert.
Man trifft überall Massen an Code Monkeys!

  • Netiquette unbekannt
  • F1-Taste drücken und die Basics der MSDN lesen wird nicht gemacht
  • FAQ ansehen ist umständlich
  • Nichtmal die entsprechenden bekannten Suchbegriffe in Google einzugeben gelingt
  • Basiswissen über die entsprechenden Programmiersprachen wird per Try&Error erprobt
  • Es zählt nur der schnelle Erfolg, auch wenn die Art und Weise wie die Lösung gefunden ist zweifelhaft ist
  • Grundsätzlich ist immer der Compiler und die verwendeten Libraries (CRT/MFC) buggy. Nie der eigene Code!

Irgendwie bin ich aus meiner Vergangenheit verwöhnt.
In meiner Anfangszeit als MVP habe ich weniger gepostet. Dafür waren die Antworten länger und ausführlicher, und meistens handelte es sich um wirkliche Probleme, die es zu lösen galt. Heute sind die Antworten weitaus kürzer und bestehen oft nur auf einen Verweis auf die Doku. Schade eigentlich. Man muss sich wirklich fragen warum man das eigentlich macht!

Im Großen und Ganzen hat sich das Niveau in der Newsgroup nntp://microsoft.public.de.vc gehalten. Allerdings ist die Gruppe der Poster und Regulars ziemlich geschrumpft. Es scheinen NNTP Gruppen irgendwie aus der Mode gekommen zu sein.

Foren wie http://www.c-plusplus.de/forum/index-var-.html und http://forums.microsoft.com/MSDN/default.aspx?SiteID=1 scheinen zu boomen, allerdings ist das Niveau hier nach unten offen…

Tja: Scheinbar war früher wirklich alles besser… 😉

VC-2005 Features der CRT für Unicode Unterstützung

Die CRT der VC-2005 hat eine perfekte Unterstützung für Unicode Dateien im UTF-8 und UTF-16 Little Endian Format.

Wollte man bisher Unicode Dateien lesen, so mussten diese mit _wfopen(…,L“rb“) geöffnet werden und entsprechende Leseoperationen mussten folgen. Um Unicode und ANSI Dateien zu unterscheiden schrieb man selbst entsprechenden Code, der nach einer BOM (Byte Order Mark) schaut. Beim Schreiben hatte man auch selbst darauf zu achten die BOM entsprechend zu setzen.

Ziemlich unbemerkt (auch von mir 🙂 ), hat die CRT hier eine entscheidene Erweiterung erfahren. Mit dem folgenden Code lässt sich gezielt jede Datei entsprechend öffnen und lesen, sofern Sie über eine korrekte BOM verfügt, bzw. auch eine Datei zum Schreiben öffnen die mit der entsprechenden BOM versehen wird.

FILE *pFile = _tfopen(_T(„myfile.txt“),_T(„rt, ccs=UNICODE“));

Ist die Datei eine ANSI Datei ohne BOM, wird sie entsprechend geöffnet. Unicode Dateien im Typ UTF-8 und UTF-16 little endian werden an der entsprechenden BOM erkannt und entsprechend gelesen.
Über ccs=UTF-8 bzw. ccs=UTF-16LE lässt sich auch gezielt eine entsprechende Unicode Datei ohne BOM öffnen. Eine vorhandene BOM überschreibt allerdings die beim Öffnen angegebenen Formatierung. Fein!

Leider hinkt die MFC diesen wirklich tollen Funktionen der CRT hinterher. Weder die MFC  8.0 aus VS-2005 noch die neue Orcas Version (Stand Beta1) verfügt über eine neue Version der CStdioFile, die diese Funktionen der CRT abbildet.

Glücklicherweise gibt es einen entsprechenden CStdioFile(FILE *) Konstruktor. Dadurch ist es möglich, einfach eine Datei mit _tfopen zu öffnen und den Stream einfach an ein CStdioFile Objekt zu koppeln.
Einziger Schönheitsfehler: CStdioFile::Close muss explizit in diesem Fall aufgerufen werden, d. h. Close wird nicht durch den Destruktor aufgerufen.
Für den MFC Kenner: m_bCloseOnDelete ist FALSE und leider protected. Dieses Flag verhindert, dass Close auch durch den Destruktor aufgerufen wird.

MSDN Dokumentation zu _tfopen/fopen/_wfopen