 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / VS Tools for Office / February 2006Please help: VSTO and custom contact forms
Using VSTO, when I use Word or Excel, I can have "code behind" to populate the documents upon load. In Outlook 2003, I need a have custom contact form and populate it with data from other sources. Is this possible in VSTO? Can anyone point me to an example. Thanks, A custom Outlook form? Design it using Outlook's form designer and use the normal property syntax (itm.prop_name, itm.UserProperties("prop_name") to set the item's properties in your VSTO code. You could also have your VSTO code using the NewInspector event to detect a contact opening and display a Windows form instead of an Outlook form, but this would involve a more coding to read data from the Outlook item and write it when your win form closes. Maybe you'd like to provide more details about your specific scenario?  SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > Using VSTO, when I use Word or Excel, I can have "code behind" to populate > the documents upon load. [quoted text clipped - 4 lines] > > Thanks, Sue, Your guidence is much appreciated. When the user clicks on a contact, we want to be able to display all the Outlook Database onformation for the contact (like whats on the the current default form) AS WELL AS extend the "view" to display/edit other associated data with the contact which comes from the company's SQL database. Assume we need to display the 30 or so standard Outlook database items as well as the 10 items from the SQL database. So I was thinking we could: a) Create a custom form, - which would display/edit current Outlook's contact data items - and perhaps we should create a (CCW/.NET managed) ActiveX Control that would be on one of the custom tabs which would display data from the SQL database. OR b) I have never worked with Inspector and that perhaps it might be easier to just create our own custom Winform dialog What is the simplest, easiest to deploy solution? c) Somehow extend the Outlook database to contain more data items and a custom form that would synchronize with the SQL database as well as display and edit all items I'm a little unsure of what to do Solutons a & b would require deployment to individual desktops. Solution c could be centrally deployed if you can publish forms to the Organizational Forms library on Exchange server, but the code behind the form would all be VBScript, which seems like ancient history once you've used VSTO. I would probably go for solution b. What I've found works well is to subscribe to the Inspectors.NewInspector event. That event will give you the Inspector that's opened. You'll also want to subscribe to its Inspector.Active event. When Activate fires, you can get a reference to the item that opened from Inspector.CurrentItem and close the Inspector. (You can't close the Inspector from the NewInspector event.) SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > Sue, > [quoted text clipped - 28 lines] > > I'm a little unsure of what to do I'd also add that if Infopath is an option on your clients, it can be connected to outlook and external data sources, and provides a good metaphore for document management. The next version of IP will also allow for a web deployment so the client would not need the Infopath client (some restrictions apply). I have connected the outlook client to a sql database using VSTO with a WinForm, and now with Infopath/XML. Both have their strenths and weaknesses. I'm currently leaning towards the IP/XML /VSTO because IP forms design is relatively quick compared to WinForms. Just my $.02 /Bob Solutons a & b would require deployment to individual desktops. Solution c could be centrally deployed if you can publish forms to the Organizational Forms library on Exchange server, but the code behind the form would all be VBScript, which seems like ancient history once you've used VSTO. I would probably go for solution b. What I've found works well is to subscribe to the Inspectors.NewInspector event. That event will give you the Inspector that's opened. You'll also want to subscribe to its Inspector.Active event. When Activate fires, you can get a reference to the item that opened from Inspector.CurrentItem and close the Inspector. (You can't close the Inspector from the NewInspector event.) SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > Sue, > [quoted text clipped - 32 lines] > > I'm a little unsure of what to do Bob, IP is a great idea. But it requires clients to purchase MS Office Professional Enterprise Edition whioch is a significant upgrade (price) - clients are somewhat resistant... Cool! InfoPath, especially IP 2007, definitely fulfills the vision of that people once had of Outlook forms -- at least message forms. SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > I'd also add that if Infopath is an option on your clients, it can be > connected to outlook and external data sources, and provides a good [quoted text clipped - 23 lines] > item that opened from Inspector.CurrentItem and close the Inspector. (You > can't close the Inspector from the NewInspector event.) >> Sue, >> [quoted text clipped - 32 lines] >> >> I'm a little unsure of what to do Sue, Thanks for your help. I agree - after VSTO the thought of scripting kills me. I will start with Solution B and go from there. There one drawback to Winform is that they must use the new winform to view all information and they can't see all the information in Outlooks CardView, list, etc... I don't believe I can just create a more sophisticated UserControl - that is something sitting inside the container like the CardView - that it must be a floating window/dialog etc.. (Am I wrong about this?) And do you know of any any programming examples or book (any .NET language) that shows how to display/edit and save Outlook Contact info using VSTO? Why not? You can add fields to individual Outlook items through the UserProperties collection and customize one or more views (View.XML) to show them to the user. The other approach is to use a folder home page (web page) for the folder's display instead of the item list. That's the approach that Microsoft CRM and some other applications integrating with external data sources use. SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > Sue, > [quoted text clipped - 12 lines] > do you know of any any programming examples or book (any .NET language) that > shows how to display/edit and save Outlook Contact info using VSTO? p.s. Neither Outlook.Inspectors nor Outlook.Inspector has an Activate event.. do you mean a function override?. Inspector definitely has an Activate event, but I can't help with C# code. SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > p.s. Neither Outlook.Inspectors nor Outlook.Inspector has an Activate event.. > do you mean a function override?. Sue, In the object explorer, Outlook.Inspector only has an Active() method which collides with the event name. If I cast it the inspector to the interface it derives from Microsoft.Office.Interop.Outlook.InspectorEvents_10_Event, then it may work. I would think this is true with VB too. Not to intuitive, huh. It works fine in VB.NET. As I said, writing C# code is beyond me. SignatureSue Mosher, Outlook MVP Author of Configuring Microsoft Outlook 2003 http://www.turtleflock.com/olconfig/index.htm and Microsoft Outlook Programming - Jumpstart for Administrators, Power Users, and Developers http://www.outlookcode.com/jumpstart.aspx > Sue, > [quoted text clipped - 5 lines] > > I would think this is true with VB too. Not to intuitive, huh. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.