Continuons notre découverte sur développement d’add-ins pour Microsoft Visual Studio, l’IDE de prédilection pour les développements sur plateforme Microsoft/.NET. Dans la 1ere partie nous avons vu de quoi était constitué un add-in et comment il fonctionnait. Dans cette 2ème partie nous verrons comment créer des fenêtres d’outils dans Visual Studio.
Nous nous étions contenté, dans la partie 1, d’afficher une simple MessageBox lors du clique sur le bouton de notre add-in présent dans le menu Tools (ou Outils) de VS. Nous avons vu que la gestion du clique se faisait dans la méthode Exec (implémentée par l’interface IDTCommandTarget) quand l’argument commandName était égal au nom de notre commande (ex : commandName == « MonAddinDemo.Connect.MonAddinDemo »).
Mais un Add-In lançant une MessageBox n’est pas forcement très utile 
Nous avons plutôt besoin d’afficher notre propre fenêtre embarquant toute la GUI de notre Add-In.
Fenêtre Visual Studio ou simple WinForm ?
Et si à la place de notre MessageBox.Show() je faisais un new MaWinForm().Show() afin d’afficher une WinForm que j’aurais préalablement créée dans mon projet ?
La réponse serait que cela marcherai sans aucun problème, il en résulterait l’affichage notre propre fenêtre dans depuis Visual Studio.
Vous allez me dire « mais pourquoi écrire un article sur l’affichage d’une simple WinForm ? ». La réponse est ci-dessus : un new MaWinForm().Show() permet simplement d’afficher la fenêtre depuis VS. Il ne s’agit en aucun cas d’une fenêtre dans Visual Studio.
En d’autre terme vous ne bénéficiez pas du look&feel VS, vous ne pouvez pas non plus la docker dans l’IDE ou l’afficher en tant que document VS. Pour ce faire, il faut créer la fenêtre par Visual Studio.
D’ailleurs nous ne créerons pas de Winform mais un UserControl qui sera docké dans une fenêtre Visual Studio.
CreateToolWindow ou CreateToolWindow2 ?
La création d’une fenêtre par VS se réalise en appelant la méthode EnvDTE80.Windows2.CreateToolWindows2() ou EnvDTE.Windows.CreateToolWindow().
Avant de détailler son utilisation, nous voyons pourquoi y a t-il deux CreateToolWindow ?
On retrouve en fait deux namespaces presque identiques :
- EnvDTE : une assembly « wrapper » vers le composant COM du Core Automation de Visual Studio (inchangée depuis VS2003).
- EnDTE80 : une extension de EnvDTE apparut depuis VS 2005 (8.0) pour supporter de nouvelles fonctionnalités.
Dans le 1er, EnvDTE, on retrouve la classe Windows contenant la méthode CreateToolWindow.
Dans la 2ème, EnvDTE80, on retrouve la classe Windows2 contenant la méthode CreateToolWindow2. (note: on retrouve aussi CreateToolWindow dans Windows2).
Comme vous l’aurait comprit, CreateToolWindow est un peu obsolète par rapport à CreateToolWindow2. Dans des soucis de versionning, beaucoup de classes ou d’interfaces ont le suffixe « 2″ dans le namespace EnvDTE80 pour pouvoir les différencier avec ceux d’EnvDTE.
Voyons leurs signatures :
1
2
3
4
5
6
7
| Window CreateToolWindow (
AddIn AddInInst,
string ProgID,
string Caption,
string GuidPosition,
out Object DocObj
) |
1
2
3
4
5
6
7
8
| Window CreateToolWindow2 (
AddIn Addin,
string Assembly,
string Class,
string Caption,
string GuidPosition,
out Object ControlObject
) |
Hormis le fait que les noms des paramètres sont un peu différents, nous remarquerons surtout l’apparition d’un nouveau paramètre de type string nommé Assembly.
Analysons les différents arguments que nous trouvons dans la méthode CreateToolWindow2 :
- Addin (ex-AddInInst): l’instance de l’addin passée dans la méthode OnConnection (variable _AddInInst dans notre Connect).
- Assembly : répertoire de notre assembly
- Class (ex-ProgID) : nom complet du UserControl à afficher dans la fenêtre VS.
- Caption : titre de la fenêtre
- GuidPosition : un GUID permettant d’ identifier la fenêtre.
- ControlObject (ex-DocObj) : référence vers l’instance de votre usercontrol.
Dans les deux cas, ces méthodes retournent un objet Window représentant la fenêtre VS crée.
La principale différence entre les deux méthodes est qu’ anciennement nous affichons un ActiveX dans les fenêtres VS. Depuis VS2005 (et l’arrivé du namespace EnvDTE80) nous avons la possibilité de passer directement un UserControl .NET (d’où l’ajout de l’argument Assembly).
Vous pouvez encore utiliser la méthode CreateToolWindow mais il faudra marquer votre UC ComVisible ou enregistrer l’assembly pour l’interop. COM (dans les propriétés du projet). Développeurs .NET comme nous sommes, en 2009, je pense que nous pouvons oublier les anciennes versions de Visual Studio antérieures à 2005, le CreateToolWindow et les ActiveX au profit d’une méthode plus récente et plus sûre 
Attention, notez aussi qu’il faut absolument que votre UC soit dans la même assembly que votre Add-In (classe Connect). Sinon lors de l’appel de la méthode CreateToolWindow2, la référence vers votre UC (ControlObject) restera à null.
Cas concret : créer des fenêtres d’outils VS
Pour détailler cela, reprenons notre projet « MonAddinDemo » vu en partie 1, et ajoutons un UserControl nommé MaFenetre.
Pour l’exemple nous allons, pour faire très simple, créer un mini browser Web. Dans votre UserControl déposez un WebBrowser docké dans l’UC. Plaçons ensuite une méthode publique NavigateTo pour définir l’adresse du WebBrowser :
1
2
3
4
| public void NavigateTo(string url)
{
webBrowser1.Navigate(url);
} |
Notre UC est prêt ! Voyons comment le lancer dans une fenêtre VS.
Pour cela reprenons notre classe Connect et dans la méthode Exec, ajoutons pour le clique de notre bouton le code ci-dessus :
1
2
3
4
5
6
7
8
9
10
| object monBrowser = null;
var vsWindows = _applicationObject.Windows as Windows2;
// Creation de la fenetre VS de type "MaFenetre"
var maWindow = vsWindows.CreateToolWindow2(_addInInstance, Assembly.GetExecutingAssembly().Location,
typeof(MaFenetre).FullName, "Ma 1er fenetre VS", "{EC7011CF-A49F-4f06-9C2D-7FF32511DE7F}", ref monBrowser);
// La ref. vers notre UC "MaFenetre" est dans la variable monBrowser !
// On le recupere pour appeler la méthode NavigateTo de ntore UC
(monBrowser as MaFenetre).NavigateTo("http://sebastien.warin.fr");
// Affichage de la fenetre VS
maWindow.Visible = true; |
Le résultat devient alors « VS like »
Étant donné que nous avons désormais une fenêtre VS, nous avons la possibilité de la docker dans un endroit de notre IDE :
Et même la possibilité de la définir en tant que Document VS :
Nous pouvons aussi, avant d’afficher notre fenêtre (Visible = true) définir des propriétés à notre fenêtre comme par exemple :
- Linkable (booléen) : permet de définir si la fenêtre peut être dockée dans l’IDE comme vu ci-dessus.
- IsFloating (booléen) : permet de définir si la fenêtre peut être « volante ».
Par exemple, pour créer la fenêtre sous forme d’un document VS comme le montre la dernière capture, nous écrirons :
1
2
3
4
| // Affichage de la fenetre VS
maWindow.IsFloating = false;
maWindow.Linkable = false;
maWindow.Visible = true; |
GuidPosition dynamique : attention au Guid.ToString()
Le GUID que l’on passe à la méthode CreateToolWindow2 permet d’identifier de manière unique la fenêtre. Visual Studio se sert de cela pour mémoriser l’état et la position de la fenêtre.
Remarquez que si vous cliquez une deuxième fois sur votre add-in dans le menu Tools, aucune nouvelle fenêtre n’est créée. En fait la méthode CreateToolWindow2 vous renverra la même référence que lors du 1er appel. Cela est normal étant donné que nous avons mis en dur le GUID pour l’argument GuidPosition.
Dans certain cas nous souhaitons créer plusieurs fenêtres du même type. Par exemple nous pouvons imaginer d’avoir la possibilité de créer plusieurs fenêtres pour plusieurs sites web. Dans ce cas là il nous faut générer un GUID dynamiquement !
Nous allons donc penser à faire un :
1
| Guid.NewGuid().ToString() |
au niveau de l’argument GuidPosition.
Mais à l’execution nous aurons une erreur de type :
1
| [System.Runtime.InteropServices.COMException] = {"Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))"} |
En effet VS attent un GUID au format {<guid>} or un ToString() sur un Guid n’inclut pas les { } !
Pour cela nous avons deux solutions :
- Faire de manière « peu propre », en concaténant :
-
1
| "{" + Guid.NewGuid().ToString() + "}" |
- Modifier le format du Guid (cf. MSDN) :
-
1
| Guid.NewGuid().ToString("B") |
Du fait si l’on remplace notre appel à CreateToolWindow2 par :
1
2
3
| // Creation de la fenetre VS de type "MaFenetre"
var maWindow = vsWindows.CreateToolWindow2(_addInInstance, Assembly.GetExecutingAssembly().Location,
typeof(MaFenetre).FullName, "Ma 1er fenetre VS", Guid.NewGuid().ToString("B"), ref monBrowser); |
… dès que l’on clique plusieurs fois sur notre add-in, plusieurs fenêtres seront créées :
Aller un peu plus loin dans la gestion de la fenêtre
La création des fenêtres dans la méthode Exec n’est pas « très propre ». Il est préférable de les créées dans la méthode OnConnection quand le connectMode est à Startup ou AfterStartup.
Dans notre dernière exemple nous allons permettre de créer une fenêtre volante (toujours de notre UC ‘MaFenetre’ contenant le WebBrowser vers mon site !).
Ajoutons tout d’abord une variable privée à notre classe Connect :
1
| private Window _maWindow; |
Dans notre méthode OnConnection nous avons actuellement le code permettant d’ajouter notre addin au menu Tools (comme vu en partie 1) lorsque le connectMode est à UISetup.
En dessus de cela ajoutons la création de notre fenêtre lorsque nous sommes à Sartup ou AfterStartup :
1
2
3
4
5
6
7
8
9
10
11
12
13
| if (connectMode == ext_ConnectMode.ext_cm_AfterStartup || connectMode == ext_ConnectMode.ext_cm_Startup)
{
object monBrowser = null;
var vsWindows = _applicationObject.Windows as Windows2;
// Creation de la fenetre VS de type "MaFenetre"
_maWindow = vsWindows.CreateToolWindow2(_addInInstance, Assembly.GetExecutingAssembly().Location,
typeof(MaFenetre).FullName, "Ma 1er fenetre VS", Guid.NewGuid().ToString("B"), ref monBrowser);
// La ref. vers notre UC "MaFenetre" est dans la variable monBrowser !
// On le recupere pour appeler la méthode NavigateTo de notre UC
(monBrowser as MaFenetre).NavigateTo("http://sebastien.warin.fr");
// Affichage de la fenetre VS
_maWindow.Visible = true;
} |
Dans notre méthode Exec maintenant, nous allons simplement nous contenter d’afficher _maWindow si celle ci n’est pas Visible. Voici le code complet de cette méthode :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| public void Exec(string commandName, vsCommandExecOption executeOption, ref object varIn, ref object varOut, ref bool handled)
{
handled = false;
if (executeOption == vsCommandExecOption.vsCommandExecOptionDoDefault)
{
if (commandName == "MonAddinDemo.Connect.MonAddinDemo")
{
// Afficher seulement si elle n'est pas déjà visible
if (_maWindow != null && _maWindow.Visible == false)
_maWindow.Visible = true;
handled = true;
return;
}
}
} |
Pour terminer nous allons compléter la méthode QueryStatus, qui je le rappelle, définit l’état de notre bouton dans le menu Tools. Nous allons en effet griser le bouton si la fenêtre est déjà lancée. Voici le code complet de notre méthode QueryStatus :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| public void QueryStatus(string commandName, vsCommandStatusTextWanted neededText, ref vsCommandStatus status, ref object commandText)
{
if (neededText == vsCommandStatusTextWanted.vsCommandStatusTextWantedNone)
{
if (commandName == "MonAddinDemo.Connect.MonAddinDemo")
{
if (_maWindow.Visible)
status = (vsCommandStatus)vsCommandStatus.vsCommandStatusSupported;
else
status = (vsCommandStatus)vsCommandStatus.vsCommandStatusSupported | vsCommandStatus.vsCommandStatusEnabled;
return;
}
}
} |
Observez le résultat une fois la fenêtre affichée :
Conclusion
Vous voilà maintenant capable de créer vos fenêtres dans Visual Studio, de les disposer dans l’IDE de manière volantes, dockées ou comme de simples documents ouverts dans Visual Studio. Dans chacune de ces fenêtres se trouve un UserControl .NET qui contiendra l’interface graphique de votre add-in. En passant l’objet DTE à votre UC, vous avez tout à votre disposition pour interagir avec l’IDE depuis celui-ci.
Dans une troisième partie nous illustrerons quelques interactions possibles avec l’IDE comme par les Window Panes, la Status Bar ou encore la Properties Window.
La plupart des développeurs sur plateforme Microsoft/.NET ont bien l’habitude d’ouvrir leur Visual Studio pour le développement de leurs applications. Lancé en 1997, la 1ère version de Visual Studio (ou VS) nommé tout naturellement Visual Studio 97, a voulu réunir dans un seul et même IDE plusieurs langages qui étaient à l’époque le VB 5.0, VC++, InterDev, VJ++ et FoxPro. Depuis 2002 et l’arrivée de la plateforme .NET, Visual Studio est devenu l’IDE de référence permettant le développement d’application WinForm, ASP.NET (WebForm), Mobile, WPF, Services Web/WCF, workflow, etc… supportant plusieurs langages comme VB.NET, C#, VC++.net et bien d’ autre encore sous forme d’extension.
La grande qualité de Visual Studio est sa capacité à être étendue pour l’enrichir de nouvelles fonctionnalités (Add-in), de nouveaux langages, designers (DSL), etc.. Dans la version 2008 il est aussi possible de se servir du Visual Studio Shell permettant l’utilisation du socle Visual Studio pour développer un IDE spécifique basé sur VS.
Nom: Sébastien Warin
