Extremely annoying behavior :(

Docking/MDI for Windows Forms Forum

Posted 13 years ago by Kasper
Version: 2.0.0077
Platform: .NET 2.0
Environment: Windows XP (32-bit)
Avatar
Hi,

I'm experiencing some very weird and very annoying behavior from the tool windows of the UI Studio package. I'm using the latest version, of course. I have a pretty normal IDE-looking layout, with about 10-12 tool windows. However, when I start my application, the contents of some of the tool windows will be gone. It's simply completely empty. I figured out that I could get it back by undocking the window - as soon as I do that, the controls of the window will appear, and they will stay even if I dock the window again. Now, if my application loads from a previously saved layout, it works fine, but if it starts from scratch, I get this behavior. After lots of struggling I figured out that the designer, for some reason, set the Visible property of the tool windows to false. If I change them to true, it will sometimes work, but the designer always sets them back to false at some point :(. This is of course a very big problem for me.

Now, I know you will ask me to make a sample application, but I can't reproduce this in a less complicated application - it is however a very big problem! I really hope you can help me, since my application won't be going anywhere with a problem like that. I of course hope that this is a bug you can fix, but a workaround will do as well, since I'm desperate.

Comments (26)

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hmm... something in the VS designer must be thinking that you want to keep those invisible for some reason. Our code does not touch child control visibility.

Of course a small sample application would really help towards us debugging and possibly coming up with a workaround. But if you can't put together one of those, can you describe what types of tool windows this happens on? Like does it happen on tool windows that are hidden or auto-hidden in the designer only, etc.?

What about this for a workaround... in the WindowInitializing event, take the window and do a look through the child controls like:
foreach (Control childControl in e.TabbedMdiWindow.Controls)
   childControl.Visible = true;
Does that help work around the issue?


Actipro Software Support

Posted 13 years ago by Kasper
Avatar
Hi,

Thanks for your reply :)

>But if you can't put together one of those, can you describe what types of tool windows this happens on? Like does it happen on tool windows that are hidden or auto-hidden in the designer only, etc.?

Actually, all my tool windows are docked. I have docked them in 3 different areas: To the left, to the right and in the bottom. Right now, only selected tool windows to the left and to the right have this problem - the ones in the bottom works fine. The windows are all tabbed, and it seems like the one which is selected when the application starts never fails. It also seems that this will mostly happen with windows which I have added recently.

>What about this for a workaround... in the WindowInitializing event, take the window and do a look through the child controls like:

I actually tried that, although not in that event, and it seems to do the trick. I will do it in the event you propose - should I expect any drawbacks from this hack? For instance, will it lead to any problems with windows popping up even though the user has tried to hide them or something like that?


Edit: Okay, I read your code a bit fast there. I simply ran through the Tool windows and set their Visible to true - you loop through the controls of the windows instead. However, I guess that will cause problems if I have controls on the tool windows which I would like to keep hidden. Also, showing the child controls doesn't seem to make a difference, I'm afraid.

[Modified at 01/10/2007 06:59 AM]

[Modified at 01/10/2007 07:02 AM]
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
My guess was that since the non-visible tabpages have a Visible property of false, Visual Studio was assuming the child controls have a Visible of false as well. Maybe you could check that by looking at your InitializeComponent code to see if a child control is set Visible = false. Or is there some other setting on one of your tool windows in InitializeComponent that looks goofy.

This is where a simple sample project would really help. :)


Actipro Software Support

Posted 13 years ago by J Harrington
Avatar
I've just started seeing this problem too. Basically what I have is a simple app with a few ToolWindows docked as tabs. Everything works fine until I drop a custom user control onto one of the tabs. Then when I launch the app, the Visible property of all three tabs gets set to false and the designer goes kablooey (it goes blank and reports the error "The designer loader did not provide a root component but has not indicated why." Closing and reopening the designer fixes this.) The contents of the tabs may or may not show up at runtime. If I manually reset all the tabs to Visible, they get reset back to false every time I launch the app. If I remove the user control and reset all the tabs to Visible, they stay that way and everything is fine. I don't ever touch the visibility of the child controls, just the ToolWindows themselves.

I've got a minimal sample app that demonstrates the problem. I'll be happy to zip it up and send it - any particular email address, or just the general support@actiprosoftware.com?
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Julianne,

Sure send over a sample and we can take a look to see if there's anything we can do.

BTW, the "root component" exception in the designer is something that we reported to Microsoft a long time back on their "connect" site but they replied that it would not be fixed. The exception can easily be reproed by using a control that participates in the .NET licensing model (which ours and most third-party controls do). We made a tiny sample project with a bare-bones licensed control that showed the behavior and included that in our report to them.


Actipro Software Support

Posted 13 years ago by J Harrington
Avatar
Okay, just sent it. Let me know if I can provide any more info. Thanks for looking into this!

Thanks for the info on the root component exception too. Gotta love it when MS says they just plain won't fix it. *rolls eyes*
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
I think I was able to narrow down a workaround for the child control visibility designer issue. Try this for me in your sample to double-check. Go into the InitializeComponent code and look at the tool window code. You will see a Visible = false attribute on a couple of them. Remove those lines. Then run your app and see if all the child controls are visible. If so then that's good news...

What I did to our code here just now is do a new implementation of the Visible property on TabbedMdiWindow that doesn't serialize the Visible property any more. That seems to resolve it from what I am seeing here. This change will go into effect in the next maintenance release.


Actipro Software Support

Posted 13 years ago by J Harrington
Avatar
I've tried removing the Visible=false lines in InitializeComponent, and even tried explicitly adding Visible=true for all the tool windows. It always gets set back to false again, either immediately on launch or the next time I edit something in the designer.

If loop through all the tool windows and set them all to Visible=true in the constructor after the call to InitializeComponent, that seems to be a viable workaround, though things are still wonky in the designer.

I'll look forward to the next release. Thanks again!
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi yes, that's what I meant. If you removed the Visible=false lines without the designer open and immediately ran the app, did it fix it. It sounds like what you did with the constructor is the same thing so that should indicate the code change made for the next release will resolve this. Great!


Actipro Software Support

Posted 13 years ago by Lisa
Avatar
FYI... I have just started experiencing the same problem in our application. We just upgraded from v2.0.74 to v2.0.78 and this is when the problem started. In the previous version, the Visible property of the tool windows was always true. With the current version, the Visible property of every tool window is false. If I explicitly set Visible to true in the constructor after the InitalizeComponent() call, the tool windows and their controls are correctly displayed. It sounds like you've already fixed this problem on your end, so I'll look for the next release.
Posted 13 years ago by Martin Lamothe
Avatar
Same issue here.

This is the type of stuff that can make you lose your hair. I originally thought I introduced a bug or that something happened when I upgraded to VS2005 SP1. Just happy that I found this thread and that I can replicate the symptoms/workarounds mentioned above.

Looking forward to a release to fix this bug.

Keep up the good work guys :)
Posted 13 years ago by Kasper
Avatar
Hehe, I was so sure that I was the only one experiencing this. I probably spend 2 or 3 hours in total, trying to hunt down this bug or at least find a workaround. Oh well, as long as it gets fixed, I'm happy :)

[Modified at 01/25/2007 02:54 PM]
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Wow, active thread! :) Yes the release with this fix should be out in the next several days. There will be a Shared/WinUICore update with it, so releases of all the other products will be made as well.


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
Wow, re-opening a 9 month old bug really kills me, but I am now seeing this behavior once again. I have built a new application, and whatever I do, the Visible property of my tool windows are set to False. I can set them all to true, but as soon as I close the designer tab of my main form in VS and re-open it, they will all be False again :(. If I stay away from saving and loading the layout, the windows WILL be visible at runtime, but it completely messes up if I wish to use the load and save routines. I am using the latest version of UIStudio, and I hope this bug can be fixed again!
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Kasper,

Can you email over a small sample project along with instructions on how to reproduce it? Thanks!


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
Hi,

All I have to do is drop a DockManager on my otherwise empty form, rightclick it and select "Create tool window...". The created Tool window will have the Visible property set to False. I can change this to True, close the form in the designer and whenever I open it again, the Visible property is false. I'm not sure if I'm seeing a different behavior here than you or if you perhaps didn't check it out at all? :)
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
We didn't look at it yet. Sometimes when customers report bugs, it is actually caused by things they've done wrong and they catch it when building a repro. So by having customers either send a repro project to us or giving us steps to repro it is good because it finds those situations and also enables us to see the issue if it is our bug. Thanks for the reply and we'll check it out.

Do you offhand happen to know when this behavior started, as in which build?


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
Hi,

Sorry if I sounded harsh, that wasn't my intention. However, I do get a bit frustrated to wait ~24 hours for a "Please repro this so we can look into it" answer. I know that it is by far the best option for you, but please consider that I, as a developer, have a busy day as well, and may wish to spend my time with more beneficial things than trying to hunt down your bugs :). If you can't reproduce the described behavior at all, I will of course do my very best to try and repro the issue (although it can be really troublesome and time consuming!), but please give me the benefit of the doubt and check it out before urging me to make sample applications - when writing on this forum and asking for help, I have usually already spent a lot of time trying to figure out the bug or work around it :).

Besides that, keep up the great work - I'm very excited to see what the future will bring us from Actipro Software :)
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Kasper,

Sorry, the posting instructions in the forums when you make a post of type "Bug Report" do specify to give specific repro instructions and/or a repro sample project. We get so many emails every day that we have to prioritize and take care of the ones first who give us a sample project or very specific repro instructions. If those details aren't provided then we generally have to assume that the customer hasn't looked into it much yet. We've gotten burned a lot in the past where a bug report is made without clear repro instructions and we spend time investigating it only to find it wasn't a bug with our product at all. Sorry to ramble, just wanted to let you know where all this comes from. :)

In your case though I believe you were replying to the existing thread and probably didn't get those bug posting instructions (you need to post with type Bug Report to see them).

So all is good, we narrowed down the bug and have it fixed for the next maintenance release. If you'd like a preview build to try it out on your end too, send an email over and we can hook you up.


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
I guess I just assumed that you remembered me, since I have been posting a lot, as well as e-mailing you a bit, and since it seemed to be a bug which re-appeared, I didn't know how much details to provide. I always try to be as specific as possible when posting bug reports, since I know that anything else is very annoying to the developer :). Anyway, I'm very happy that it was fixed. I'm not in a hurry to get the new build, unless it will be a while before it's released? :)
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Of course we remember you, you're always a pleasure to work with. We'll try and get the next maintenance release out in a week or two. But if you need a preview build before that, just let us know and we'll be happy to set you up.


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
Thank you for the kind words and right back at you :)

I'm holding off a couple of maintenance releases of my own applications for this bug, so if you have a stable build, please do send it to me, if you still have my e-mail address somewhere - if not, just let me know and I will throw you an e-mail :)
Posted 12 years ago by Kasper
Avatar
Thank you for the early build. I have just tested it a bit, and the bug seems to be gone. Good work :)
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Great, be sure to grab the official build when it comes out.


Actipro Software Support

Posted 12 years ago by Kasper
Avatar
Hi,

It has been a couple of weeks now, and I would really like to update my products with the latest version of UIStudio - do you have an ETA on the final release of 2.0.95? I'm eagerly awaiting it :)
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
We'll try and get it out in the next several days.


Actipro Software Support

The latest build of this product (v2020.1 build 0400) was released 9 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.