2010-12-12 50 views
1

J'ai une application C# WPF. Il est conçu pour fonctionner sur tous les fichiers. À l'heure actuelle, il accepte 'input' au moyen d'arguments en ligne de commande ainsi que de glisser-déposer vers un contrôle dans sa fenêtre principale. Cependant, idéalement, je veux que les gens cliquent avec droit n'importe quel fichier/plusieurs fichiers et qu'ils puissent simplement cliquer sur "Awesomify this". (Ce n'est pas le vrai nom.: P)Méthode recommandée pour le mélange des menus contextuels .NET et des fichiers

J'ai une certaine expérience avec les menus contextuels d'il y a des années, donc dans l'ensemble, ce n'est pas trop courant. En tant que tel, je suis à la recherche de conseils sur la meilleure façon de mettre en œuvre cette fonctionnalité. Tous les exemples suivants sont basés sur ce que je vois en utilisant W7.

Généralement, je comprends qu'il y a essentiellement deux façons: registre pur, et registre + objet COM.

Le premier a une certaine élégance, car je ne veux rien de spécial; cependant, d'après ce que je peux dire par la documentation, ces éléments de menu se regroupent toujours au même endroit que les actions du fichier principal (Open, Aperçu, Imprimer). Cependant, j'aimerais que mon objet apparaisse plus bas sur le totem. Si je regarde mon menu contextuel personnel pour un fichier aléatoire, je voudrais qu'il soit à la «place» UltraEdit et Malwarebytes Anti-Malware s'en tenir eux-mêmes. Coller mon entrée sous HKCR\*\shell\AwesomeTest obtient moi mon article, mais peu importe ce que je choisis pour le Position, je reçois deux extrêmes différents je n'aime pas: Top le met au-dessus de l'élément par défaut, Bottom le met juste au-dessus Propriétés. Je veux entre Partager avec et Restaurer les versions précédentes, où la plupart des outils à usage général semblent trouver une maison.

Certains creuser plus de registre semble indiquer les applications que je souhaite imiter utiliser la route d'objet COM. Et cela me ramènerait (je crois) au code natif. Ce qui apporterait alors avec lui tous les enfers de développement 32 bits et 64 bits que j'essaie d'éviter.

Y at-il quelque chose qui me manque? De même, autre que le MSDN page regarding context menu handlers que j'ai regardé à travers et trouvé être plutôt inutile (comme il semble parcourir beaucoup sans plonger dans les détails plus précis concernant le placement et autres), y at-il de bonnes sources concernant ce problème?

Une autre chose que je n'ai pas encore réussi à comprendre est la façon dont je peux encore ajouter le support IDropTarget à mon application .NET WPF, donc des informations à ce sujet seraient également les bienvenues.

Si quelqu'un a une réponse instantanée, eh bien, ce serait bien, mais j'essaie principalement de trouver le bon chemin à prendre sans perdre plusieurs jours sur les chemins qui sont des impasses. Ce qui semble être beaucoup. :(

Répondre

1

IContextMenu :: QueryContextMenu(). Extensions Shell sont dans le domaine de C++, très désagréable en C#, .NET 4.0 nécessaire. Un exemple de projet qui utilise is here.

+0

Merci pour la réponse, mais c'est Je cherche à mettre mon application WPF dans le menu contextuel du fichier à un endroit spécifique, pour ne pas avoir mes fichiers par shown/accédé/etc depuis mon application WPF. la meilleure alternative pour cela est d'avoir le gestionnaire de menu contextuel 32 bits et 64 bits dll jeté dans le mélange pour montrer l'élément au bon endroit – Stigma

+1

(Note mentale: arrêter de livrer de mauvaises nouvelles). –