DockWindow isnt working with my form as expected

Okay I have discovered that its the border style feature... I would request that in your documentation where the section points out form in a WindowDocument for tabbed MDI... to actually put an example of a form actually being done here. Your example uses the ControlWindow which isnt complete and your sample doesnt actually use forms at all. In fact all the windows in your sample are just "custom controls" for the most part.

I would be a little curious why you went the route of DocumentWindow when other lesser docking controls out there have a more complete tabbed mdi control. I mean, dont get me wrong I love your docking capabilities in UIStudio but the tabbed MDI window is awkward. I should say MdiParent = this; and your tabbed component should recognize to tab that window. All the information to display it is within the form control... atleast it should be.

[Modified at 11/09/2005 02:42 PM]

Our upcoming maintenance release does allow you to have designable DocumentWindows and ToolWindows, just like UserControls. That should help.

I have added the border style setting to the help topic as you requested.

We don't use Forms as child controls in our sample because we don't particularly like that design. We prefer that people use UserControls and put those on the controls instead. Or with the upcoming maintenance release, design classes that inherit DocumentWindow or ToolWindow directly.

In order to support a number of advanced features we provide in UIStudio that most other packages do not, we do not hook up to existing MDI forms for document window handling. You have to consider advanced features such as properties specifically on DocumentWindow such as Filename, FileType, Modified, etc. which are used throughout the docking UI (on tabs, next window nav, etc.). Also the tool windows have to behave as document windows when they enter the MDI area. And both have to be able to switch between standard MDI and tabbed MDI on the fly, which is a great feature in itself. VS.NET doesn't even support that. There are other things but I'll stop there. :)

And if you would like to directly use plain old MDI forms that you develop, just set our BarManager.DocumentMdiStyle to None. Then you can do it that way.

Hmm... If you prefer the method of using a custom user control instead of a form then why are you calling it a tabbed MDI Control? My issue here is that I was looking for a tabbed MDI display for my MDI parent form to display my MDI child forms. What your offering however doesn't seem to work effectively for what it is named and advertised. This concept is highly inneffecient for me the developer, because I cannot build around my forms controls. I no longer have simple mergeing of menus and toolbars without manually doing them with code. I have to build a wrapper so that I can manually transfer a forms icon, title, and various other signatures to your document window. What feature in your tabbed mdi component is worth doing all this for? Its not about wanting to use a standard mdi display... I want what you were advertising. A tabbed MDI display for my forms. Unfortunately once I implement tabbed display my parent mdi form loses its ability to be an mdi form. This seems a bit odd don't you think?

Its really quite sad because I like your other features of UIstudio. The docking system, once again, is great tool and I think you outfitted the controls and develop needs effectively. Its the easiest docking manager I have tried to date...

Trust me, I don't like that behavior either but unfortunately Microsoft programmed things so that only MDI child Forms in the MDI area of a parent Form cause MDI menu merging. So we're stuck here with how the .NET framework is built.

And again, this is something we want to make work correctly when using our future bar controls since it's something that has bugged us about the .NET framework for a while. With our own bar controls we won't be limited to how Microsoft designed things, which will be nice.

Also I don't believe that converting DocumentWindow to a Form would solve anything. The reason is that in tabbed MDI mode, there is no MDI client area which is what the .NET framework looks in for menus to merge. Therefore you end up with the same situation.

I will refrain from dragging this out any farther... If you get a chance try using Syncfusion's tabbed mdi component. It accepts forms, and so does a few other UI suites out there. Claiming that microsoft is limiting your design is ludicrous. I mean you can improve the menustrip that microsoft provides if you feel it necessary (I for one wouldnt mind on occasion to use a menu strip that utilizes imagelists) but I can't see for the life of me how you would think this is the answer to your problem. All these different UISuites offer extensibility but every one I have tested thus far offers extensibility with flexibility to the existing framework. If your components can't work independantly from each other then your doing something wrong.

Hi Corey,

I agree with you that this is a big issue and we always want to make our products the best that they can be and provide features that other companies don't. We are committed to making the best product possible and pleasing our customers. Therefore, I have started looking into this in-depth for you.

I believe that I didn't explain our history on this issue properly so let me start over. First you are looking at the .NET 2.0 world, but when we first looked into this, it was back in the .NET 1.0 world and that's what most of my comments were referring to. Up until today, I hadn't looked into how the 2.0 framework handles MDI merging. So I spent a lot of time today on this issue to make sure all my information is up to date. I created a number of tests, looked at the .NET framework source code via Reflector, and Googled some things. Here's what I found (I'll start off with the old style of menus)...

MDI Merging Using MainMenu Class (this is the "old" style of main menu)

What I had stated in previous messages is correct. .NET will only merge menus if you have a parent Form with IsMdiContainer=true, a child Form on it with the MdiParent set to the parent Form, and both Forms have MainMenu classes.

You had suggested making DocumentWindow a Form instead so that tabbed MDI picks up menus. I tried this in a test app, and it didn't work. So I looked at the .NET source code and verified that indeed, it will only automatically merge menus if the parent Form has a child Form accessible via its ActiveMdiChild property. But unfortunately to fill that property, you need to use standard MDI. Since our tabbed MDI doesn't use a parent Form with IsMdiContainer=true, this can never work.

You mentioned that a competitor has this working (not sure if you mean old style menus or the new 2.0 MenuStrip controls). If that is the case for the old style menus, then they might still be using IsMdiContainer=true and managing to assign the ActiveMdiChild somehow through Windows messages since it isn't accessible via .NET code without using standard MDI behavior. I'll try and check out their implementation to see what they are doing.

You can merge menus programmatically with Menu.MergeMenu, however there is no programmatic way to "un-merge" them. I verified this with Google searches. So unfortunately that leaves out the option of us programmtically merging menus when using tabbed MDI.

MDI Merging Using .NET 2.0 MenuStrip Class

After doing a number of tests, using these controls yield the same results as above when it comes to a tabbed MDI implementation where IsMdiContainer=false. MenuStrips only automatically merge menus if the parent Form is assigned a child MDI Form, which would be accessible via ActiveMdiChild. So again we have the same issue.

However, here's the good part! Microsoft exposed the code to programmatically merge and un-merge MenuStrips via the ToolStripManager class. This means that once we compile UIStudio in .NET 2.0, we should be able to get MenuStrip merging automated for tabbed MDI.

The other good news is that I believe with the addition of a new event to DockManager, you'd be able to get it all working now until we get our .NET 2.0 compilation out. We're going to do some tests to see if our idea works. Then if so I can send you the code or post it on what you need to do. Basically what I'd post is what we will make internal in our .NET 2.0 compilation.

So I hope we can move forward together on this. Like I said, we want to keep you pleased and now that I've looked at the MDI features in the .NET 2.0 framework, it looks like we can come up with a solution.

Great news... we added a new DockManager.SelectedDocumentChanged event that fires whenever the selected window in the MDI area is changed, in either tabbed or standard MDI modes.

We also made a .NET 2.0 test project and wrote a few lines of code to fully support merging of MenuStrip controls when in tabbed MDI mode!

In the upcoming maintenance release, we will include a help topic that shows the code needed to achieve this (it's pretty small). Once we have a .NET 2.0 built version of UIStudio and can reference MenuStrip, we will move this code internally so that you won't need to implement any client code to support it.

Look for the maintenance release in the next few days. We're glad we can finally support this feature.

Hey thats great news. I look forward to using the next release. I will hold off implementing anything into the project until I check this new code out. I appreciate you taking the time to look into and do something about my post.