I’m sending you an MDI Window with the following — intented — functionality, which, unfortunately I cannot achieve:
In the constructor I add two mdi child forms: One has a datetimepicker and the second one has a number of buttons on it.
A. When the browser opens, the second one is shown correctly for a split second with the buttons on it and immediately
afterwards the contents disappear. If I switch to the first form and then back to the second the contents show
B. The first time one of the buttons is clicked, a new mdi form is created, added to the mdi parent and is shown.
Additionally, a new textbox is created and added to the mdi form which just opened.
The following times a button is clicked there are two possibilities:
1. if the button hasn’t been clicked before, a new mdi form is created, added to the mdi parent and is shown. The
textbox that had been created earlier is taken from the form on which it was and added to the last form.
2. if the button has been clicked before, the form that had been originally opened by that button is activated and
the textbox is moved to it.
What I have observed is that the first time works alright.
Then, in case 1, a new mdi form is added correctly and gets focus, but the textbox disappears. It is neither on the
new nor the original form.
In case 2, the form corresponding to the clicked button does not get focus at all.
C. Aside from the above, I have a datetimepicker on the first form. When the calendar drops, the previous/next month/year
buttons are not visible, although when hovering over their expected position the cursor turns into hand and the tooltip
shows up and also the click functionality is ther.
All this is with Classic-2 theme.
2 issues have been fixed here in the latest build (1.2.31):
WJ-7437 Mdi child forms closed using the tab don’t fire FormClosing and FormClosed.
WJ-7438 Form.Deactivate is fired after Form.Activated, it should be the opposite.
It seems that neither FormClosing or FormClosed events fire. I’ve seen it in MDI child forms, I don’t know if it is also a more general Form problem.
I love control freaks! In coding, that is, not in every aspect of life!
Having said that, I just discovered a workaround, I can use the form.Deactivate and the ParentForm.MDIChildActivated, which fire in the right order.
We do have full control over the order of the events (and pretty much everything else in Wisej :)). And this seems to be a bug since the correct order is certainly Deactivate and the Activated. Will log and fix.
Luca and Frank, thank you for the bug fixes! Especially because the control moved between mdi children is not a simple
TextBox but a much more complicated UserControl and moving it between Mdi children (and refilling it)
proved to be much faster than instanciating it and filling it every time a new mdi form opened !
Continuing in the mdi form … As I said, an mdi child form A has a usercontrol in it. The user control in the
current mdi child form has a state, let’s say background color = red. When I switch from child form A
to child form B, I would like to preserve the status it had by storing it in the A.Tag property (so that if I switch back
to form A in the future, I can restore the status of the control). So, I am trying to use the Form.Deactivate
and Form.Activated events.
In the FormA.Deactivate, I store the usercontrol’s status in FormA.Tag. In the FormB.Activated, I switch the
parent of the user control (i.e. FormB.Controls.Add(usercontrol) and then I grab the stored status from FormB.Tag
and reload it to the control. Or this is what I wish …
The problem is that when I switch mdi tab, the FormB.Activated event fires before the FormB.Deactivate event.
This means that the usercontrol is first loaded to Form B and has its status changed, so when the FormA.Deactivate
event fires, the usercontrol is not in FormA.Controls anymore and its status has been lost.
I don’t know whether you have control over the order these events are fired, but I would think that the FormB.Activated
should fire after FormA.DeActivate.
There are other ways to do it of course, (like storing the usercontrol’s status to its parent Form every time the status
changes, so that it is already stored when the switch happens) but they are more chatty and involve going back and forth
to the server. So, I thought worth asking.
All the best,
good news: WJ-7421, WJ-7422, WJ-7423 have all been fixed in build 1.2.25.
WJ-7429 (“Reusing a disposed control doesn’t throw the ObjectDisposed exception.”) is fixed as well and also included in this build.
This now leads to an exception in your sample that was previously not exposed.
To avoid it, you can modify your code:
if (t == null || t.IsDisposed)
t = new TextBox();
You are right, you don’t see the exception because it’s an assert failure in debug mode. It should probably be moved down and make it an exception. 7422 refers to another problem we noticed testing your test case.
In fact after reading my original post and your answer, it is not clear to me if WJ-7422 refers to my reported problem A or B2…. 🙂
After all Text_# forms are closed, if I open up a new one I don’t see the Textbox, but I do not get any exception.
thanks for your input and sample.
I have logged the following 3 issues:
WJ-7421 Classic-2 theme doesn’t show the navigation buttons in the DateChooser control.
WJ-7422 Activating a new MdiChild while it’s created doesn’t make it visible the first time it’s shown
WJ-7423 Changing the parent of a child control at runtime causes the control to lose the parent.
We also found a potential error in the test code you provided:
If all the text_# forms are closed, the single TextBox instance is disposed, so the next time a form is created, you will get an Object Dispose exception.
Maybe you can check this ?
Hope that helps.