Hello fellow coders,
I've developed an outlook 2007 addin that makes use of a few form regions and some custom user properties to extend outlook's standard items and I seem to have a problem with my formregions getting 'infected' with properties.
From what i can tell, if you drop a field onto a formregion in design mode, the formregion tries to ensure that property is always available by saving it internally and then injecting it into the userproperties collection of an item when it is created and displayed. The problem is it doubles up on properties that already exist in the item, standard or custom properties.
For eg. I have an employee item (IPM.Contact.Employee) which contains one userproperty 'ParentEntry' which sits in the published Employee form. When opening an employee item programmatically, initially the item has the one expected userproperty. When the line employee.Display() runs, the userproperty count will increase to some number, most recently 13. I assume this is where the form region is stepping in and adding its fields to the item. Looking through the collection, some of the properties are double ups of my 'parententry' userproperty, others are standard contact item properties such as Contacts, FirstName, Companies etc. Looking in the 'AllFields - User fields defined in this item' list is misleading and wont display the doubleups, but set a breakpoint in your code and the userproperty count canbe seen to be higher.
The additional properties automatically added on Display() are generally properties that a) have been added to the form region by dragging from fieldchooser, or b) have recently had their properties changed in design mode eg. textbox width has been increased. Pulling up the properties dialog on a bound control and clicking OK seems to inject the property into the form region, both with userproperties and with standard outlook properties.
Once a formregion has these additional properties in it, they cant get out! Removing the control from the form region doesnt work. Pre b2tr the only way i found to get around this problem was to select all controls in a formregion, copy and paste them to a new form region and save the new form region. It would stay clean and uninfected until i pushed my luck and went changing control properties again. But with b2tr this doesnt seem to work as pasting controls into a new form region means they lose their binding and have to be manually rebound, which means changing the control properties and then the property gets saved with the form region, which is back to square one.
A formregion also seems to pick up any user properties which may be sitting in the published form which is currently housing the formregion designer. Next time the item is loaded/created the default form injects its userproperties, then the form region injects them all again.
Any one else been having similar experiences or know any solutions?
On a related tangent, the properties dialog box of controls in a form region does not always display the correct values, particularly with respect to a controls layout properties. Eg. it may say its going to grow and shrink with the form, but it just stays there ungrowing and unshrinking. b2tr realises this problem, a button was added 'select controls with layout errors' which at least highlights the problem control/s, but a better button would be 'fix controls with layout errors'. The best fix i've found for misbehaving controls is to delete them and readd.
Thanks for any help,
Trevor
| | tdtdtd | | Is there a particular reason why you're using a published custom form to design your form region? I do all mine on new, unpublished forms. | | Sue Mosher - Outlook MVP | Because of the problem with formregions picking up properties, I dont edit form regions in my published form but instead use a new form.
However, its more intuitive to edit your form region in the form that it belongs to, especially when there is a design form button on the form that allows you to step straight into design mode.
| | tdtdtd | Trevor,
I'd be glad to test this one for you. Do you have a sample you can send?
John.
http://blogs.msdn.com/johnrdurant | | John R. Durant - MSFT | The problem can be replicated by;
1) designing a new form and publishing it to a folder eg. ipm.contact.employee to a new employee contact folder.
2) create a new form region and drag one property eg. first name, from field chooser. Save the form region.
3) create the necessary form manifest & reg entry to link the formregion with the employee form, set the default form on the folder to the employee form.
4) Create a new employee item and set a breakpoint somewhere in code eg. beforeFormRegionShow method (see below), to check that the userproperty count on the item is 0. All is well.
5) Open the form region again, rightclick on the added control, choose properties, then click OK. On the surface, nothing changed. Save the form region.
6) Clear the form cache and restart outlook to ensure the new formregion is loaded.
7) Create a new employee item and when you hit the breakpoint again, the userproperty count will now be 1. The userproperty name will be the name of the sole property on the form region eg. first name.
Setting 2 breakpoints in the FormRegionStartup class spans the problem occurence, one in the GetFormRegionStorage method and the other in the BeforeFormRegionShow. Looking at Item object in the first shows a zero userproperty count, looking at formRegion.Inspector.CurrentItem object in the second shows an incremented userproperty count.
Similarly with any other controls on form regions bound to standard or user-properties defined in folder or form, when the properties dialog box is ok'ed the form region saves them to inject into the item userproperties collection on load/display.
I'd be interested to find out whether anyone else can replicate this behaviour. I'm using code from the sample addins - RibbonX and InternetHeaders FormRegion. At first i thought it was a problem with com refs not being released (which was causing other problems) but i still have this problem even after excessive garbage collection and remming out code that might even think about holding a reference to item or inspector.
| | tdtdtd |
|
index > Visual Studio Tools for Office > Outlook 2007 Form Regions and User Properties