MDI Form

pcliu

New member
Joined
Apr 12, 2005
Messages
2
Programming Experience
1-3
i created 1 mdi parent form as frmMDI and 3 child forms as frmMainChild, frmChild2 and frmChild3. When the frmMDI is loaded, it will call the frmMainChild and set it to maximize. At here, i treat the frmMainChild as the base form of my application. in the frmMainChild, i can call other forms like frmChild2 and so on...

and now, my problems are:

1. how to disable the frmMainChild to be resized, restored??? i jus want to make it maximized only.

2. when i call the other child forms from frmMainChild, i notice that it always maximize the child form. can i make the child form to be in normal window state?

thanks
 

mzim

Well-known member
Joined
Jun 3, 2004
Messages
187
Location
Other side of the rock
Programming Experience
1-3
1. you can set the property of your form formborderstyle=fixedsingle and minimizebox = false

2.when loading your child form set its windowstate=normal.
 

pcliu

New member
Joined
Apr 12, 2005
Messages
2
Programming Experience
1-3
Thanks mzim for your reply.
I tried already, it didn't work. even though i disable the max and min button for my 1st child mdi, which i want to use as the main form, when i the parent mdi is loaded, i will show the main form and make it to max window state. but use stil can restore the main form.

for the second 1, when i set the windowstate = normal when i call the other child form, my main form, which is the 1st child form that i load will automatically change to NORMAL window as well. They all change together, when i max 1 child form, other child form also been maximized.

isit a bug in vb.net or it is so called inheritance??? ****... i really don't want this...
 

jmcilhinney

VB.NET Forum Moderator
Staff member
Joined
Aug 17, 2004
Messages
14,323
Location
Sydney, Australia
Programming Experience
10+
When using MDI, either all children are supposed maximised or none are. This because, unless there is a menu item which keeps a child window list, the maximised form will obscure the normal forms and there will be no way to activate them (except Ctrl+Tab, which most people don't know about). Your's sounds like an unusual situation. I think a window arrangement like that would be best avoided if possible. You could work around the issue but it would be messy.



  • Set the initial WindowState property of the main child to Maximized and the MaximizeBox and MinimizeBox properties to False.
  • Put this code in the Resize event handler of the main child:
VB.NET:
If Not Me.MdiParent Is Nothing AndAlso Me.MdiParent.ActiveMdiChild Is Me Then
	Me.WindowState = FormWindowState.Maximized
End If

  • Set the other children's initial WindowState to Normal and their MaximizeBox property to False.
  • After you Show another child form set its WindowState property to Normal, e.g.:
VB.NET:
childForm.Show()
childForm.WindowState = Normal
You should find that while just the main child is visible the user can minimise or restore it, but it will re-maximise. When you open another child it will initially maximise, but then restore. Also, the minimise and restore buttons will dissappear, along with the close button. Note that your other child windows will be obscured behind the maximised main child when it is active, so make sure you provide a method for activating them. Also, some may dissappear behind the main child when you don't think they should.
 

mbb

Well-known member
Joined
Jun 3, 2009
Messages
52
Programming Experience
10+
Is it such an unusual situation?

I am encountering this same problem with an MDI form. I have some forms that when visible should be maximised. Sometimes I want to show a normal form over the maximised form (e.g. a progress report on a task or a menu selection).

I can achive this by not making a sub-form an MDI child, but as you say its getting messy and IMO defeating the whole point of using the MDI in the first place.

Since I can add my own menu strip to a form and hide and show forms as necessary, right now I'm wondering why I'm bothering with an MDI form at all!
 

Tom

Well-known member
Joined
Aug 23, 2005
Messages
746
Programming Experience
5-10
Can you include some screen shots of your application? It sounds like a bad design and Im curious to see what it looks like to see if I could offer an alternatives that would still accomplish your goals.
 

mbb

Well-known member
Joined
Jun 3, 2009
Messages
52
Programming Experience
10+
Can you include some screen shots of your application? It sounds like a bad design and Im curious to see what it looks like to see if I could offer an alternatives that would still accomplish your goals.
If your going to suggest that I use the progress bar on a status menu, then forget it. It's not what I had in mind.

I'm exploring alternative options now. I have been toying with the idea of using floating panels to show status or a menu (when I say menu read a datagridview configured to behave like a menu).

Of course with this idea, it means I won't have a title bar, but that may be in keeping with the application's ultimate destination as a game. i.e. my Winform client will either be pimped up or replaced entirely.

Another option is to have a single form and programatically configure the relevant controls depending on what 'screen' the application thinks it is in. But again it kind of defeats the object of using forms in an MDI setting because I won't be able to manipulate whole forms from the designer. I'd have to get into a complete presentation engine, which isn't quite what my job is supposed to be on this project.

I think my best way forward is to use non-MDI forms and strictly control when and how the forms are visible. If I understand what I was reading about winforms last night, I can control the area a form can be moved around in - as in the screen - so the form cannot be move out of view. Or if necessary I can lock a form into place.

I have already noticed one common problem which I will have to be careful of - its possible to leave the application behind as a processs without any form showing; obviously leaving an application behind without the user being able to terminate it is not desirable.

Shame, IMO this is a nasty feature of the .NET MDI (was it like this prior to .NET?) which would be nice to disable if necessary. If its my hole to dig, I'd like to be able to dig it!
 

Tom

Well-known member
Joined
Aug 23, 2005
Messages
746
Programming Experience
5-10
No thoughts about a progress bar. I was thinking instead of a main child screen that takes up the entire background of the mdiParent, that you can use panels on the mdiParent and create sort of a VB toolbox or explorer type menu on the left to put your buttons for calling other forms and then have the other forms appear in the panel on the right.

I use a third party control for this from DevExpress that creates a very professional navagation bar on the left and allows docking and hiding with the push pin etc like the toolbox menu in vb. But as I mentioned similar results can still be had with the simple use of panels or if you search around you can find some free code examples of docking panels others have made, although they may be a little buggy.

But I'm unaware of all that your main child screen might be doing besides calling other forms as you mentioned, thats why I asked to see some screenshots.
 
  • Like
Reactions: mbb

mbb

Well-known member
Joined
Jun 3, 2009
Messages
52
Programming Experience
10+
No thoughts about a progress bar. I was thinking instead of a main child screen that takes up the entire background of the mdiParent, that you can use panels on the mdiParent and create sort of a VB toolbox or explorer type menu on the left to put your buttons for calling other forms and then have the other forms appear in the panel on the right.

I use a third party control for this from DevExpress that creates a very professional navagation bar on the left and allows docking and hiding with the push pin etc like the toolbox menu in vb. But as I mentioned similar results can still be had with the simple use of panels or if you search around you can find some free code examples of docking panels others have made, although they may be a little buggy.

But I'm unaware of all that your main child screen might be doing besides calling other forms as you mentioned, thats why I asked to see some screenshots.
Panels would be the way to go, but as I have said I want to avoid having to write a presentation engine.

I'll stick to using non-MDI forms for now and see how it goes.

Also, from what you say, it follows that there may be a custom MDI control out there that behaves as a pre-NET MDI would too. I'll keep an eye out for one!

Thanks.
 

mbb

Well-known member
Joined
Jun 3, 2009
Messages
52
Programming Experience
10+
No thoughts about a progress bar. I was thinking instead of a main child screen that takes up the entire background of the mdiParent, that you can use panels on the mdiParent and create sort of a VB toolbox or explorer type menu on the left to put your buttons for calling other forms and then have the other forms appear in the panel on the right.

I use a third party control for this from DevExpress that creates a very professional navagation bar on the left and allows docking and hiding with the push pin etc like the toolbox menu in vb. But as I mentioned similar results can still be had with the simple use of panels or if you search around you can find some free code examples of docking panels others have made, although they may be a little buggy.

But I'm unaware of all that your main child screen might be doing besides calling other forms as you mentioned, thats why I asked to see some screenshots.
Well, I'm eating my furry hat now!

This was good advice in the end. Using disjointed forms just looks bad so now I am using mulitple panels as 'screens', each with its own controller object that manages appearance, location and binds event handlers onto named controls.

The main winform looks congested, but the underlying code is fairly clean. I guess the way to go would be to wrap up the presentation and control into a single User Defined Control but that's for another day.

But, when the app runs it's looking good ;)
 

Tom

Well-known member
Joined
Aug 23, 2005
Messages
746
Programming Experience
5-10
Glad it worked out for ya... :)
 
Top Bottom