Inconsistent Property Page Width

[Jim]

Hello,

My Outlook Add-In includes a property page. The property page looks
good on most PCs, but I have reports that on some PCs, the controls on
the property page are clipped on the right-hand side.

I located Ken Slovak's post recommending a maximum property page width
of 5800 Twips. I adjusted my property page controls to fit within
this limit, and I can see where they would no longer be clipped on the
offending PCs.

But -- to fit within the 5800 Twips limit, the controls now appear
bunched to the left on the majority of machines which were not
previously producing clipping of my property page controls. And when
I alternate between Outlook built-in tabs on the property page and my
tab, it is obvious that Outlook is able to display controls beyond the
5800 Twips limit, at least on most machines.

What is going on here? Is the property page size dependent on Outlook
version, Windows version, screen resolution, etc?

Is there a recommended way to dynamically adjust the position of the
controls to compensate for differences in the runtime dimension of the
property page? If so, how do I detect at runtime which property page
dimension I am operating under? I would really like the margins of my
controls to match up with the margins for the controls in Outlook's
own property pages.

Thanks.

Jim

 

[Ken Slovak - [MVP - Outlook]]

Actually, my recommendation is that the Height of the UserControl used as
the property page be under 5400 twips, not the width. That seems to be the
maximum height that won't clip the bottom of the tab when shown in Tools,
Options.

The width shown without clipping depends on a number of factors, some of
which you can't really figure out. Certainly the screen resolution has
something to do with it, but the number of property pages also has an effect
and there's no good way to determine how many pages have been added. You can
count how many COM addins are connected but if a user connects another one
from the COM AddIns dialog that changes things. Also, depending on which
version of Outlook and mode for Outlook 2000 and whether or not Exchange is
being used the number of tabs will vary.

What I do is try to keep the width to under 6100 twips, which works on most
setups. In many cases if I need more space than that I use command buttons
to open subsidiary forms from the main property page. The thing to be aware
of using those forms is that you have to handle either saving settings on
the form immediately yourself when the user clicks on an OK button or
preserve the settings in the main code so when the user clicks on OK or
Apply those settings are updated property.

You can dynamically move controls around by reading the height and width of
a form and changing Top and Left for all controls based on that. However,
clipping a property page doesn't change the UserControl's size so you'd
never know it was clipped.

 

[Jim]

Ken,

Thanks for your response. Your point is well taken that the number of
tabs cannot be predicted, and this could reduce the real estate
allowed to the property page. I did not think of that. I will need
to test this condition to see what happens.

Having experimented for a day or so, I agree with you that the
solution to eliminate clipped controls may be to dynamically move the
controls on the form at runtime. This is messy from a maintenance
standpoint, because I lay out the property page controls for the
default case using the visual designer, but must then also empirically
determine alternate positioning for my controls for the cases where
Outlook produces different property page dimensions for my controls.
It's messy, but it works, so it is probably what I will implement and
deploy.

I can reproduce clipping of property page controls on the right hand
side if I use Windows Display Properties to change the Font Size from
Small Fonts to Large Fonts. It appears that Outlook sees this change,
and reduces the property page real estate. Outlook's own property
pages appear to dynamically adjust to compensate for the font change.

Standing on the shoulders of other newsgroup giants, I have learned
that I can detect the Font Size change by comparing
Screen.TwipsPerPixelX to 15. If it is 15, then Small Fonts are in
effect and I simply use the default control location/dimension
properties configured using the visual designer. But if the value is
not 15 (a variety of values are possible depending on Windows
settings), my Add-In code kicks in and dynamically adjusts the
controls.

Display Font Size Screen.TwipsPerPixelX
--------------------- ---------------------
Small, 100% ( 96 dpi) 15
Large, 125% (120 dpi) 12
Other, 150% (144 dpi) 10
Other, 200% (192 dpi) 7

In addition to changing the location/dimension properties for my
controls, I also have to dynamically change the font size for my
controls to 7 to continue to look like Outlook. I have to change this
font size for my controls on the property page, and on forms launched
by command buttons on my property page. Otherwise, there is a
noticable change in font size when navigating to and through my forms
from the Outlook property page.

I have observed that Outlook does not reduce the property page real
estate for all non-default (not = 15) settings. But rather than make
a career out of handling every configuration permuation, I have taken
a practical shortcut and apply the dynamic adjustments for every case
where the value is not 15. This has the effect that for some
configurations where the value is not 15 but Outlook has not reduced
the property page real estate, my controls will appear pulled to the
left when compared to Outlooks own property pages.

Why not just use least common denominator values for all settings, as
configured in the visual designer, to eliminate the messy maintenance?
Because that results in the property page controls being bunched to
the left for the common case where default Small Fonts are being used.
It looks bad when the user switches from an Outlook built-in tab to
our tab, and our controls seem to shift to the left. It makes our
integration noticably less seamless. So it is worth the extra effort
to support one set of coordinates for the default case, and a second
set of coordinates for the Large Font and other cases.

Thanks for your help.

Jim

 

[Ken Slovak - [MVP - Outlook]]

Yes, large fonts versus small fonts is a problem and you seem to have a
handle on it. Nice going.