When I found out that I couldn't control the expanding/collapsing of the form regions, it made me sad. I decided to look into controlling how much the form pops out. This has made me sadder still. It seems that while I can control the height, the user won't be able to set the height higher than what I set it to. I couldn't find a height property that controls just how far the region is set without changing the actual height of the form. I'm guessing it's somewhere in the this.OutlookFormRegion, but I haven't had any luck. Any direction towards solving this would be very much appreciated. Thanks.
Did you try to use the Form property of the FormRegion class to set up the required properties?
There are a lot of limitations exist with form regions. The Creating Outlook Form Regions section in MSDN describes form regions in depth.
I'd suggest using Advanced Outlook Form Regions instead. They allow to manage the form in the way you need - hide/show, collapse, change the size and layout at runtime and etc.
Another approach is to subclass an Outlook window and inject your own custom form. See Adjacent Windows In Outlook and Creating Adjacent Windows In Outlook sample project.
If your FormRegionType is Adjoining, after changing to your form region's e.g. Height property, call this.OutlookFormRegion.Reflow() to request that Outlook redo form layout. At least that works well for me in Outlook 2013.
Related
My C# standard windows forms app is finished, it has 10 forms. But the new requirement is now to change the "multiple forms" to one dashboard where you click a link on a bar on the side or top and switch between forms in the main area of the dashboard one at a time, pretty much exactly the same way an old HTML frame works with framesets (just imagine my Windows Forms are framesets).
Without going into much detail, each of these forms are pretty involved, multiple threads and so on, and I am looking for a simple trick to display them, as oposed to recoding the entire thing.
I looked at http://www.codeproject.com/Articles/37397/A-Multipanel-Control-in-C
but it's not what I want.
Is there a way to do this?
If you convert the forms into custom controls, it then becomes pretty simple to use the TabControl http://msdn.microsoft.com/en-us/library/system.windows.forms.tabcontrol.aspx to display the custom controls on the surfaces of the Tabs it contains.
By making them custom controls you avoid the mixing of the code for each of them (they remain distinct) but they also become easily added to other surfaces. I do this with a UI with a dozen display tabs.
I would recommend that you either use a tabbed control, or use an MDI Container, or a combination of both. The MDI has some nice behaviors that you'll get for free by implementing it. You could hard code each tab to each form, or have a dropdown that selects each view. If you want to manage the lifecycle of each form, you could implement a singleton pattern on each, or use IOC.
Not entirely sure this is going to solve your problem, but if you have questions or more details, let me know.
I resolved this using MDI as suggested above, works great in .NET Windows Forms 4.0 and 4.5.1.
In the parent form:
Declare a new child form.
myNewChildForm.MdiParent = this;
set child form StartPosition to Manual.
set child form Location to 0,0.
set child form WindowState to Maximized.
set child form Dock to Dockstyle.Fill
That does the trick.
Thank you all.
If I have created a forms app and not specified anything out of the ordinary (just used Visual Studio's designer to drag and drop controls), what behavior should I expect when resizing the window? Does it differ based on what controls I used? Is there detailed documentation of this someplace I can reference?
(I hate asking something so vague and contrived, but I don't have access to Visual Studio and the developers who do aren't being helpful. As far as I know they're using C# and not using any sort of layout panel.)
It sounds to me like you need to know about anchoring and docking the various components, how they hold together, and how they behave when resizing the form. Please see this link for a guide on how to do this effectively, and how some of the various options work.
Controls on a WinForm application do not resize by default. Look at using the Anchor property on controls. For example. If you want a button to widen when you widen a form go to the Anchor property on the button and anchor the left and right sides. This will widen the button as the form widens.
You can think of the anchor as the parts that get "pulled" when a form moves.
See this post:
Auto size the controls in winform
My C# Window Form size is 1364,835.It is shown perfectly in my PC.But while running with my Laptop(small screen size),only part of my form has shown in the visible area.How can able to fit this size issue among all systems.
do i need to add verticall scroll bar to my form?
Please Guide me to get out of this issue...
Saravanan.P
If you have not done much work on the windows application in that case you can think of using WPF, as WPF is more capable to handle this.
Still if you want to use Window application then make sure that your controls layout properly when their size changes. Use the Anchor and Dock properties. You can also use TableLayoutPanel in GrowAndShrink mode, but remember you might face some flickering issues if you use TableLayoutPanel in excess.
You can check MSDN for Auto Scaling here
you can set one property of form
WindowState = Maximized
just try this...
useanchoring, docking and etc.
look at microsoft outlook when you resize the window it changes looking another softwares can help you
I have been working on a project in C#, a portion of it requires multiple instances of a window to open. Is there any easy way to cascade the instances of the form? I'm assuming I'd have to deal with the math required manually. I just cannot wrap my head around it, any comments or suggestions would be greatly appreciated.
If I understand you correctly, you want the forms to appear on screen in a cascade effect:
If so, when using WinForms you can do this by ensuring that the StartPosition property of each form is set to FormStartPosition.WindowsDefaultLocation (which it is by default).
If you are using WPF, you need to set the WindowStartupLocation property to WindowStartupLocation.Manual in a similar manner and not set a specific location for the window.
This leaves Windows to position the form when it displays, which it does by using the cascading effect shown in the picture.
Using .NET 2.0 with WinForms, I'd like to create a custom, multi-columned menu (similiar to the word 2007 look&feel, but without the ribbon).
My approach was creating a control, and using a left/right docked toolstrip, I have constructed a similar look&feel of a menu. However, there are a few shortcomings of this solution, such as
the control can only be placed, and displayed within the form;
if the form is too small, some area of the control won't be displayed;
the control also have to be manually shown/hidden.
Thus, I'm looking for a way to display this control outside of the boundaries of the application. Creating a new form would result in title-bar deactivating on display, so that's also out. Alternatively, any other approach to create a customized menu would be very welcomed.
Edit: I don't want to use any commercial products for this; and since it's about a simple menu customization, it's not related to Microsoft's ribbon "research" in any way.
unless you are in the business of providing .net components, you should be looking to buy it off the shelf. Its a lot of work getting such a control right - There are already vendors providing this kind of UI. e.g. ComponentOne
if you are trying to build this component as a product, you should look at the link below. Apparently Microsoft has a 'royalty-free' license around the Office UI to protect their R&D investments. As of now you need to tell them that you are using something similar to the Office UI. More of that here
The MenuStrip class has a Renderer property. You can assign your own ToolStripRenderer derived class to customize the painting. It's a fair amount of work.