Visual Studio 2005

Beim Debuggen in Visual Studio 2008 stört mich, dass bei CString-Objekten nicht mehr sofort die entsprechende Zeichenkette als InfoTip angezeigt wird. Stattdessen muss man den InfoTip erst erweitern, das gleiche gilt auch für die Anzeige der Variablen im Watch-Fenster:

Das hat mich an die Existenz der autoexp.dat erinnert, die es schon seit Visual Studio 6 gibt. Diese kann man um eigene Ausdrücke ergänzen, so dass der Debugger die Werte von bestimmten Datentypen gleich anzeigt. Die autoexp.dat befindet sich unter <VSInstallDir\Common7\Packages\Debugger> und sie kann mit einem einfachen Texteditor bearbeitet werden. Fügt man in der Sektion [AutoExpand] die beiden Zeilen

ATL::CSimpleStringT<char,1> = m_pszData=<m_pszData,s>
ATL::CSimpleStringT<wchar_t,1> = m_pszData=<m_pszData,su>

hinzu, dann sieht die Anzeige im Debugger gleich viel besser aus:

Beim Blättern in der autexp.dat sind mir auch die auskommentierten Zeilen

; see EEAddIn sample for how to use these
;_SYSTEMTIME=$ADDIN(EEAddIn.dll,AddIn_SystemTime)
;_FILETIME=$ADDIN(EEAddIn.dll,AddIn_FileTime)

aufgefallen. Google hat mich dann zum EEAddIn-Beispiel geführt, welches ich sogleich heruntergeladen und kompiliert habe. Der ersten Begeisterung folgte aber sogleich die Enttäuschung, denn es funktionierte nicht. Auch die explizite Angabe des Pfades oder das Anpassen der Funktionsnamen auf die wirklich exportierten Namen (_AddIn_SystemTime@28) wollte nicht helfen.

Wie debuggt man aber ein AddIn für den Debugger, welches nur geladen wird, wenn eine andere Anwendung gedebuggt wird? Ich habe mich für die universelle MessageBox-Methode entschieden, also an den wichtigen Stellen einfache MessageBox-Aufrufe eingebaut. Es zeigte sich, dass

// read system time from debuggee memory space
if (!pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper>GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot))
    return E_FAIL;

fehlschlug. Mein Bauch sagte mir, dass ReadDebuggeeMemoryEx anstatt eines BOOL-Wertes möglicherweise einen HRESULT-Wert zurückgibt. Nach der Änderung dieser Zeilen auf

// read system time from debuggee memory space
if (FAILED(pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper->GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot)))
    return E_FAIL;

wurde der Wert einer SYSTEMTIME-Variablen plötzlich wunschgemäß angezeigt:

Auch die FILETIME-Variable sieht nun wesentlich informativer aus:

Bei der Entwicklung eines Dateimanagers kommt man ja öfters mit FILETIME-Variablen in Berührung. Dank dem EEAddIn sieht man nun sofort den formatierten Wert, ohne dass man erst ein paar Zeilen für die Formatierung einfügen muss. So gut bin ich nämlich auch nicht im Kopfrechnen, dass ich aus den beiden DWORD-Werten der FILETIME-Struktur sofort auf das richtige Datum schließen kann.

Dank dem genialen Tipp von Martin habe ich das Projekt-Kontextmenü von Visual Studio endlich mal ein wenig übersichtlicher gestalten können. Seit Visual Studio 2005 war mir dies mit knapp 30 Einträgen doch ein wenig zu voll, die Übersichtlichkeit leidet unter den vielen Einträgen enorm.

Nach dem Hinzufügen von zwei Untermenüs („Source Safe“ und „Advanced“) und dem Wegsortieren der entsprechenden Befehle sieht es nun bedeutend übersichtlicher aus. Hier das Untermenü mit der Quellcodeverwaltung:

Und so schaut das Menü mit den weniger benötigten Befehlen aus:

In 15 Jahren Windows-Entwicklung habe ich in der IDE immer mit den Standardfarben gearbeitet, also dunkler Text auf hellem Hintergrund. Der weiße Fensterhintergrund war mir aber immer zu grell, daher war das erste nach einer Windows-Installation die Anpassung auf RGB(255, 251, 240). Nebenbei hatte das den Vorteil, dass man bei Zeichenoperationen gleich bemerkte, wenn man es mal vergessen hatte, die korrekte Hintergrundfarbe zu setzen. Der Nachteil waren die vielen HTML-Seiten im weltweiten Netz, deren Programmierer es wohl als überflüssig ansahen, eine weiße Hintergrundfarbe anzugeben.

Bei Damien Guard habe ich neulich ein Farbschema gesehen, das sehr angenehm aussah. An die Envy Code R VS-Schrift konnte ich mich nicht gewöhnen, mir ist sie (genau wie Consolas) etwas zu dünn. Nach einigen kleinen Anpassungen sieht das bei mir nun so aus:

Wer das auch mal ausprobieren möchte, der kann sich das Farbschema hier herunterladen. Die Installation in Visual Studio erfolgt über das Importieren von Einstellungen im Menü Tools.

Ich hatte ja schon geschrieben, dass ich auf der Grundlage von WndTabs ein Add-In für Visual Studio 2005/2008 entwickelt habe. Nach einem kleinen internen Praxistest habe ich nun beschlossen, das Add-In auch anderen interessierten Entwicklern kostenfrei zur Verfügung zu stellen.

Im folgenden nun eine kurze Beschreibung der wichtigsten Funktionen:

1. Registerkarten

Visual Studio zeigt zwar geöffnete Dokumente bereits als Registerkarten an, allerdings sind die Konfigurationsmöglichkeiten doch sehr eingeschränkt. EasyTabs bietet hier bedeutend mehr Flexibilität, die Registerkarten können entweder oben oder unten angeordnet werden. Eine weitere herausragende Eigenschaft ist das Gruppieren von Dateien. Dateien, die zueinander gehören (z.B. .cpp/.h/.idl), können zusammen auf einer Registerkarte angezeigt werden. Reicht der Platz nicht mehr für alle angezeigten Dokumente, dann zeigt EasyTabs die Registerkarten auch in mehreren Reihen an. So hat man immer auch wirklich alle geöffneten Dokumente im Blick.

2. Anordnung

Die Registerkarten für die geöffneten Dokumente können auf verschiedene Weise angeordnet werden. Im MDI-Modus werden die Fenster stets in der Z-Order angezeigt. Das heißt, dass sich die Registerkarte für das aktive Fenster immer ganz links befindet, rechts daneben befindet sich das zuvor verwendete Fenster usw. Alternativ können die Registerkarten auch alphabetisch angeordnet werden. In der Standardeinstellung werden die Dateien in der Reihenfolge ihres Öffnens angezeigt und behalten diese während der gesamten Sitzung auch bei.

3. Nummerierung

Jede Registerkarte erhält eine Nummer, die über mehrere Arbeitssitzungen erhalten bleiben kann. Die Nummer einer Registerkarte kann auf Wunsch angezeigt werden. Für die Aktivierung der Registerkarten 1 bis 9 können auch Tastenkürzel zugeordnet werden, so dass diese schnell erreichbar sind. Die Zuordnung der Tastenkürzel erfolgt über den Einstellungsdialog von Visual Studio.

4. Namen kürzen

Besonders lange Dateinamen kann EasyTabs bei der Anzeige auch kürzen. Dies kann über das Festlegen einer bestimmten Länge erfolgen, es ist aber auch möglich, bestimmte übereinstimmende Zeichen am Anfang und/oder am Ende des Dateinamens zu entfernen.

5. Menüs

Durch einen Klick mit der rechten Maustaste auf eine Registerkarte öffnet sich das Kontextmenü, welches Befehle zur Fenster- und Dateiverwaltung enthält. Hier kann z.B. des Schreibschutzattribut gesetzt oder gelöscht werden, zudem wird das Explorer-Kontextmenü für die jeweilige Datei angezeigt. Eine nützliche Funktion ist auch das Öffnen eines sich gerade in Bearbeitung befindenden Dialogs als Textdatei.

6. Anzahl der offenen Fenster begrenzen

Wer den Wald vor lauter Fenstern nicht mehr sieht, der kann festlegen, dass nur eine bestimmte Anzahl an Fenstern geöffnet bleiben soll. Beim Öffnen eines neuen Fensters schließt EasyTabs dann automatisch das Fenster, was am wenigsten verwendet wurde.

7. Während des Debuggens geöffnete Dateien automatisch schließen

Eine recht nützliche Funktion ist das automatische Schließen von Fenstern, die während des Debuggens geöffnet werden. Meistens handelt es sich dabei um Header- und Quellcodedateien von Bibliotheken (z.B. MFC), die beim Debuggen von Funktionen angezeigt werden. Nach einiger Zeit wird der Arbeitsbereich mit diesen Fenstern quasi überschwemmt, sofern sie nicht explizit wieder geschlossen werden.

EasyTabs übernimmt auf Wunsch das automatische Schließen nach jeder Debugsitzung. Im Einstellungsdialog kann festgelegt werden, auf welche Verzeichnisse hier geachtet werden soll.

8. IDE

Neben der Fensterverwaltung bietet EasyTabs noch zwei weitere Funktionen, welche die IDE erweitern. So kann der Dialogeditor gezwungen werden, auch in der Entwurfsansicht die Tastenkürzel der Dialogelemente anzuzeigen. Auch die Breite der Spalten im Stringtabelleneditor kann gespeichert und beim nächsten Öffnen wieder hergestellt werden.

9. Download

Dies war nur eine kleine Einführung in EasyTabs, im Einstellungsdialog sind noch ein paar weitere Funktionen zu finden. Für jede Einstellung ist eine Hilfe verfügbar, einfach auf das Fragezeichen in der Titelzeile des Einstellungsdialogs klicken und anschließend auf das Dialogelement selbst. Wer bis hierhin durchgehalten hat, der wird nun mit dem Downloadlink von EasyTabs belohnt.

Softwareentwicklung kann recht anstrengend sein, das weiß auch Microsoft. Ein kleines Spielchen zwischendurch kann die Gedanken etwas auflockern. Was liegt also näher, als ein solches Spiel nahtlos in die IDE von Visual Studio 2005/2008 zu integrieren?

Microsoft hat sich für eine abgewandelte Version von Memory entschieden. Es wird automatisch gestartet, wenn man im Dialogeditor die Tastenkürzel zuordnen möchte. Egal, wieviele Tastenkürzel man schon vergeben hat, die Ansicht ist immer die gleiche:

Leider hat man nicht daran gedacht, den Schwierigkeitsgrad einstellbar zu machen. Je älter der Programmierer umfangreicher der Dialog ist, umso schwerer wird es, das Spiel zu gewinnen. Auch die Länge des Spiels kann sich durchaus etwas hinziehen.

Um das Spiel etwas abzukürzen, habe ich meinem Add-In einen Cheat für eine Sofortlösung spendiert. Nach dem Öffnen des Dialogeditors werden die bereits vergebenen Tastenkürzel sofort angezeigt:

Eine weitere Sache, die mich auch etwas stört, ist die Spaltenbreite im Stringtabellen-Editor. Man kann die Spaltengrößen von „ID“, „Wert“ und „Beschriftung“ zwar beliebig ändern, bei der nächsten Anzeige sind letzten Positionen aber wieder vergessen. Auch hier bietet das Add-In Abhilfe und stellt die vorherigen Größen auf Wunsch automatisch wieder her.

Ich habe ja schon hier und da berichtet, dass ich WndTabs in Visual Studio 2005/2008 wirklich sehr vermisse. Wer WndTabs noch nicht kennt, dem empfehle ich eine kleine Tour durch die Funktionen. Insbesondere die erweiterten Funktionen, die man für 10$ freischalten konnte, erleichtern die Fensterverwaltung enorm.

In den letzten vier Wochen habe ich die meiste Zeit unter Visual Studio 2008 verbracht und musste schmerzhaft feststellen, dass ich mir bei ein paar mehr geöffneten Fenster mitunter sehr verloren vorkam. Einerseits steckt die Leiste mit den Registerkarten nun oben und liegt damit nicht mehr in meinem primären Blickfeld, zum anderen ist die schwarze Schrift auf dem doch recht dunklen Hintergrund nicht ganz einfach zu erkennen. Dazu fehlt natürlich auch die gewohnte Gruppierung von Header- und Quellcodedateien. Ich habe mich oft dabei ertappt, wie ich mit den Augen verzweifelt die Leiste abgrase, um die passende Datei zu finden. Zwar kann man die Reihenfolge durch Drag&Drop ändern (wie ich erst vor kurzem festgestellt habe), es wäre aber schön, wenn dies automatisch geschehen könnte. Zudem werden die Registerkarten nur in einer Reihe angezeigt. Reicht der Platz nicht aus, dann fallen sie links bzw. rechts herunter und sind nur noch über das Menü rechts erreichbar.

Der Wunsch nach einer vernünftigen Anzeige wurde also immer größer. Also habe ich mir den Quellcode von WndTabs geschnappt und mal geschaut, ob sich da etwas machen lässt. Nachdem die Kernbereiche lokalisiert waren, habe ich den Assistenten von Visual Studio ein neues AddIn-Projekt erstellen lassen und die wichtigsten Elemente von WndTabs eingearbeitet. Die Darstellung und Verwaltung der gruppierten Tabs war etwas schwerer, da diese nicht Bestandteil des verfügbaren Quellcodes sind.

Nach einer Woche Arbeit ist das AddIn nun einsetzbar. Zwar fehlen noch ein paar Funktionen (u.a. der Einstellungsdialog), die für mich wichtigen Sachen funktionieren aber erst einmal. Und so sieht das ganze nun aus:

Microsoft hat Veritest beauftragt, einen Produktivitätsvergleich zwischen ASP.NET und ASP.NET 2.0 zu erstellen. Zwei Entwicklerteams (ASP.NET und ASP.NET 2.0) wurde eine Projektaufgabe gestellt, die vorgegebene Zeit betrug fünf Tage. Der Auftrag war so formuliert, dass es schwer bzw. unmöglich war, ihn in dieser Zeit zu erfüllen.

Das Ergebnis der Studie zeigt, dass mit ASP.NET 2.0 deutliche Produktivitätssteigerungen möglich sind, die vor allem auch auf die neue Entwicklungsumgebung zurückzuführen sind. ASP.NET 2.0-Entwickler erledigen in der gleichen Zeit etwa 113% mehr Aufgaben als ASP.NET-Entwickler. Bei einigen Teilen der Aufgabe wurden einzelne Webseiten sogar bis zu 357% schneller erstellt.

Ob eine Studie für C++-Programmierer zwischen Visual Studio 6 und 2005 auch so ausgehen würde? 😉

Letzte Woche habe ich mich dazu gezwungen, alle Aufgaben mit Visual Studio 2005 durchzuführen. Nach vielen Jahren Entwicklung mit dem inzwischen acht Jahre alten Visual Studio 6 hat man sich aber an gewisse Dinge gewöhnt, die man ohne Zwang nicht so einfach aufgeben will. Dementsprechend hat es das VS2005 bei mir auch recht schwer, obwohl man meinen könnte, dass das sieben Jahre jüngere Produkt den alten Hasen ausstechen müsste.

1. Langsamer Editor

Ich benutze einige Makros, die mir vordefinierte Textblöcke auf Tastendruck an der aktuellen Stelle im Quelltext einfügen. Im VS2005 dauert das immer zwischen einer und zwei Sekunden, man kann dem Editor quasi dabei zusehen, wie er die aktuelle Zeile nach unten verschiebt und den Textblock einfügt. Der VC6 macht das so schnell, dass man die Zeit überhaupt nicht messen kann.

2. Projektmappen-Explorer

Die Baumansicht im Projektmappen-Explorer wird komplett neu gezeichnet, wenn man ein Projekt oder einen Ordner zum ersten Mal nach dem Start aufklappt. Klappt man ihn zu und wieder auf, dann geschieht das für diesen einen Eintrag in Zukunft ohne Flackern. Nach dem Schließen des letzten Fensters wird die Baumansicht ebenfalls sichtbar aktualisiert, obwohl hier eigentlich kein Grund dafür existiert. Das Flackern erzeugt bei mir eine ziemlich unruhige Stimmung. Leider wird auch der Status aller aufgeklappten Zweige gespeichert und beim nächsten Start wiederhergestellt. Im Gegensatz zum VC6 muss man daher alle aufgeklappten Einträge auch selbst wieder zuklappen, um bei umfangreichen Projekten nicht die Übersicht zu verlieren.

3. Geringfügig größere Fontdarstellung

Als Schriftart im Editor verwende ich schon seit vielen Jahren Courier New in Größe 10. Das Auge hat sich daran gewöhnt und möchte nichts anderes sehen. Natürlich lässt sich die gleiche Schriftart auch im VS2005 einstellen, allerdings scheint Microsoft hier andere Maße zu verwenden. Die wohlgemerkt gleiche Schriftart mit gleicher Größe (10) wird im VS2005 etwas größer dargestellt, so dass natürlich auch weniger Zeilen zu sehen sind. Ich habe es versuchsweise mal mit einer 9er-Schrift probiert, diese ist mir aber für die tägliche Arbeit zu klein.

4. Dialogeditor

Die Arbeit mit dem Dialogeditor ist extrem gewöhnungsbedürftig. Alle Angaben zu einem Dialogfeld werden nun im Eigenschaften-Fenster vorgenommen. Im VC6 erscheint auf Doppelklick oder <Enter> ein kleines Fenster, die verschiedenen Optionen sind auf mehreren Registerkarten gruppiert. Auf Wunsch kann das Fenster auch über einen Pin gesteuert ständig sichtbar bleiben. Genau dieses seit Jahren gewohnte Verhalten zum Ändern eines Textes wird einem im VS2005 zum Verhängnis. Ein <Enter> auf ein Dialogelement löscht einfach den Text des Elementes, und das auch noch ohne jedwede Undo-Möglichkeit. Man muss also den Text erneut eingeben (sofern man ihn noch weiß) oder VS2005 ohne Speichern der Dialogvorlage beenden und neu starten. Ich hatte das Problem natürlich auch im Betatest an Microsoft weitergeleitet, das ganze ist „Resolved as by Design“:

Thanks for reporting the issue. However, setting the cursor for the Caption property isn’t a guaranteed operation. Hence the decision is to do in-place editing of captioning. The behavior you see is an artifact of that.

Übrigens war dieses Problem auch schon im VS.NET 2003 enthalten. Für mich ist das immer noch ein klarer Showstopper.

Bei eigenen vordefinierten längeren Initialisierungstexten für Kombinationsfelder verliert man nun recht schnell den Überblick. Im VC6 sind diese Texte noch in einem mehrzeiligen Editierfeld bearbeitbar, in VS2005 hat man nur noch ein einzeiliges Editierfeld.

5. Stringtable-Editor

Öffnet man eine Stringtabelle zum Bearbeiten, dann werden die Einträge nicht automatisch nach aufsteigender ID sortiert, sondern in der Reihenfolge, wie sie in der jeweiligen .rc-Datei enthalten sind. Wenn man also auf eine sortierte Darstellung wie im VC6 Wert legt, dann bleibt einem nichts anderes übrig, als jedesmal zuerst auf die entsprechende Spalte zu klicken. Auch dies ist „Resolved as by Design“:

We encourage you to click on the column header to sort the way you want since there is no automatic sorting as you add or change items. Thanks for your report.

Mittlerweile hat Microsoft aber wohl ein Einsehen gehabt und einen Fix eingecheckt. Ich warte gespannt auf das SP1.

6. Eigenschaften-Fenster für Botschaften und Befehle

Das Eigenschaften-Fenster zum Hinzufügen von Handlern für Botschaften und Ereignisse ist kein Alternative zum gewohnten Class Wizard. Da sich der Inhalt des Eigenschaften-Fensters an die aktuelle Cursorposition anpasst, ist es nicht ganz einfach, einen Punkt zu finden, der einem das Bearbeiten ermöglicht. Nach meinen Erfahrungen muss man sich in der Headerdatei innerhalb der Klassendefinition befinden, allerdings nicht in einer Zeile mit einer Funktion. Im VC6 ist ein Tastendruck in der jeweiligen Quelltextdatei sehr viel fixer.

7. Zugriff auf die geöffneten Fenster

Die geöffneten Fenster werden im VS2005 als Registerkarten in einer Reihe angezeigt. Wenn man dann einmal ein paar mehr Fenster geöffnet hat, dann rutschen die zuerst geöffneten Fenster nach rechts heraus und sind nur noch über ein Menü erreichbar. Im VC6 verwende ich schon seit vielen Jahren WndTabs, welches die geöffneten Dateien auf Wunsch logisch gruppiert und auch ständig sichtbar hält. Leider gibt es keine Version für VS2005. Letztlich würde das wohl auch durch die geänderten Objektmodelle auf eine komplette Neuentwicklung hinauslaufen, und dazu fehlt Oz Solomon leider die Zeit.

8. Visual Assist

Der letzte Punkt ist eher Visual Assist zuzurechnen. Im VC6 verwende ich noch Visual Assist 6, in dem es die von mir heißgeliebte Funktion „Display best guesses in inverse tooltips“ gibt. Visual Assist analysiert dabei das Tippverhalten und schlägt zuletzt häufig benutzte passende Eingaben vor. Das inverse InfoTip verschwindet nach einer einstellbaren Zeitspanne von selbst, alternativ lässt sich mit <Tab> der angezeigte Text übernehmen. Die Trefferrate ist dabei äußerst beeindruckend. In der aktuellen Version von Visual Assist X für VS2005 werden statt einem Vorschlag gleich mehrere passende in einem Auswahlfeld angezeigt. Für mich ist das aber eher ein Rückschritt, da das Auge nun auf einen größeren Bereich zu achten hat.

Leider muss ich das Fazit ziehen, dass der VC6 für mich auch weiterhin die erste Wahl bleibt. Von den Funktionen her ist VS2005 ohne Zweifel sehr viel mächtiger, allerdings sind viele Kleinigkeiten, die für meine tägliche Arbeit wichtig sind, im VC6 viel besser gelöst. Für mich ist der VC6 einfach das ausgereiftere Produkt. Ich frage mich aber auch, ob ich der einzige bin, dem die oben erwähnten Sachen auffallen und stören.

Aufgefallen beim Debuggen mit Visual Studio 2005. Ungültiger Ptr wäre sicher passender, in der englischen Version heißt es Bad Ptr.

MSDN-Abonnenten können sich ab sofort eine aktualisierte deutsche MSDN Library für Visual Studio 2005 herunterladen. Neuerungen zur ersten Ausgabe liegen vor allem in der Dokumentation zu:

• Visual Studio 2005 Team Foundation Server
• SQL Server 2005
• Internet Information Server SDK
• Internet Security and Acceleration Server SDK

Bei der Installation wird die vorhandene deutsche Installation erkannt und die Aktualisierung angeboten, allerdings verlangt das Installationsprogramm nach einer „Visual Studio 2005 DVD“. Meine vorhandene MSDN-DVD, von der auch die Installation erfolgte, hat es nicht akzeptiert. Eine Deinstallation der alten MSDN Library und eine anschließende Neuinstallation brachte aber den gewünschten Erfolg.