Wie hängen Tools wie SVN und Git an Windows Explorer an, so dass sie Optionen zum Kontextmenü hinzufügen und das Häkchen/Ausrufezeichen je nachdem, ob eine Datei bearbeitet wurde, hinzufügen?Windows Explorer-Add-Ons
(Ich bin nicht nach Git oder SVN-spezifische Informationen - habe ich sie nur als Beispiele)
Was Sie wollen, heißt Shell-Erweiterungen, sind in-Prozess-COM-Objekte, die die Fähigkeiten von Windows-Betriebssystem erweitert.
alt text http://www.csscript.net/help/Images/ShellExt2.PNG
können Sie diese Links
Bye sehen.
Explorer DLLs ermöglicht als Shell-Erweiterungen zu registrieren. Eine Shell-Erweiterung kann Kontextmenüelemente, Symbol-Overlays und zahlreiche andere Funktionen bereitstellen. Dies geschieht durch das Freilegen bestimmter COM-Schnittstellen, die der Explorer z. vor dem Anzeigen eines Menüs oder eines Symbols. Hier ist die MSDN home page for shell extensibility - obwohl seltsam genug das Zeug über Kontextmenüs und Icon-Overlays scheint nicht mehr da zu sein - müssen Sie möglicherweise das Offline-SDK unter Win32 und COM-Entwicklung | Benutzeroberfläche | Windows Benutzererfahrung | Windows-Shell | Shell Entwicklerhandbuch | Integration von Anwendungen in die Shell.
Abhängig von der Shell-Erweiterung, die Sie wollen, können sie sehr komplex zu implementieren sein. Ich weiß nicht, wonach du suchst, um schnell eine schöne Erweiterung zu schreiben oder um ins Wesentliche zu kommen und alles von allem zu lernen. Wenn Sie nicht so besorgt über die, wie sind, und haben nur ein paar Ideen, die Sie implementieren möchten, überprüfen Sie diese Bibliothek aus für Erweiterungen Shell zu schreiben ...
EZShellExtensions MFC
EZShellExtensions.NET
Es gibt eine Menge von verschiedene Typen:
- Kontextmenüs
- -Eigenschaftenseiten
- Icon Handlers
und viele mehr ...
Sie haben auch eine andere Bibliothek zum Schreiben von Namespace-Erweiterungen (Dinge, die im Baumfenster von Windows Explorer angezeigt werden).
Sie verknüpfen mit der .NET-Edition dieses Frameworks. Benutze das niemals! Schreiben Sie niemals eine Shell-Erweiterung in .NET. Hier ist warum: http://blogs.msdn.com/oldnewthing/archive/2006/12/18/1317290.aspx – Stefan
Interessanter Punkt. Hatte nicht daran gedacht. Ich denke, dass dies je nach Zielgruppe ein Problem sein kann oder auch nicht. Wenn Sie für eine gut kontrollierte Zielgruppe schreiben (z. B. wie Intranet-Websites auf JUST IE abzielen und andere Browser ignorieren können), ist das möglicherweise kein Problem, aber für die Veröffentlichung ist es ein guter Punkt, den Sie in Betracht ziehen sollten. Meine Antwort wurde aktualisiert, um die MFC-Version einzuschließen. – eidylon
Es ist kein Problem von IE im Vergleich zu anderen Browsern. Das Problem ist, dass jede App, die Plugins verwendet, kaputt gehen kann. Stellen Sie sich eine native App vor, die COM-Plugins verwendet, und eines dieser COM-Plugins ist in .NET geschrieben. Wenn die App einen Dialog zum Öffnen/Speichern von Dateien verwendet hat, bevor sie das Plugin laden muss, kann das Plugin nicht geladen werden, da aufgrund dieser fehlerhaften Shell-Erweiterung bereits eine andere .NET-Laufzeitumgebung geladen wurde. Eigentlich ist es nicht einmal nötig, einen Datei-Öffnen/Speichern-Dialog zu verwenden: Selbst einige oft benutzte 'normale' Shell-Funktionen wie SHGetFileInfo() reichen aus. Und ja: Ich habe eine App, die bricht, wenn solche Shell-Erweiterungen installiert sind – Stefan