Please help me,
Im adding a radwindow dynamically (using the code behind)
and then after the radwindow is closed i'd like to perform some manipulation.
When i use the .Close() function the 'Closed' event is handled, but when I press the Close button ('X' button at the top right of the radwindow), the 'Closed' event is not handled.
Can someone help me please.
Here is the code,
Telerik.Windows.Controls.RadWindow frm = new Telerik.Windows.Controls.RadWindow();
frm.Closed += new EventHandler<Telerik.Windows.Controls.WindowClosedEventArgs>(frm_Closed);
this.LayoutRoot.Children.Add(frm);
frm.Show();
private void frm_Closed(object sender, Telerik.Windows.Controls.WindowClosedEventArgs e)
{
}
Im adding a radwindow dynamically (using the code behind)
and then after the radwindow is closed i'd like to perform some manipulation.
When i use the .Close() function the 'Closed' event is handled, but when I press the Close button ('X' button at the top right of the radwindow), the 'Closed' event is not handled.
Can someone help me please.
Here is the code,
Telerik.Windows.Controls.RadWindow frm = new Telerik.Windows.Controls.RadWindow();
frm.Closed += new EventHandler<Telerik.Windows.Controls.WindowClosedEventArgs>(frm_Closed);
this.LayoutRoot.Children.Add(frm);
frm.Show();
private void frm_Closed(object sender, Telerik.Windows.Controls.WindowClosedEventArgs e)
{
}
5 Answers, 1 is accepted
0
Accepted
Hi Damien,
In our latest release we decided to change the functionality of RadWindow's close button. Now, whenever a user clicks on the Close button the window is just hidden, e.g. it internally calls the Hide() method of RadWindow. If you want to close the RadWindow using the Close button, you should handle the Hidden event of RadWindow and then explicitly call the Close() method so that the RadWindow's reference is removed from the code.
By the way, it isn't necessary to add any RadWindow to the LayoutRoot element of your Silverlight application, because the RadWindow performs all necessary actions for the layout positioning internally. Therefore, you don't need the following line of code:
this.LayoutRoot.Children.Add(frm);
Greetings,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
In our latest release we decided to change the functionality of RadWindow's close button. Now, whenever a user clicks on the Close button the window is just hidden, e.g. it internally calls the Hide() method of RadWindow. If you want to close the RadWindow using the Close button, you should handle the Hidden event of RadWindow and then explicitly call the Close() method so that the RadWindow's reference is removed from the code.
By the way, it isn't necessary to add any RadWindow to the LayoutRoot element of your Silverlight application, because the RadWindow performs all necessary actions for the layout positioning internally. Therefore, you don't need the following line of code:
this.LayoutRoot.Children.Add(frm);
Greetings,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 24 Oct 2008, 12:20 AM
We just encountered this problem, and I'm not sure I agree 100% with your fix.
We currently inherit Window to emulate a lot of the missing functionality of this control.
And then we have our silverlight application create windows that inherit "our" version of your control to encapsulate everything that occurs within that window (such as a customer editing screen).
While I can understand why you'd not necessarily want the close button to dispose the Window object so you can see the dialog result or other properties on it, it assumes that the close action should actually hide the control. It doesn't provide a "cancellable" event between the clicking of the button, and the actual hiding.
So, to implement an "Are you sure you want to close?" type of situation requires one to change the way "Hidden" works (force it to call close and then let the "Closing" event always cancel, and manipulate the visibility).
While this way works, it's hacky, and causes a little visual glitch to occur (a quick hide, then re-show happens because of the default behavior on re-draw)
Furthermore, it fires the "Opening" event for no good reason because Show() is being called, which means all subscribers of that event have to be aware that it may re-fire when the close is cancelled.
The other way around this forces the parent container to perform "business" logic that is really the job of that editing window (which breaks encapsulation pretty severely). We still get the "hide-reshow" glitch if we decide to cancel.
If you don't want the hidden costs of the Close() method (such as the disposal) to burden the control, it would be nice if a "Hiding" event was implemented to provide a way of cancelling that close button's operation. Then we wouldn't have to hack around it, cause visual glitches or make events fire that shouldn't.
Better yet, make the events ClickHide and ClickHiding so the subscribers don't have to differentiate between a close click and a call directly to Hide().
Thanks
Dan
We currently inherit Window to emulate a lot of the missing functionality of this control.
And then we have our silverlight application create windows that inherit "our" version of your control to encapsulate everything that occurs within that window (such as a customer editing screen).
While I can understand why you'd not necessarily want the close button to dispose the Window object so you can see the dialog result or other properties on it, it assumes that the close action should actually hide the control. It doesn't provide a "cancellable" event between the clicking of the button, and the actual hiding.
So, to implement an "Are you sure you want to close?" type of situation requires one to change the way "Hidden" works (force it to call close and then let the "Closing" event always cancel, and manipulate the visibility).
While this way works, it's hacky, and causes a little visual glitch to occur (a quick hide, then re-show happens because of the default behavior on re-draw)
Furthermore, it fires the "Opening" event for no good reason because Show() is being called, which means all subscribers of that event have to be aware that it may re-fire when the close is cancelled.
The other way around this forces the parent container to perform "business" logic that is really the job of that editing window (which breaks encapsulation pretty severely). We still get the "hide-reshow" glitch if we decide to cancel.
If you don't want the hidden costs of the Close() method (such as the disposal) to burden the control, it would be nice if a "Hiding" event was implemented to provide a way of cancelling that close button's operation. Then we wouldn't have to hack around it, cause visual glitches or make events fire that shouldn't.
Better yet, make the events ClickHide and ClickHiding so the subscribers don't have to differentiate between a close click and a call directly to Hide().
Thanks
Dan
0
Hello,
You are right indeed. We will add the preview hide event with the Q3 release. Thank you for the feedback.
Dan, can you clarify what you mean by that:
"We currently inherit Window to emulate a lot of the missing functionality of this control."
Can you tell me what is the missing functionality that you need? I'm very interested to know how can we further improve the control.
Thanks!
Best wishes,
Valentin.Stoychev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
You are right indeed. We will add the preview hide event with the Q3 release. Thank you for the feedback.
Dan, can you clarify what you mean by that:
"We currently inherit Window to emulate a lot of the missing functionality of this control."
Can you tell me what is the missing functionality that you need? I'm very interested to know how can we further improve the control.
Thanks!
Best wishes,
Valentin.Stoychev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 24 Oct 2008, 05:00 PM
Just to clarify, when I said "alot", I didnt mean for it to come off as the control was worthless. It's actually very well put together, and you have all done a great job. Much of the missing functionality I'm referring to probably isn't even in the scope of what your product should provide. Our version's behavior caters to a much smaller audience (our end users and their sometimes bizarre notion as to how the UI should act).
There are a few things that would probably benefit your audience though.
Things that would benefit your control (at least in my opinion), I've posted here already (and in some cases, posted the work-around code for your end-users until you can address it officially (if you decide to)... A recap of some of the things that might be good to implement:
1) Minimize/resize behavior (you can drag-resize a minimized window, which leads to strange behavior and de-synchronizes some of the other properties, such as the WindowState)
2) Cascading of windows within the parent container on show (start-up position is slightly offset of the previously opened window, and handles the new positioning so it doesn't go out of view within the parent).
3) Property to hide/show the close button rather than manipulating the control template. Or expose the close button's style so that the template can be applied non-globally.
4) This one I'm not sure of in terms of scoping of your product, but it's something that helps with a real issue in the silverlight community. Because of the need for remoting calls to be asynchronous, we've added some features to our version that deal with disabling the Content area without disabling the entire window. This allows a window to process and display information concurrently with other windows, and allows the user to move the window around or out of view while the processing occurs. This might not be within the scope of your product though as everyone has a different theory on how to handle this type of thing.
5) Provide a cancellable event arg for the "click-hiding" when the close button is clicked (as I described in a previous post on this thread)
6) The ability to somehow script custom transition effects for Opening and Hiding. As it is now, the window animation is neat, but it's a little goofy and inconsistent (sometimes it performs the "explode" animation on opening twice). An animation on hiding would be slick too.
PS- you mentioned that the issue in this thread would be addressed in the Q3 release. We are technically in Q4 right now. Did you mean Q4, or will we be waiting an entire year for the fix?
Thanks!
Dan
There are a few things that would probably benefit your audience though.
Things that would benefit your control (at least in my opinion), I've posted here already (and in some cases, posted the work-around code for your end-users until you can address it officially (if you decide to)... A recap of some of the things that might be good to implement:
1) Minimize/resize behavior (you can drag-resize a minimized window, which leads to strange behavior and de-synchronizes some of the other properties, such as the WindowState)
2) Cascading of windows within the parent container on show (start-up position is slightly offset of the previously opened window, and handles the new positioning so it doesn't go out of view within the parent).
3) Property to hide/show the close button rather than manipulating the control template. Or expose the close button's style so that the template can be applied non-globally.
4) This one I'm not sure of in terms of scoping of your product, but it's something that helps with a real issue in the silverlight community. Because of the need for remoting calls to be asynchronous, we've added some features to our version that deal with disabling the Content area without disabling the entire window. This allows a window to process and display information concurrently with other windows, and allows the user to move the window around or out of view while the processing occurs. This might not be within the scope of your product though as everyone has a different theory on how to handle this type of thing.
5) Provide a cancellable event arg for the "click-hiding" when the close button is clicked (as I described in a previous post on this thread)
6) The ability to somehow script custom transition effects for Opening and Hiding. As it is now, the window animation is neat, but it's a little goofy and inconsistent (sometimes it performs the "explode" animation on opening twice). An animation on hiding would be slick too.
PS- you mentioned that the issue in this thread would be addressed in the Q3 release. We are technically in Q4 right now. Did you mean Q4, or will we be waiting an entire year for the fix?
Thanks!
Dan
0
Hi Dan,
Thanks for the feedback - I've updated your telerik points.
No, you don't have to wait a year to get the fix :). Our Q3 release is just behind the door - only 2 weeks left.
Sincerely yours,
Valentin.Stoychev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Thanks for the feedback - I've updated your telerik points.
No, you don't have to wait a year to get the fix :). Our Q3 release is just behind the door - only 2 weeks left.
Sincerely yours,
Valentin.Stoychev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.