Komfortabler Dateimanager mit vielen Funktionen

Visual Studio

Visual Studio 2005 (CTP Juni)

By Sven on 27.06.2005 - 22:28 in Visual Studio 2005

In den letzten Tagen habe ich mir die aktuelle Community Technology Preview vom Visual Studio 2005 installiert und damit etwas Zeit verbracht. Trotz einiger immer noch existierender Produktivitätsbremsen macht das Arbeiten mit VS 2005 zusehends mehr Spaß. Verantwortlich dafür sind einige nette Funktionen:

1. Projekte werden parallel erzeugt

Projekte, die unabhängig voneinander sind, werden auf Mehrprozessor-Maschinen parallel kompiliert. Die Anzahl der zeitgleich erzeugten Projekte ist abhängig von der Anzahl der Prozessoren. Auf meinem P4 mit Hyperthreading gibt es zwei logische Prozessoren, damit werden also zwei Projekte nebeneinander kompiliert. Beim nächsten Rechnerupdate lohnt es sich also wirklich einmal, einen Blick auf die Xeon-Prozessoren zu werfen.

2. Visual Assist ist nun auch für Visual Studio 2005 verfügbar

Die letzten Builds von Visual Assist unterstützen nun endlich auch das Visual Studio 2005. Wenn man sich einmal an Visual Assist gewöhnt hat, dann kann man ohne kaum noch arbeiten und fühlt sich sehr verlassen.

3. Hervorragender Debugger

Der Debugger ist eines der Sahnestücke in VS 2005, das Betrachten von Variablen während des Debuggens ist ein Traum. Man zeigt nur noch mit der Maus auf die entsprechende Variable und der Debugger zeigt eine Liste mit den Eigenschaften. Zeigt man wieder auf ein Objekt, dann wird auch dieses aufgeklappt und dessen Eigenschaften werden angezeigt:

Debugger

4. Automatisches Einfügen eines Manifests

Damit eine Anwendung unter XP auch im entsprechenden Design angezeigt wird, muss sie ein Manifest enthalten. Bisher hat man das Manifest als Entwickler immer in die Ressourcendatei eingebunden. VS 2005 führt nun einen neuen Linker-Schalter ein, der ein Manifest auf Wunsch automatisch in die Programmdatei aufnimmt. In einer normalen Anwendung hat das Manifest immer die ID “1” , in einer Dll (z.B. einer Explorer-Erweiterung) dagegen die “2”. Der Linker kümmert sich automatisch um die richtige ID, die folgenden Zeilen reichen völlig aus.

Diese Zeilen habe ich in eine Header-Datei gesteckt, die ohnehin in jedem Projekt eingebunden wird und allgemeine Eigenschaften definiert, die für alle Projekte gelten. Entsprechend der jeweiligen Plattform wird immer gleich das korrekte Manifest eingebunden, man muss sich nun nicht mehr mit Manifesten in Ressourcen herumärgern.

#if _MSC_VER >= 1400
#ifdef _M_IX86
   #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='x86' "                             \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif

#ifdef _M_AMD64
    #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='amd64' "                           \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif

#ifdef _M_IA64
    #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='ia64' "                            \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif
#endif

Unkaputtbar

By Sven on 25.06.2005 - 22:41 in MFC with 3 Kommentare

Seit meinem Umstieg auf Visual C++ vor knapp 10 Jahren programmiere ich mit der MFC (Microsoft Foundation Classes), und im Laufe der Jahre habe ich die MFC als eine verlässliche und robuste Bibliothek kennengelernt. Die MFC deckt alle Grundlagen für eine moderne Windows-Anwendung ab, kleine oder größere Erweiterungen findet man entweder im Netz oder programmiert man sich selbst.

In dem einen oder anderen Gespräch mit C++Entwicklern konnte ich feststellen, dass sich mit dem nahenden Longhorn und der Werbung für die schöne .nette Welt gewisse Ängste entwickeln, dass man in naher Zukunft mit C++ und der MFC nur noch im Regionalexpress fährt und vom .NET-Transrapid bald überholt wird. Ich selbst teile diese Ansicht nicht, denn auch in Longhorn wird .NET ein Aufsatz auf dem Betriebssystem bleiben. Das Windows-API wird natürlich weiter Bestand haben, da einerseits das gesamte Betriebssystem darauf aufbaut und Microsoft sich auch nicht erlauben kann, mit Longhorn einfach alle Brücken zu “alter” Software zu kappen. In diesem Fall müssten sie das gesamte Betriebssystem auf gänzlich neue Füße stellen, und das kann selbst Microsoft sich nicht leisten.

Auch Avalon und seine Beschreibungssprache XAML hat für den normalen Anwendungsprogrammierer keine wirkliche Bedeutung. Oder glaubt tatsächlich jemand, man könnte einen Dateimanager oder ein Packprogramm mit einer XML-Sprache programmieren? Das nun auf später verschobene WinFS wird sicher auch aus nativen Anwendungen ansprechbar sein, ansonsten wäre wohl keine Integration in den Explorer möglich.

Steve Teixeira hat nun einen Ausblick auf die Zeit nach Visual Studio 2005 gegeben, und dieser dürfte den einen oder anderen zweifelnden C++/MFC-Programmierer doch sehr erfreuen:

MFC continues to be the C++ application framework of choice for many developers because the breath and depth of support that MFC provides for the Microsoft platforms remains unmatched by other frameworks. Visual Studio 2005 makes it possible for the C++ developer to leverage existing C++ code, the strengths of MFC, and the advantages of .NET, all within a single application.

Looking beyond Visual Studio 2005, C++ developers should expect deepened integration between MFC and the .NET framework. After the release of Windows Longhorn, Microsoft intends to add MFC support for key Longhorn APIs and features. Microsoft also intends to support the Avalon user interface framework in MFC, providing MFC developers with a bridge to the future of platform user interface design. In essence, as the platform evolves, developers can look forward to seeing MFC updated to leverage the latest managed and native APIs and frameworks.

MFC developers have access to more frameworks than any other type of developer on the platform. As such, MFC developers are free to leverage the best from all worlds as it makes business and technological sense to do so. Microsoft fully expects to support this capability into the foreseeable future.

Also, auf die nächsten 10 Jahre!

Visual Studio 2005 (Beta 2) verfügbar

By Sven on 17.04.2005 - 22:41 in Visual Studio 2005 with 2 Kommentare

Gestern abend hat Microsoft still und heimlich die Beta 2 vom Visual Studio 2005 für MSDN-Mitglieder freigebeben. Die Installation verlief ohne Probleme und im Vergleich zu früheren Versionen auch deutlich flotter. Die Projekte von früheren Versionen lassen sich übernehmen, allerdings hat Microsoft die Bezeichnung für die AMD64-Buildkonfiguration von Win64 (AMD64) auf x64 geändert. Man sollte also vorher manuell mit einem Editor die alte Konfigurationsbezeichnung durch die neue ersetzen und dann auch in den jeweiligen Solutions die Anpassung vornehmen, wenn man mit den bisherigen Projekten weiterarbeiten möchte. Ansonsten wundert man sich, dass der Build-Befehl für 64bit-Projekte keine Funktion hat.

Die Beta 2 ist bis jetzt deutlich stabiler als die CTP vom Februar, die IDE selbst agiert bei Änderungen an den Projekten auch nicht mehr so schwerfällig. Weitere Erfahrungsberichte gibt es sicher in den nächsten Wochen.

Debug-Fix für Visual Studio 2005 (Beta)

By Sven on 13.04.2005 - 08:13 in Visual Studio 2005 with Keine Kommentare

Visual Studio 2005 ist eine 32bit-Anwendung und läuft im WoW64-Layer (Windows on Windows). Damit man nun auch 64bit-Anwendungen debuggen kann, benutzt VS2005 den Remote Debugger. Dies geschieht für den Entwickler völlig transparent, man merkt davon nichts.

Nach der Installation von VS 2005 (CTP vom Februar) auf der finalen Version von Windows x64 funktioniert leider das Debuggen von 64bit-Anwendungen nicht mehr, obwohl der Remote Debugger für Windows x64 korrekt installiert wurde. VS2005 zeigt die Meldung

Remote debugging components are not registered, but are required for debugging. On a 64-bit machine, these components are not installed with Visual Studio.

Mit der finalen Version von Windows x64 gab es noch einige kleine Änderungen bzgl. der 64bit-Registrierungsschlüssel. Damit man den Debugger auch hier zum Laufen bekommt, muss man im Ordner “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x64” den Befehl “msvsmon /regautolaunch” eingeben. Danach funktioniert der Debugger wieder wie gewünscht.

Nun kann ich WinDbg, den ich die letzten vier Tage benutzen musste, endlich deinstallieren und stattdessen wieder den gewohnten und komfortablen VS-Debugger benutzen. Vielen Dank an Ken Bayer von Microsoft, der mir dieses mitteilte.

Was stört in Visual Studio 2003?

By Sven on 03.02.2005 - 12:20 in Visual Studio 2003 with 1 Kommentar

Obwohl das Visual Studio 2003 nun schon seit 2 Jahren auf dem Markt ist, arbeite ich immer noch mit Visual C++ 6.0. Bisher habe ich mich zweimal an den Umstieg herangewagt, aber jedesmal bin ich reumütig zum VC6 zurückgekehrt. Die Gründe für die Unzufriedenheit liegen nicht im Compiler und im Debugger, denn die sind eine wirkliche Verbesserung. Das Problem ist die IDE selbst, der man anmerkt, dass sich ihre Zielgruppe eher aus .netten Entwicklern zusammensetzt.

Da ich immer wieder verwundert gefragt werde, warum ich immer noch am VC6 hänge, habe ich einmal das aufgelistet, was das effektive Arbeiten im VS2003 enorm behindert:

  • Nach der Bearbeitung eines Dialoges verschwindet das Tool-Fenster nicht wieder automatisch
  • Im VC6 bekam man im Dialogeditor mit <Enter> den Eigenschaftendialog (z.B. für ein Kontrollkästchen) angezeigt und konnte dann den Text ändern. Im VS2003 löscht <Enter> einfach den gesamten Text (auch noch ohne Undo!). Ist mir desöfteren passiert und nervt ungemein!
  • Die Stringtabelle wird nicht sortiert, bei jeder Anzeige muss man dies jedesmal per Hand machen.
  • Beim Einfügen von neuen Strings werden diese ständig hinten angehangen, der VC6 fügt sie an der entsprechenden Stelle ein.
  • Im VC6 wurden in der Stringtabelle alle 16 Einträge eine Linie gezeichnet, das hat die Übersichtlichkeit sehr erhöht.
  • Die Eigenschaften (z.B. für einen Button) sind jetzt alle in einem Eigenschaftenfenster. Im VC6 waren sie logisch gruppiert, daher sucht man im VS2003 jedesmal nach der richtigen Option.
  • In meinen Projekten verwende ich einige Ordner, um die Dateien zu gruppieren. VS2003 sortiert ab Ebene 2 grundsätzlich die Dateien vor die Ordner. So sucht man jedesmal nach einer Datei, weil sie nicht da ist, wo man sie vermutet.
  • Wenn man mehrere Ordner in einem Projekt aufgeklappt hat, dann merkt sich VS2003 den Aufklappstatus (auch nach dem Beenden). Ich bin es gewohnt, dass die Ordner beim nächsten Mal wieder alle geschlossen sind.
  • Mit F4/Umschalt+F4 bewegt man sich nach dem Kompilieren durch die einzelnen Fehler. Im VC6 wird der Cursor automatisch auf die jeweilige Zeile gesetzt, im VS2003 bleibt der Fokus auf der Fehlerliste und man muss nach F4 jedesmal <Enter> drücken, um in das Quellcodefenster zu gelangen.
  • Beim Suchen durch Dateien konnte man sich im VC6 auch mit F4/Umschalt+F4 durch die Ergebnissliste bewegen und die entsprechende Datei wurde mit der Fundstelle geöffnet.
  • Im Dialogeditor werden beim Design nur Tastenkürzel angezeigt, wenn die globale Windows-Option ‘Unterstrichene Buchstaben für Tastaturnavigation ausblenden (mit Alt-Taste einblenden)’ aktiviert ist. Ich habe diese standardmäßig ausgeschaltet, und damit kann man die Tastenkürzel für die einzelnen Elemente nur durch Raten vergeben.
  • Bei den Projektoptionen ist es nicht möglich, die Optionen für mehrere Projekte gleichzeitig zu ändern. So muss man den Dialog jedesmal öffnen/schließen.
  • Der Build-Befehl gilt immer für das Projekt, was gerade im Solution-Explorer bzw. im Quelltextfenster aktiv ist. Im VC6 wählt man ein Startprojekt aus und die Befehle gelten dafür. Allerdings gibts für VS2003 auch ein entsprechendes AddIn (Fast Solution Build), das funktioniert aber nicht immer zu 100%.
  • Wenn man eine Datei zum Bearbeiten aus der Quellcode-Verwaltung auscheckt, dann braucht man im VC6 im Bestätigungsdialog nur <Enter> drücken. Im VS2003 ist da aber ein mehrzeiliges Kommentarfeld und <Enter> geht dann natürlich dahin. Kann man zwar hart in den Ressourcen ändern, stört aber.
  • Für den VC6 nutze ich WndTabs, das die geöffneten Dateien logisch gruppiert und ständig sichtbar hält. Im VS2003 hat man nur eine Leiste und muss ständig mit der Maus hin- und herscrollen. Dazu wechselt <Strg+Tab> anhand der MDI-Reihenfolge und nicht anhand der in der Tableiste angezeigten Reihenfolge.
  • Das wichtigste: Der Class-Wizard fehlt, alles geht nun umständlich über Eigenschaftenfenster. Die überschriebenen Methoden und Windows-Nachrichtenhandler werden nicht mehr geordnet in die Header-Datei geschrieben, im VC6 gab es jeweils dafür bestimmte Sektionen. Meine Projekte gleichen sich in den Hauptklassen und Dateinamen (z.B. MainFrame.cpp). Mir ist es hier öfters passiert, dass der neue Handler in einem anderen Projekt eingefügt wurde, wenn die Datei- und Klassennamen in mehreren Projekten vorkommen. Dazu wird in der Quelltextdatei “#include “.\MainFrame.h” eingefügt, obwohl “#include “MainFrame.h” schon vorkommt.

Leider macht es einen Microsoft immer schwerer, mit dem VC6 weiter zu arbeiten. Mit den LIB-Dateien vom letzten Platform SDK für XP SP2 kann der VC6 nicht mehr umgehen und auch mit den Symboldateien vom SP2 kommt er nicht mehr klar. Mein großer Wunsch ist immer noch, dem VC6 die Fähigkeit verpassen zu können, mit dem neuen PDB-Format des VS2003 umgehen zu können. Dann könnte man einfach den Compiler und Linker austauschen und wäre wieder auf dem neuesten Stand. Aber das wird wohl leider nur ein Wunschtraum bleiben.

In den nächsten Wochen werde ich einmal testen, inwieweit die aktuelle Preview von VS2005 das eine oder andere Problem abstellt oder ob ich auch in Zukunft weiter auf den VC6 zurückgreifen muss.

Benannte Threads

By Sven on 17.01.2005 - 10:46 in Visual Studio 2003, Visual Studio 6

Beim Debuggen von Anwendungen mit mehreren Threads fragt man sich mitunter, in welchem Thread man sich gerade durch den Debugger quält. Im VC6 gibt es ein Thread-Fenster, was aber nur den Namen der Startfunktion des Threads bzw. den der aktuellen Funktion anzeigt. Sobald man mehrere Threads mit den gleichen Funktionen zu debuggen hat, wird die Unterscheidung schwer, welcher Thread gerade aktiv ist:

Normale Threadanzeige

In der MSDN-Library ist beschrieben, wie man durch das Auslösen einer bestimmten Exception die einzelnen Threads benennen kann. Hierzu wird eine Struktur definiert, die u.a. mit dem Namen und der entsprechenden Thread-ID initialisiert wird. Anschließend wird eine Exception ausgelöst. Erfolgt der Aufruf zum Setzen des Namens für den aktuellen Thread, so kann als Thread-ID auch -1 übergeben werden. Zu beachten ist, dass der Name des Threads immer in Ansi (und nicht in Unicode) angegeben wird.

typedef struct tagTHREADNAME_INFO {

    DWORD       dwType;             // Typ (muss 0x1000 sein)
    LPCSTR      pszName;            // Zeiger auf den Threadnamen (ANSI)
    DWORD       dwThreadID;         // Thread-ID (-1 fuer den aufrufenden Thread)
    DWORD       dwFlags;            // Reserviert (muss 0 sein)

} THREADNAME_INFO;

void Lwl_SysSetThreadName(DWORD dwThreadID, LPCSTR pszThreadName)
{
    // Struktur initialisieren
    THREADNAME_INFO info;
    info.dwType = 0x1000;
    info.pszName = pszThreadName;
    info.dwThreadID = dwThreadID;
    info.dwFlags = 0;

    // Exception generieren
    __try
    {
        RaiseException(0x406D1388, 0, sizeof(info)/sizeof(DWORD), (DWORD_PTR*) &info);
    }

    //
    __except(EXCEPTION_CONTINUE_EXECUTION)
    {
    }
}

Beim Aufruf des Thread-Fensters werden die Threads nun mit ihrem Namen angezeigt. Beim VC6 besteht leider eine Limitierung des Namens auf 9 Zeichen, die im aktuellen Visual Studio 2003 aber aufgehoben ist.

Threadanzeige mit angepasstem Namen

Auch in der .netten Welt mag es manchmal hilfreich sein, wenn man mehrere Threads anhand des Namens unterscheiden kann. In der Regel präsentiert sich das Thread-Fenster wie folgt:

Normale Threadanzeige (.NET)

Der Threadname für den Debugger lässt sich direkt über die Eigenschaft Name der Thread-Klasse des .NET-Frameworks festlegen.

Public Class Form1 : Inherits Form
    Class Needle

        ' This method will be called when the thread is started
        Sub Baz()
            Console.WriteLine("Needle Baz is running on another thread")
        End Sub

    End Class

    Public Shared Sub Main()
        Console.WriteLine("Thread Simple Sample")
        Dim oNeedle As New Needle()

        ' Create a Thread object
        Dim oThread As New Thread(AddressOf oNeedle.Baz)

        ' Set the Thread name to "MainThread"
        oThread.Name = "MainThread"

        ' Starting the thread invokes the ThreadStart delegate
        oThread.Start()

    End Sub

End Class

Der Zugriff auf das Thread-Objekt des Prozesses erfolgt über Thread.GetCurrentThread. Nach dem Setzen der Threadnamen sieht das Fenster im Debugger nun so aus:

Threadanzeige mit angepassten Namen (.NET)

Top