Tipps & Tricks:Entzerren komplexer Pre- und Post-Build-Steps durch eigene Utility Projekte

Ich habe einige komplexe Projekte in die auch andere Tools eingebunden sind. Diese Tools erzeugen Dateien und Ressourcen erzeugen, die mit in den kompletten Build eines Projektes einfließen. Zum Teil sind es Daten, die auf einen speziellen Weg kompiliert werden oder auch Ressourcen, die durch ein sekundären anderen Compiler erst mit verarbeitet werden müssen.

Teilweise hatte ich diese Prozesse in einen Pre– und Postbuild Step eingebaut. Leider verhält sich Visual Studio oft genug eigentümlich, es merkt nicht das abhängige Dateien während des Build Prozesses verändert werden.

Bei einer Umstellung meiner Projekte stellte ich fest, dass es weitaus einfacher ist für solche speziellen Vorgänge eigene kleine Projekte zu erzeugen vom Typ „Utility„.

In diesen Projekten kann man einfach Ein- und Ausgabedateien definieren und den Befehl, der dazu notwendig ist die Daten eben zu bearbeiten.
Das Ganze wird dann in eine Master Solution kombiniert mit den entsprechenden Abhängigkeiten. Das hat vor allem auch den großen Vorteil, das auch die Projekte parallel im Build durchlaufen werden können.

Utility Projekte sind für manche Aufgaben weitaus besser geeignet als Pre– und Postbuild Steps. Vor allem werden durch die Verwendung von Utility Projekten die einzelnen Vorgänge entzerrt und verständlicher.

Acceleratoren in Dialogen für Felder ohne Prompt bzw. Static Control

Mit Alt+Buchstabe ein Feld in einem Dialog anspringen ist der Tastaturliebhaber gewöhnt.
Aber was mach man wenn man keinen Platz für ein Static Control hat vor dem entsprechenden Eingabefeld. Oder wenn solch ein Static gar nicht in das Design passt, oder gar eine Grafik enthalten soll.

Man könnte PreTanslateMessage überschreiben und mit Hooks Klimmzüge veranstalten. Aber es geht weitaus einfacher.

Man kann das Static Control an die korrekte Stelle in der Z-Order platzieren und dann einfach auf „Invisible“ setzen. Der Accelerator funktioniert trotzdem.
Nur Statics, die disabled sind werden als Acceleratoren ignoriert. Das Acceleratoren auch für nicht sichtbare Controls funktionieren habe ich bereits in diesem Artikel Button + Accelerator + ShowWindow(SW_HIDE) – EnableWindow(FALSE) = Falle erwähnt.

Anmerkung:
Damit ein User weiß das Acceleratoren für dieses Feld funktionieren sollte ein sichtbarer Hinweis im Handbuch existieren. Da aber wenige Menschen überhaupt Handücher verwenden :mrgreen: eignen sich hier Tooltips für den entsprechenden Hinweis.  Etwa so wie das VisualStudio macht mit Show shortcut keys in ScreenTips

VS Tipps & Tricks: Schnellere Lernkurve durch sichtbare Tastatur Shortcuts

Wie kann man eigentlich lernen noch schneller mit Visual Studio umzugehen?
Ein Weg ist sicherlich die Maus zu umgehen und mehr mit der Tastatur zu machen. Dazu ist es aber auch notwendig, die entsprechenden Tastaturbefehle zu kennen.

Ein einfaches Hilfsmittel ist es die Tastatur Shortcuts auch in den Buttons der Toolbars anzeigen zu lassen. Das geht einfach über Tools -> Customize -> Show shortcut keys in ScreenTips.

Die Tooltips der Buttons enthalten, dann auch den Shortcut, der diesen Befehl auch auslösen würde. Auf diese Weise erhält man z.B. schnell die Info, dass Strg+D in das Suchfeld springt.

VisualStudio 2008 SP1 wird ab dem 11.08.2008 auf MSDN zum Download bereitstehen

Die englische Version des Microsoft SQL Server 2008 wurde gestern am 06.08.2008 veröffentlicht.

Auf der Startseite der MSDN Subscriptions findet sich folgende hoch interessante Information:

SQL Server 2008 RTM Available for Download

English downloads are available now and additional languages will be added on a daily basis. Visual Studio 2008 users will need to download and install Service Pack 1 which will be available here after August 11, 2008.

Das heißt, dass wir ab Montagmorgen mit dem finalen SP1 für Visual Studio 2008 rechnen dürfen, zumindest in der englischen Version. Ich befürchte, dass die deutsche Version noch ein paar Tage mehr auf sich warten lässt.
Wie immer ein Grund nur mit den englischen Entwicklungswerkzeugen zu arbeiten :mrgreen:

Tipps & Tricks: #import durch #include ersetzen

Nicht wenige verwenden, wie ich auch COM Komponenten, aus dem eigenen Haus oder von Fremdherstellern. Eingebunden werden diese COM-Komponenten oft genug über das #import Statement, das ja eine wirklich simple Integration erlaubt.

Lästig ist nur, dass diese Komponenten nicht auf allen Rechnern in den selben Verzeichnissen liegen. Das macht es nicht leicht Projekte und Entwicklungmaschinen so auszustatten, dass alle Projekte gleich zu kompilieren sind. Da fängt es schon an, dass ein Entwickler ein englisches OS (C:\Program Files), ein andere ein deutsches (C:\Programme) und der dritte Entwickler benutzt das Installationverzeichnis der zu entwickelnden Komponente (C:\Dev\Project\Bin).

Aus diesem Grund bin ich dazu übergangen das #import Statement nur einmal auszuführen, und die entstehenden .tlh und .tli Dateien direkt in das Projekt aufzunehmen.
Zu schnell? OK, also schrittweise:

  • Ich binde die Komponente also wie gewohnt per #import ein.
  • Die entstehenden .tlh und evtl. auch die .tli Dateien werden in das Projektverzeichnis kopiert und in das Projekt aufgenommen.
  • Das das #import Statement wird nun auskommentiert und statt dessen entsprechende #include Statements eingesetzt.
  • Nachdem man das auch korrekt mit entsprechenden Versionsangaben der Komponente dokumentiert hat und auch dieses Verfahren in die Projektbeschreibung aufgenommen hat ist man fertig!

Vor- und Nachteile:

  • Nicht nur, dass dieses Projekt unabhängig kompiliert werden kann. Das Kompilieren ist auch noch schneller, denn die (an sich) statischen .tlh und .tli Dateien werden nicht immer neu erzeugt.
  • Vorrausetzung ist hier sicherlich, dass es sich hier um Komponenten handelt, deren Interface sich nicht mehr verändert, und man muss bei einem Update der Komponente natürlich auch manuell die neuen .tli und .tlh Dateien einbauen.
  • Ein weiterer Vorteil ist auch, dass das Interface fest eingebunden wird, das auch für die Auslieferung festgelegt wird und keine alte/oder neuere Version zu Überraschungen führt.
  • Was auch zu dem genialen Verhalten führt, dass man aus dem Sourcecontrol System eine Software Version erzeugen kann, die noch mit einer älteren/abweichenden COM Komponente erzeugt wurde ohne diese auch noch mal installieren zu müssen!

VS Tipps & Tricks: Fehler in Custom Build Steps ermitteln

Manchmal macht man ja schon komplexere Sachen in den Custom-Build-Steps, wie zum Beispiel auch das Erzeugen der HTML-Help Include Datei. Aber es geht ja noch viel komplizierter, zumindest benutze ich solche komplexen Custom-Build Funktionen ziemlich häufig!

Was nun, wenn man eine Fehlermeldung erhält in solch einem Custom-Build-Step, aber gar nicht weiß wo der Batch eigentlich aussteigt, oder was er gerade getan hat ❓ Besonders wenn die Ausgabe im Build-Fenster so informativ ist wie:
Das System kann den angegebenen Pfad nicht finden.

Das eigentliche Problem ist, dass die Batch-Zeilen bei der Ausführung nicht angezeigt werden.
Man könnte meinen, dass Visual Studio dies mit einem mystischen Trick macht. Sieht man sich jedoch die Build-Log Datei an, so sieht man, dass vor einen Custom-Build-Step einfach immer ein @echo off eingebaut wird.
Was spricht eigentlich dagegen als erste Zeile ein @echo on in den Custom-Build einzusetzen? Nichts!

Gesagt getan!
Die Folge: Jede Zeile des Batches, der im Custom-Build durchlaufen wird, erscheint brav in der Build-Ausgabe. Einen Fehler zu finden, bei man z.B. einen Pfad falsch mit Makros zusammengebaut hat ist nun denkbar einfach.

TFS-2008 mit Visual Studio 2005 und anderen älteren Entwicklungssystemen benutzen

Ist man eigentlich gezwungen Visual Studio 2008 zu verwenden wenn man Team Foundation Server 2008 nutzt?

Nein! Wenn man Visual Studio 2005 und 2008 nutzt, wie auch ich für einige Projekte, dann kann man ohne weiteres trotzdem aus allen Systemen auf TFS-2008 zugreifen.
Man muss nur den passenden Team Explorer installieren. D.h. für Visual Studio 2005 installiert man einfach den Team Explorer 2005. Der 2005er Explorer steht übrigens auch kostenlos zum Download zur Verfügung, wer evtl. keine Version des TFS-2005 hat (http://www.microsoft.com/downloads/details.aspx?FamilyID=46473C2A-BB85-4461-BB27-4792A5DEF222&displaylang=ja&displaylang=en)

Es ist klar, dass man in diesem Fall einige Features des TFS-2008 nicht benutzen kann, bzw. nur über den Team Explorer 2008. Aber das ist ja auch nicht weiter tragisch.
Tunlichst vermeiden sollte man aber neue Team-Projekte aus dem 2005er Explorer heraus anzulegen, das schlägt bei mir fehl.  Also neue TFS-Projekte zuerst im Team Explorer 2008 anlegen und dann mit Visual Studio 2005 bearbeiten.

Das Source Control System von TFS-2008 lässt sich übrigens mit den entsprechenden Microsoft Source Code Control Interface (MSSCCI). Ein entsprechendes Plugin gibt es hier zum Download: http://www.microsoft.com/downloads/details.aspx?familyid=faeb7636-644e-451a-90d4-7947217da0e7&displaylang=en. Diese Liste der unterstützen Systeme ist lang:

  • Visual Studio .NET 2003
  • Visual C++ 6 SP6
  • Visual Visual Basic 6 SP6
  • Visual FoxPro 9 SP1
  • Microsoft Access 2003 SP2
  • SQL Server Management Studio
  • Sparx Systems Enterprise Architect 6.1
  • Sybase PowerBuilder 10.5
  • Toad for SQL Server 2.0

VS Tipps & Tricks: Kontextmenüs in Visual Studio anpassen

Man kann ja ohne weiteres Toolbars und die Menüs in Visual Studio anpassen, was ich auch gerne nutze.

Besonders interessant ist es aber auch die verschiedenen Kontextmenüs anzupassen. Dazu muss man zu einem kleinen Trick greifen, denn die Kontext Menüs stehen normalerweise nicht automatisch im Zugriff beim Anpassen der UI.

  • Man wählt Tools -> Customize -> Toolbars
  • Dort dann Context Menus auswählen -> Kontextmenü

Es öffnet sich nun ein neuer Toolbar, in dem die Kontextmenüs alle erscheinen und können wie gewohnt angepasst werden.

Gar nicht schwierig, man muss nur wissen wie man dran kommt 😉

Microsoft Visual Studio 2008 Service Pack 1 Release Candidate wurde veröffentlicht

Seit dem 06.07.2008 steht für Visual Studio 2008 auf Microsoft Connect ein Download für den Release Candidate des Microsoft Visual Studio 2008 Service Pack 1 zur Verfügung.

Dann kann man ja hoffen, das es bis zur Freigabe des SP1 nicht mehr lange dauert… 😉

Anmerkung: Es ist möglich, dass dieser Download nur Teilnehmern des SP1 Beta Programms zur Verfügung steht.

MFC Fenster in anderen Applikationen verwenden…

Manch ein Programmierer kommt auf die Idee und entwickelt ein Plugin mit der MFC für ein anderes Programm. Dass Plugin oder die entsprechende Funktionalität soll alleine in einer Standard-DLL leben. Die Schnittstelle wird bewusst schmal und einfach gehalten. Manche dieser kleinen Tools müssen/wollen nun auch ein Fenster nicht modal anzeigen.
Kein Problem, einfach CWnd::Create, oder CDialog::CreateIndirect und schon hat man sein Fenster.

Eines muss an dieser Stelle klar sein ❗
Man verlässt sich in einem solchen Fall, dass die hostende Anwendung eine Messageloop bereitstellt. Andernfalls bekommt das Fenster keine Nachrichten. OK!

Was einem aber auch klar sein muss in diesem Fall ❗
Man kann PreTranslateMessage nicht mehr verwenden. Das würde nur gehen, wenn man eine Extension DLL hat, oder die hostende Anwendung als auch die DLL beide die MFC als Shared DLL in derselben Version verwenden.
Damit ist nun auch verbunden, dass evtl. Tooltips in diesem Fenster ein sehr eigenwilliges Leben führen werden.

Es gibt einfach keinen vernünftigen Weg sich in die Messageloop eines Hosts auf einfache und vernünftige Art einzuklinken.
Ein Ansatz an dieser Stelle wäre sicherlich ein entsprechender WH_GETMESSAGE Hook. Denkbar wäre dann die entsprechende Nachricht abzufangen und an die eigenen Fenster via PreTranslateMessage anzubieten, sofern eben die eigenen Fenster den Focus haben oder die Nachricht für eines dieser eigenen Fenster oder Kindfenster bestimmt sind. Eben genauso wie es die MFC in seiner Messageloop macht. Dieses Verfahren wird auch für ActiveX Controls in der MSDN im KB Artikel 194292 empfohlen.

Siehe auch Wann Message Reflection nicht funktioniert!