Hi
I have a form which is data driven in terms of position, size etc. I have glass turned off and the style set to RoundedSizable. It looks fantastic with the Office 2007 black style library loaded. I did have to set useAppStyling to false to get the caption area to be black for some reason as it was being coloured incorrectly.
I have a routine which saves the size of the form on formclosing and one that sets it in the constructor. Despite this my form gets progressively smaller on each run. It seems the size we save, cant be used before thr form.show method as it gets the size wrong. We've managed to get this bit working but only by manipulating clientsize instead. I should be able to manipulate the size and it should be accurate.
Further adjustments in size take place before the form show() method is executed. This is because the form is sized and then resized by other controls as they are placed on the form. It seems subsequent resizes don't work. I have noticed that the form keeps an old size when the form is shown.
I guess I need an override position in the code before the shown event but after the ultraformmanager makes its adjustments. I lve the visuals but its not helpful the way it binds itself to the form. It should be much earlier.
Any ideas?
Darren
To shorten this. Everything else is manageable and I can code around it.
The biggest issue I have is that anything which sets the size of the form between form creation and the show() method being executed can't use the difference between form.size and docked panel.size to correctly size the control. The form manager seems to set the size based on its size initially.
Regards
Hello Darren.
In order to render the custom form borders, the UltraFormManager (or UltraToolbarsManager), must perform quite a bit of manipulation to the form itself to prevent the standard form borders from showing while maintaining the original size. This is done by subclassing the form, and manipulating it's window messages.
Here's the basic process to render the custom form borders. The standard form borders are eliminated by removing the non-client area of the form. DockArea controls are docked around the outside of the form to render each individual border side. When using a process of this nature, one of the biggest difficulties is maintaining the correct size of the form at both run-time and design-time. As such, there is quite a bit of manipulate required for the WM_NCCALCSIZE, WM_WINDOWPOSCHANGING, and WM_WINDOWPOSCHANGED window messages, to handle the form's size correction. Unfortunately, we don't control when these messages are received, so we can't guarantee that the Size property of the form is the adjusted size when being accessed in the form's constructor or the Load event handler.
For the most part, the rule of thumb when looking to set the form's size prior to it being shown, is to use the ClientSize property. If you want to narrow it down more, I believe that if the form's Handle has not been created (IsHandleCreated == false), you should use the ClientSize. If it has been created, the Size property may be fine.
I hope these details help explain the exhibited behavior. Let me know if you have any questions.
Chris
Thanks for the reply. Probably the most informative article I've seen on form manager. I did work out that vs is showing me borders of 8 on left, right and bottom and a caption of 32.
It turns out that at the point I'm setting the size, I'm needing an extra 32 width and 80 height to compensate whivh is double. Thanks for the Info. I'll work this into the code.