Problem with controls on an MDI Form

[IliaPreston]

I have a project with an MDI form
The MDI form has a menu on the top.
When the user selects a menu item, a child form opens.

There are many menu items and therefore many child forms.

Now, I need to place a few controls on the MDI form for example a few command buttons and one or two checkboxes.
But, the MDI form does not accept these controls.

I tried to put a Picturebox on the MDI form and put those commandbuttons and checkboxes on the Picturebox.
But this resulted in wasting the part of the screen covered by the Picturebox !!!!!!

The Picturebox sticks to the top of the MDIForm and takes one third of the height of the MDI Form.
That one third of the surface of the MDI form is now out of bounds for child forms.
When the user clicks on a menu item to open a child form, that child form, now opens BELOW the picturebox !!!!!!
And when I use my mouse to drag the child form, the child form can be dragged further down, but cannot be dragged upwards to cover the picturebox.

Even something like this in the child form:

Private Sub Form_Load()
   Me.Top = 0
   ......
End Sub

Doesn't make any difference.

The area covered by the Picturebox is a dead zone !!!!!!

How can I put some controls on an MDI form (whether directly on the MDI Form, or on a picturebox or any other container) so that that area would not be blocked for other forms.

Please help.
Thanks.

[OptionBase1]

The fun of MDI forms.

If this UI content is something that only needs to be interacted with and visible to the user occasionally, then one option is to do what you are doing now with a Picturebox but have it hidden most of the time. Have a top level menu item with no subitems that will make the picturebox visible when clicked, then have a button inside the picturebox that will hide it as well when done.

If this is something that needs to be available and visible on screen all the time, then I don't have a good suggestion other than trying to make it as small as possible from a height standpoint.

Edit: Since your details of what functionality you need on the MDI main form is a bit vague (buttons and checkboxes), not sure if this is feasible or not, but you could have two pictureboxes - one "shorter" picturebox that is visible the majority of the time and simply gives a summary of the status of these checkboxes you refer to along with an "expand" button. When the "expand" button is clicked, the other "taller" picturebox is displayed instead which contains the full button/checkbox UI that you have now and allows the user to take necessary actions with those buttons/checkboxes.

[Episcopal]

Why do you put the picturebox on the left side so it can consume less space.

[LaVolpe]

Similar to what OptionBase1 suggested: Maybe create a menu on the MDI form where the menu items perform the execution of whatever those controls would do

Or are you talking something like a floating toolbar?

In any case, if the MDI children would be able to overlap the picturebox, then it sounds like the reverse could be an issue. Users need to move the children around, or minimize them, to access the picturebox.

I agree with OptionBase1 that more details could be helpful

[dilettante]

Sounds like your PictureBox should be yet another MDI Child Form instead. Perhaps you want something like an optionally-dockable tool window instead of permanently docking that group of controls, which of course takes away from the MDI Workspace.

Of course you might also permanently dock to the top, bottom, left, or right edge but use a splitter-bar to allow it to be sized or even collapsed-to/expanded-from the edge.

[DataMiser]

If all you need are a few buttons and a couple of toggles then another option may be to use a toolbar. They do not need much space and of course can be hidden when desired.

[IliaPreston]

Thanks for all the help and advice.

Actually I came up with something like this:

Private Function NonMinimizedFormsCnt() As Long
   
   Dim Frm      As Form
   Dim Cnt        As Long
   
   Cnt = 0
   
   'Counting 
   For Each Frm In Forms
      If Frm.Name = Me.Name Then
      ElseIf Frm.WindowState <> vbMinimized Then
         Cnt = Cnt + 1
      End If
   Next Frm
   
   'Result
   NonMinimizedFormsCnt = Cnt
   
End Function

Private Sub MDIForm_Activate()
   If NonMinimizedFormsCnt() = 0 Then
      picMain.Visible = True
   End If
End Sub

Then in the Form_Load of all forms, I have something like this:

Private Sub Form_Load()
   MDIFrmMain.picMain.Visible = False
   ......
End Sub

With this code in place, in the beginning when the application starts, the picture box shows properly.
Then when I click on a menu item to open a form, that form also opens properly (the picture box is made invisible and the form shows up on the very top of the MDI form as expected)

However, when I close the form, and the MDI form comes to the front, the picturebox is NOT set to visible again because (when I set a breakpoint) the MDIForm_Activate method of the MDI form is NOT triggered!!!

I don't understand why.

There is the exact same problem with minimizing the form.
When I minimize the form, the form goes to the bottom edge of the MDI form.
In that case, I expect that the MDIForm_Activate be triggered, but it is not !!!

I am sure there should be a way to get this to work by some tweaking.
Can you please help me fix this?

Thanks.
Ilia

[LaVolpe]

The Activate event of top-level forms, I believe, only applies when moving between other top-level forms in the same project. If you only have one top-level form, you probably are not going to get Activate events. If the child forms get Activate events, they probably only get them among the other child forms.

Edited: I guess you can create a Friend/Public routine in your MDI form and call that from each child form each time they minimize/maximize? You'll know that from the child form's resize event and querying Me.WindowState (not on a VB box; think that is the property name). In that new MDI form routine, you can do whatever tracking you'd like. Just a thought off top of my head.

[IliaPreston]

Everything I do to fix this, it ruins something else.
For example when I minimize all forms and the MDIForm appears and the PictureBox is made visible, the icons of those minimized forms disappear from the bottom edge of the MDIForm !!!
I guess those icons are pushed further down below the visible boundary (bottom edge) of the MDIForm.

I am abandoning this effort as it is not really worth it.
I will put those CommandButtons and checkboxes on some child forms.

But, is there a way to at least show a picture (a jpg file) and some text directly on the MDI Form (without a picturebox or any other control)?

Please advise.
Thanks.
Ilia

[LaVolpe]

Everything I do to fix this, it ruins something else.
For example when I minimize all forms and the MDIForm appears and the PictureBox is made visible, the icons of those minimized forms disappear from the bottom edge of the MDIForm !!!
I guess those icons are pushed further down below the visible boundary (bottom edge) of the MDIForm.

Actually that dark space below the picturebox & where the child forms are confined to is another window, called the MDI Client. When you make the picturebox visible, that pushes the entire MDI Client down and when you hide the picturebox, the entire MDI Client is slid up to take its position.

But, is there a way to at least show a picture (a jpg file) and some text directly on the MDI Form (without a picturebox or any other control)?

Yes, you should be able to find some threads/examples of adding a picture to a MDI Client. I think it will require subclassing to custom draw the MDI Client. In your searches, ensure you use "MDI Client".

[dilettante]

The MDIForm class has a Picture property you can assign to.

But if you want to overlay text on an image you'll want to use some "canvas" class that you can load an image into and then draw text on top of that and finally extract a StdPicture from it.

You'll probably want a canvas that can scale to fit your resized MDIForm client area too.

Should be tons of examples in the CodeBank.

[IliaPreston]

The Activate event of top-level forms, I believe, only applies when moving between other top-level forms in the same project. If you only have one top-level form, you probably are not going to get Activate events. ......

Thanks.
Why should a vbp project have more than one MDI form?
I think the VB6 IDE does allow the developer to add more than one MDI form, but I don't understand why.
As far as I understand the MDI form is the parent of all forms in the vbp project, so, more than one MDI form probably doesn't make sense.
Is there any reason why a vbp project may need to have more than one MDI form?

Also, one other question that really bothers me is that:
An MDI form has more capabilities than a normal form. But, why does it also have these restrictions?

For example an MDI Form does not accept the placement of a commandbutton or a textbox on it.
Why?
Is there any real rationale behind this?

Please correct me if I am wrong: I believe Microsoft developers who designed and created VB6 made the mistake of creating MDI forms with these restrictions without any good reason.
The more I think why these restrictions should exist, the less reasons come to my mind.
Is this a bug in VB6?

Also, if you take a look at popular applications out there (developed in other languages such as C++) for example Winrar, etc, when you open their main page (parent of all sub-forms), there are a whole lot of controls on them.
For example on the main page in Winrar, there is even a grid (as well as a whole lot of other things).

I would really appreciate it if someone could shed some light on this issue.
Thanks.
Ilia

[LaVolpe]

Why should a vbp project have more than one MDI form?
I think the VB6 IDE does allow the developer to add more than one MDI form, but I don't understand why.
As far as I understand the MDI form is the parent of all forms in the vbp project, so, more than one MDI form probably doesn't make sense.
Is there any reason why a vbp project may need to have more than one MDI form?

MDI forms are not the only type of top level form. Any form that is not a child form is a top-level form.

Also, one other question that really bothers me is that:
An MDI form has more capabilities than a normal form. But, why does it also have these restrictions?

For example an MDI Form does not accept the placement of a commandbutton or a textbox on it.
Why?
Is there any real rationale behind this?

Technically it does, via a picture box.

Also, if you take a look at popular applications out there (developed in other languages such as C++) for example Winrar, etc, when you open their main page (parent of all sub-forms), there are a whole lot of controls on them.
For example on the main page in Winrar, there is even a grid (as well as a whole lot of other things).

Hard to believe, but I've never used Winrar. In any case, if it is MDI-like, one can do nearly anything they want if they are willing to handle the subclassing needed. There are very few restrictions when subclassing -- just a lot more work.

[dilettante]

Why should a vbp project have more than one MDI form?

Imagine a text editor that can handle both plain and rich text. The latter might have toolbars and menus for things that don't apply to the former.

Or perhaps the same program also supports painting and editing images.

Or a program like Outlook might view/edit emails, but also calendar reminders and appointments, personal notes, etc.

[dilettante]

Also, one other question that really bothers me is that:
An MDI form has more capabilities than a normal form. But, why does it also have these restrictions?

For example an MDI Form does not accept the placement of a commandbutton or a textbox on it.
Why?
Is there any real rationale behind this?

MDIForm can contain nearly any control with an Align property. Those that are containers can have other controls added within them. The most common are PictureBox, Coolbar, Toolbar, and UserControls where Alignable = True.

[Eduardo-]

For example an MDI Form does not accept the placement of a commandbutton or a textbox on it.
Why?
Is there any real rationale behind this?

Hello. The reason is that the MDI parent is intended to contain child forms, thus the area to hold the child forms need to be rectangular, it can't be some other irregular shape.

You can place controls inside it, but only controls that can take the whole width when placed at top/bottom or the whole height when placed at left/right.
They are controls that has Align property.

If you need to place other kind of controls, you can, but inside one that has Align capability, such as a PictureBox.

I think the VB6 IDE does allow the developer to add more than one MDI form, but I don't understand why.

How? AFAIK only one MDI parent is allowed.

[Elroy]

MDI Form does not accept the placement of a commandbutton or a textbox on it.

If we're just trying to get the cat skinned, create a borderless MDIChild form, put your button on it (top-0, left=0), size the form to the size of the button. And then, in the MDI form's load (or activate), position that MDI Child where you want it.

I think the VB6 IDE does allow the developer to add more than one MDI form

Hmmm, my first thought was an in-process ActiveX DLL, but you don't seem to be able to add MDI forms to these projects. However, I then looked at an out-of-process ActiveX EXE, and they do allow MDI forms. So, that's a way to get this done as well. Apparently, the restriction is one MDI parent form per process.

[Eduardo-]

Another option would be to put the controls inside a normal form (borderless) and subclass the MDI parent's WM_MOVE message to place this normal form at the top-left of the MDI client area.

But I don't know exactly what the OP wants to achieve (I didn't read the whole thread).

PS: Or better WM_WINDOWPOSCHANGING for handling the z-order

[IliaPreston]

Thanks for all the help and advice.

Now, let's look at this whole thing from a different perspective:

Instead of using an MDI form as the main form in a project and trying to put controls on it, one can go the other direction:
One can do away with the MDI form, and instead, use an ordinary form (instead of an MDI form) as the main form.
Then, all kinds of controls can be placed on that form at will.
For example, even menu items can be added to an ordinary form.
Then the code under those menu items or command buttons, etc. can load other forms and sub-forms, etc.

So, if that is the case, why should one even think about using an MDI form?
If an ordinary form can do everything that an MDI form can do, then why MDI forms are out there?

The only thing that comes to my mind is that when you use an MDI form, then all the sub-forms (when minimized), minimize into the bottom edge of the MDI form (instead of going to the task bar).
Can that functionality (sub-forms being minimized to the bottom edge of the main form) be somehow achieved when using an ordinary form (instead of an MDI Form)?
How?

And is there any other problem with using an ordinary form instead of an MDI form?
What other features do I lose if I use an ordinary form instead of an MDI form?

Thanks.
Ilia

[LaVolpe]

I think the biggest difference is that MDI is a container. All child forms are contained within that MDI. Minimize the MDI, all child forms come off the screen too. Restore MDI, all child forms are back on the screen. Move a MDI, all child forms move with it. That functionality can be replicated with multiple non-MDI forms, but requires more work.

The choice, in my opinion, is whether to containerize or not to containerize child forms.

[Eduardo-]

I've never used MDI forms in my programs.
Surely it depend very much on the nature of the program, but I think if I had to show multiple documents I'll use the current MS approach of showing them on individual windows or use a tabbed approach.

[Elroy]

I too have never used the MDI approach, and have never really liked it. I don't even use it for the VB6 IDE.

Personally, if I have some main form, and also have some sub-tool-forms associate with it, I just use the OwnerForm option on the form Show method. Using this option causes "child" forms to minimize with the "Owner", and it also causes them to unload when the "Owner" unloads. Furthermore, the "child" forms are always on top of the "Owner", much like in the MDI situation (but not restricted to the bounds of the MDI parent). For me, this is a superior approach.

[IliaPreston]

I think the biggest difference is that MDI is a container. All child forms are contained within that MDI. Minimize the MDI, all child forms come off the screen too. Restore MDI, all child forms are back on the screen. Move a MDI, all child forms move with it. That functionality can be replicated with multiple non-MDI forms, but requires more work.

The choice, in my opinion, is whether to containerize or not to containerize child forms.

Thanks.

That functionality can be replicated with multiple non-MDI forms, but requires more work.

How can that functionality be replicated with non-MDI forms?

Do you mean something like what Elroy suggested in post #22 ?
Or do you mean another way of doing it? How?

Thanks.
Ilia

[DataMiser]

Also, if you take a look at popular applications out there (developed in other languages such as C++) for example Winrar, etc, when you open their main page (parent of all sub-forms), there are a whole lot of controls on them.
For example on the main page in Winrar, there is even a grid (as well as a whole lot of other things).

A whole lot of other things? There is a toolbar, a status bar both of which can go on a MDI parent. And there is a listview that fills the rest of the form.

Not really sure why you think Winrar is a MDI though. All of the secondary windows I have opened in winrar are not children of the main window. Every window I have opened in it could be dragged outside the main window [ a mdi child can not ] and are displayed modally which also is not part of the mdi/child structure.

[dilettante]

I'm not sure what the big deal is.

MDI works great for some things and it is a poor fit for others. You don't have to use it.

As monitors increased in resolution and size, multiple monitor PCs became common, and memory got plentiful most of the reasons for MDI went away. That's probably why Office stopped using MDI and eventually Microsoft deprecated the technology.

[IliaPreston]

A whole lot of other things? There is a toolbar, a status bar both of which can go on a MDI parent. And there is a listview that fills the rest of the form.

Not really sure why you think Winrar is a MDI though. All of the secondary windows I have opened in winrar are not children of the main window. Every window I have opened in it could be dragged outside the main window [ a mdi child can not ] and are displayed modally which also is not part of the mdi/child structure.

You are right.

[IliaPreston]

As monitors increased in resolution and size, multiple monitor PCs became common, and memory got plentiful most of the reasons for MDI went away. That's probably why Office stopped using MDI and eventually Microsoft deprecated the technology.

I thought an MDI form was a matter of design. An application has a better design with an MDI form, while another application has a better design without an MDI form.

But, I don't understand what the necessity for an MDI form may have to do with monitor size and resolution, multiple monitors and abundance of memory.
I would appreciate it if you could clarify this point.

Thanks.
Ilia

[DataMiser]

When you are using more than one monitor the MDI form environment limits your options preventing you from dragging a child form to the other monitor. A non mdi environment will allow you to have forms displayed on more than one monitor so you effectively have more room to work with. Which is best depends on the program and how the users intend to use it.

[IliaPreston]

When you are using more than one monitor the MDI form environment limits your options preventing you from dragging a child form to the other monitor. A non mdi environment will allow you to have forms displayed on more than one monitor so you effectively have more room to work with. Which is best depends on the program and how the users intend to use it.

Thanks.
But, how about the other two reasons:

1- Monitor size and resolution
2- Abundance of memory

[dilettante]

Imagine you have a 640x480 monitor. Imagine this program is maximized and the children are maximized for room to work:

You can Ctrl-Tab to quickly navigate among them, no need to waste screen real estate.

If you need to hunt among all of them you can always restore them, cascade them, or even tile them.