VS-Tipps & Tricks: Schnelles Navigieren im Class View

Wenn man in Dialogen und Klassen über den Class View Variablen oder Funktionen hinzufügen will, dann ist dies oft mit mühsamen Rollen und suchen der Funktionen und Klassen verbunden.
Ganz besonders wenn man auch noch viele Namespaces verwendet.

Es gibt eine Funktion, der normalerweise kein Hotkey zugeordnet ist: View.SynchronizeClassView.

Der Name deutet es ja schon an, der Class View wird mit dem aktuellen Kontext synchronisiert.  Am Besten man weißt dieser Funktionen eine guten Hotkey zu und probiert die Funktion aus. Ich verwende hier Alt+A, S.

Diese Funktion zeigt den Class View an (auch wenn diese Tab-Seite aktuelle nicht aktiv ist), weiterhin wird sofort die aktuelle Klasse oder Funktion im Class View angezeigt, in dessen Kontext man sich aktuell befindet. Längeres Navigieren erübrigt sich.

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.

MFC 8.0 PDB Dateien mit und ohne Source Informationen

Gestern hat es mich überrascht, dass ich beim debuggen auf einmal nicht mehr in eine MFC Funktion mit der F11 Taste steppen konnte. Er sprang immer über diese Zeile. Selbst über die Assembler Ansicht war es nicht möglich die entsprechenden Source-Dateien der MFC im Debugger durch zu steppen.

❓ Eigentümlich. Ein kurzer Blick in die Debug Ausgabe und in die Liste der geladenen Module zeigte, dass die PDB Datei der MFC80UD.DLL aus meinem Symbol-Cache geladen wurden.
In der Modulliste stand als Info: Symbols loaded (source information stripped).
Ich verwende einen zentralen Symbol Cache auf unserem Entwicklungsserver und habe natürlich auch als http://msdl.microsoft.com/download/symbols als Quelle für unbekannte Symbole angegeben.

Scheinbar ist auf irgend einem Weg vom Symbolserver aus dem Netz eine Version in meinen Cache hineingelangt, die nicht alle Debug Informationen enthält. Also gerade die Informationen, die es mir erlauben durch den Sourcecode der MFC zu steppen.

Die entsprechende Version mit den Source Informationen befindet sich durch die Installation von Visual Studio im Verzeichnis C:\Windows\Symbols\dll. Auch in den Optionen für mein Visual Studio war zusätzlich natürlich korrekt auch C:\Windows\Symbols\dll als Pfad angegeben. Die dortigen PDB Dateien wurden jedoch offensichtlich ignoriert. Ein manuelles Nachladen aus diesem Verzeichnis half allerdings sofort.
Bei der nächsten Debug Session wurden jedoch wieder die Informationen aus dem Cache geladen.

Also was machen?

❗ Ich habe einfach die entsprechenden Symbol aus dem C:\Windows\Symbols\dll Verzeichnis in meinen Symbol Cache geladen. Das geht einfach mit dem entsprechenden symstore Befehl:

symstore add /r /f C:\Windows\Symbols\dll\*.* /s <My symbol store>

Und siehe da. Nun werden immer die richtigen PDB-Dateien geladen und Step-Into Befehl F11 verhält sich beim debuggen wieder wie gewohnt.

VS Tipps & Tricks: Blockmodus aus VC6 in VS.NET 2003 und VS 2005

Viele haben den Blockmodus (Box-Mode) in VC6 über die Tastatur benutzt. Diesen Modus erreichte man über die Tasten Strg+Umschalt+F8. Damit war es einfach Spalten und rechteckige Textbereiche zu markieren und zu bearbeiten.
Diese Operation konnte auch durch das Festhalten der Alt-Taste ausgelöst werden, wenn man mit der Maus den Cursor über einen Bereich zog.

Spätere Visual Studio Versionen haben dafür keinen direkten Hotkey mehr zwischen Box-Mode und Stream-Mode zu wechseln. Das Ganze wurde vereinheitlicht.
Ein Block wird markiert indem die Umschalt+Alt-Taste festgehalten werden und entsprechende Navigationstasten bewegt werden.
Eigentlich logisch und sogar dokumentiert, aber wer liest denn schon die Doku! 😛

http://msdn2.microsoft.com/en-us/library/aa301672(vs.71).aspx
http://msdn2.microsoft.com/en-us/library/729s2dhh(VS.80).aspx

Skibo, Young, Johnson: Arbeiten mit Microsoft Visual Studio 2005

Der Titel, ist etwas irreführend. Man muss hier den Untertitel ernst nehmen, der klarer sagt um was es geht: „Mit Makros und individueller Konfiguration Visual Studio 2005 optimieren“. Leider steht dieser Untertitel nirgendwo klar lesbar.
Das muss dem Leser/Interessenten von Anfang an klar sein!
Es geht hier weniger um das Arbeiten mit Visual Studio, als viel mehr um die Möglichkeiten, das bestehende Visual Studio 2005 anzupassen, zu erweitern und durch Makros Und Add-Ins Arbeiten zu automatisieren..

Das Ganze schließt Makros, Add-Ins, Assistenten ein und wir wollen die Starter-Kits nicht vergessen, auf die mich erst dieses Buch hingewiesen hat. Ein großer Part des Buches behandelt von der Erstellung von Add-Ins und später ein weitere großer Teil die Anpassungsmöglichkeiten von Visual Studio durch Makros.
Die Beispiele sind hauptsächlich in C# und bei den Makros natürlich in Visual Basic geschrieben. Man erhält einen relativ guten Einblick in das Objektmodell, das dem Entwickler zur Verfügung steht um Visual Studio an die eigenen oft speziellen Bedürfnisse anzupassen.
Beim „Tieftauchen“ habe ich allerdings gemerkt, dass trotz großem Angebot, doch Manches nicht möglich ist. Das liegt allerdings nicht an dem Buch, sondern an dem was die Entwickler von Microsoft in Visual Studio hineingepackt haben.

Am Ende wird das Buch leider zu einer besseren und ausführlichen Beschreibung der Makro Schnittstellen. Hier wären praktische Beispiele besser als nur zu zeigen wie, was, wo angesprochen wird. Ich vermute, dass die Autoren selbst von den Möglichkeiten überwältigt waren und sich dadurch (leider) auf das Nötigste beschränkten.

Trotz Übersetzung ist der Text flüssig und gut zu lesen, wobei der erste Teil ganz klar besser ist als der letzte. Da ich normalerweise englische Originale bevorzuge muss ich den Übersetzern ein Lob aussprechen. Der Ton hätte sicherlich an manchen Stellen etwas weniger trocken sein können. Aber das lag sicherlich auch an der Vorlage. Ich bin in letzter Zeit etwas mehr Humor auch bei technischen Büchern von MS-Press gewöhnt.

Als C++ Entwickler möchte ich darauf hinweisen, dass viele der beschriebenen Features wie z.B. das Exportieren von Vorlagen in C++ nicht zur Verfügung steht. Auch die sehr interessante Funktion zum Erzeugen von „Community-Content“ und Starter-Kits bleibt leider nur C#, J# und VB Programmierern zugänglich. Ein C++ Programmierer wird also beim Lesen dieses Buches öfters eifersüchtig werden.

3 Sterne

http://www.amazon.de/Arbeiten-Microsoft-Visual-Studio-2005/dp/3866454007

Der Application Verifier, mein neuer Freund

Durch die Vista Zertifizierung habe ich den Application Verifier von Microsoft als neuen guten Freund kennengelernt. Warum? Schauen wir uns mal den nachfolgenden Code an:

{
  CImageList il;
  il.Create(IDB_IMAGELIST,16,0,RGB(255,0,255));
  m_lcList1.SetImageList(&il,LVSIL_SMALL);
  m_lcList2.SetImageList(&il,LVSIL_SMALL);
  il.Detach();
}

Dieser Code ist natürlich fehlerhaft! Allerdings nicht ersichtlich auf den ersten Blick. Er erzeugt korrekt eine Image List. Setzt diese in ein List View 1 und auch in ein List View 2. Sofern LVS_SHAREIMAGELISTS nicht gesetzt wird die Image List beim Zerstören des List Views 1 freigegeben. Aber eben auch noch mal wenn List View 2 zerstört wird! Nicht gut.

Oder noch ein übles Beispiel:

{
  CImageList il;
  il.Create(IDB_IMAGELIST,16,0,RGB(255,0,255));
  m_lcList.SetImageList(&il,LVSIL_SMALL);
  ImageList_Destroy(il.m_hImageList);
}

Er erzeugt auch korrekt eine Image List. Setzt diese in ein List View und zerstört dann einmal die Image List über das Handle und anschließend noch einmal durch den Destruktor von CImageList. Und ein drittes Mal wird die Image List beim zerstören des List Views freigegeben. Übel übel!

Was passiert wenn dieser Code ausgeführt wird? Nichts…
Natürlich würde keiner so etwas programmieren 😉 . Aber man kann sich vorstellen, dass so etwas ablauftechnisch und programmiertechnisch schon mal passieren kann.
Alles ist scheinbar in Ordnung, obwohl hier eine Zeitbombe tickt.

Wie kommt man einem solchen Bug auf die Spur?
Der Titel dieses Beitrages gibt die Antwort: Der Application Verifier.

Man installiert den Verifier und fügt die Anwendung zu den Verifier Einstellungen hinzu. Man belässt es bei den Default Einstellungen und ergänzt am Besten noch unter Miscellaneous die Checkboxen für DangerousAPIs und DirtyStacks.

Sobald man nun den obigen Code im Kontext eines Debuggers ausführt bekommt man eine Exception! Wow… und wenn man einen entsprechenden Symbolserver hat und den Stacktrace betrachtet sieht man

comctl32.dll!CImageListBase::IsValid()+0x2a bytes
comctl32.dll!_HIMAGELIST_QueryInterface@12()+0x29 bytes
comctl32.dll!_ImageList_Destroy@4()+0x19 bytes

Das Ausgabefenster des Debuggers zeigt zusätzlich:

03D8F964 : Invalid address causing the exception.
75C273A8 : Code address executing the invalid access.
0012F08C : Exception record.
0012F0A8 : Context record.

Aus den Informationen kann man sich leicht denken was hier faul ist, oder sein könnte. Es empfiehlz sich die Anwendung auch im Release Mode mit Debug-Infos zu erzeugen. Das sollte sowieso Standard sein!

Es lohnt sich seine Applikation mal mit dem Application Verifier auszuführen, wenn man mal gerade nichts zu tun hat und man wundert sich dann, an welchen Stellen einem sein – so gut programmierter oder gut gemeinter – Code um die Ohren fliegt :mrgreen:

Für wen Qulitätssicherung kein Fremdwort ist, der kommt an diesem sehr nützlichen Tool nicht vorbei. Der Application Verifier und weitere brauchbare Infos findet sich hier auf der entsprechenden Produktseite von Microsoft:
http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/appverifier.mspx