Recently, a developer posted a question to the VSTO forum asking us how to set the width of a drop down control by using the Ribbon Designer (http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/8965ae5a-9c02-4aec-9178-675650b7044e/).
As this person experienced, if you do not set the width of the control, the text that appears in a drop down, combo box, or edit box will truncate. For example, the string “I love Visual Studio Tools for Office!” is truncated in the following drop down:
So how do you fix this? The magic lies in the SizeString property. However, the use of this property is not so obvious. Instead of setting this property to a number such as 20 for 20 characters of space, you must type an actual character for each character’s worth of space you want to allocate for the text width.
For example, to make enough space for the string “I love Visual Studio Tools for Office!”, set the SizeString property of the drop down to “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” or “jlkjlkjlkjlkjdlslaledfoplklksjjklsfdf” etc.
You can also decrease the size of the text area to show fewer characters than appear by default. For example, just set SizeString to “xx” if you want only two characters to appear.
Norm E.
Our very own Mary Lee has got a new video up on the Dev Center on programming smart tags in with custom recognizers in Word using Visual Studio 2008 Service Pack 1. This is a video version of the How To topic in the MSDN library.
Watch or download the video here.
Thanks Mary!
Enjoy,-Beth Massi, Visual Studio Community
You may want to develop Microsoft Office 2003 solutions with Visual Studio Tools for Office (VSTO) in Visual Studio 2008 SP1 for several reasons.
Once you're done with development, you'll want to deploy your Microsoft Office 2003 solutions to your end users. This process involves the following steps:
Due to customer demand, I've created five deployment samples that demonstrate these steps. Step 1 is demonstrated in two ways: you can select your prerequisites through the Prerequisites Dialog Box to be installed with the Setup.exe bootstrapper; alternatively, you can configure launch conditions in the Setup project to only install the customization if the prerequisites already exist.
Prerequisites Dialog Box:
Launch Conditions editor:
You can use the Setup project to complete step 2 by copying the customization assembly and for document-level projects, the document or workbook, to the designated installation location. This is done by adding the project output with the File System Editor. The default installation location in these Setup projects is %PROGRAMFILES%\MyCompany\<Name of Setup Project>.
File System Editor:
Full trust is granted by using the SetSecurity project for step 3. This code uses a custom action in the Setup project to create a code access security policy that creates a solution code group for your Office solution, and an assembly code group for the customization assembly.
Custom Actions Editor:
Step 4 only applies to application-level add-ins: when you use the Excel 2003 add-in or Word 2003 add-in project templates, there is a Setup project automatically added to your Office solution that already creates the registry keys documented in Registry Entries for Application-Level Add-Ins.
Registry Editor:
The process of preparing the development computer for deployment and configuring the Setup project is written out step-by-step in the following two whitepapers:
Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer (Part 1 of 2)
Deploying Visual Studio 2005 Tools for the Office System SE Solutions Using Windows Installer: Walkthroughs (Part 2 of 2)
Now, it's time to experiment on your own. Download the sample code and the completed installers from the MSDN Code Gallery: http://code.msdn.microsoft.com/VSTO2005SEMSI
Happy deployment!
Mary Lee, Programming Writer.
The other day I was asked about the automatic Updates feature of VSTO 3.0 deployment. In this scenario, he used the Publish Wizard in VS 2008 to create a Word document solution and the install manifest. Then a bunch of people used the Word document, and kicked off the installer which then copied things to their ClickOnce cache. Everything worked fine. Then he needed to make changes to the code, recompile, and somehow get the solution to all of his customers. Instead of using the Publish Wizard to create the update in the same server, he chose to use a different server path. The customers were unable to install the updates. He tried editing the custom properties of the document to change the install path to the new server, but it still didn’t work. Then he tried testing with a new, clean computer, and on that computer he was able to install from the new path and use the new Word document. He asked us why were the “old” users unable to get the update?
This question shows up on the Forum occasionally. “Why can I not change the update location of VSTO v3 Add-in or Document once it is installed?” (Or) “Why does VSTO continue to check in the old location even after I change location property on client machines that installed the old version?”
The Path to the deployment manifest is used as part of the Identity for an Add-in. During the First installation of an Add-in or Document, the Full Path is set and stored by the VSTO Runtime for that client machine. Once you have installed an Add-in changing the path in the registration will cause the Add-in to throw an Error. Once you have installed a customized Document, the code-behind will only check the original location and changes to the path stored in the document will be ignored (this is to allow copying a local version of a customized document that you installed from a remote location). In order to change the location that an Add-in or Document checks for updates, you must First uninstall the “old” version on the installed clients and then install from the new location.
Now, if you want to delve deeper, then keep reading this paragraph, or skip to the next one. The low-level explanation is that ClickOnce uses the solution path as part of its identity when storing solutions into the ClickOnce cache. You will get similar behavior in a CO-deployed Windows Application as well _unless_ you use the deploymentProviderURL (DPURL). Setting the DPURL can allow WinForms applications to change where updates are pulled from so that Server A (from which a solution was original installed) can be decommissioned and updates can be retrieved from Server B. VSTO does not support DPURL. Why not, you ask? At the time we were considering it during the development of VS 2008, the amount of development work-months required was more than the time we had remaining (DPURL has implications on migration of data from old solution to new solution, for instance). After much discussion, we decided to have the ClickOnce team throw an exception of a DPURL is set for VSTO solutions. At the start of development for VS 2010, we considered this feature again, but again this feature did not make our list of highest priority deployment features. We are implementing a lot of new deployment features for VS 2010.
In conclusion, the solution Path is used as part of the identity. You can’t change the update path after you've installed an Office solution. In a Windows solution, you can change the update path using DPURL. VSTO doesn’t support DPURL because we couldn’t fit that feature in the development schedule. The workaround is to uninstall the solution from the user’s computer when it is stuck pointing to an old path that you can’t update anymore and then reinstall with a new Install Path set in the Publish wizard. We recommend that you set your Install Path to a URL that you predict can stay the same for as long as your users will need updates.
This explanation applies to Word document and template solutions, and to Excel spreadsheet and template solutions.
I hope this blog entry is helpful! Please leave comments to this article if you have feedback.
-Kris Makey, Jeff Young, Christin Boyd, Mary Lee and Saurabh Bhatia contributed to this blog post
The Visual Basic team posted a walkthrough today on some of the new language features in Visual Basic and C# to help with Office programmability in Visual Studio 2010. Specific features include adding optional parameters to C# 4.0 (VB already has this) and removing the dependency on the Primary Interop Assemblies (PIAs).
You can download the CTP and see it in action for yourself and give feedback here.