RadWindow.Opened is obsolete

[Mike]

"This event will not be fired anymore."

Why is this not breaking my build?  I spent a lot of time tracking down the error that was causing my window to not load properly, only to stumble on the hard-to-see comment that the event will not be fired anymore.

Also, what is the preferred method to use now that this event is obsolete?

[Ivo]

Hello Mike,

Thank you for contacting us.

If you want using of obsolete events, methods and properties to break your build, you need to turn on Treat Warning As Errors for your project from Visual Studio.

This event was obsolete, because it was called synchronously right in the middle of the window.Show() method, which means that you could move your code from the handler of the Opened event just after the call to the Show method.

All the best,
Ivo
the Telerik team

[Kevin]

I was using the Opened event to get a handle to the canvas that acts as the parent of the window once it is shown.  The reason is I want the window to close when the user clicks outside of it. 

Now that the Opened event is no more, I can't figure out another event that will serve this purpose.  I have tried Loaded, Activated, a custom ShowDialog that attempts to get the canvas after the ShowDialog call, and nothing seems to work.  At any of these events, the parent of the window is null (I guess because it has not been shown on the screen yet).

Can you suggest a method to do this given the Opened event has been obsoleted?

[Anatoly Chekh]

In this case why methods Show() and ShowDailog() are not virtual?
We create our dialog inherets from RadWindow and did some common actions in the Opened event.
So now we should call this code from all places where different dialogs are shown. This's not convinient.

Thanks, Anatoly Chekh,

[Kevin]

Can we please have the opened event back?

We need something to be able to react once the window is open and showing on the screen.

[Valeri Hristov]

Hi Kevin,

You could use the Loaded event for that. The Opened event should have been raised in the same moment...

Best wishes,
Valeri Hristov
the Telerik team

[Lee]

I have to say that I agree with the other posters in this thread.

I use the Opened event from within custom RadWindow controls that are specific to that RadWindow (i.e. pre-populating RadDatePickers to current date, or other fields that need to be pre-populated).  I don't want to have to do all of that UI initialization from within the parent windows that instantiate the RadWindow.  I could call those RadWindows from several different forms.

Rewritting all of the code to move everything from the Opened event handler to the Loaded event handler is a pain and very time consuming.

[Dean Wyant]

>>This event was obsolete, because it was called synchronously right in the middle of the window.Show() method, which means that you could move your code from the handler of the Opened event just after the call to the Show method.

Code should not have to be moved. Opened was being called and now it is not. That is a shameful breaking change. Shame, Shame, Shame!!!

A remark in the help for the event stating that you can put your code after Show or use the Loaded event instead would have sufficed. How could there have been a need to quit calling Opened but leave it.
The poor RadWindow... it is never "Opened" anymore.... :-)

Telerik needs to change its policy. New policy: Events cannot become "Obsolete"... once they exist they are always relevant. You provide it, you are stuck supporting it forever.

Telerik should put the call back ASAP... call it wherever it makes sense. If it was in the middle of Show, and Telerik did not like that, then simply move it to the end of Show.

In a later post, we are told that the Loaded event is equivalent. Hmmm... first it was synchronous with Show, now it is synchronous with Loaded? If that is the case, I would expect that Loaded is synchronous with Show and thus; the Loaded event is "obsolete" and it will not be called starting with the next build. :-)

It was nice of Telerik to provide the Opened event in the first place. The Opened event for window objects is very handy. The Opened event is available for almost every window class. It is almost a standard. People get used to using it and then Telerik pulls the rug out from under them.

The call needs to be put back. If it does not make sense where it was, then move it. Call it right after Show or after Loaded if you like, but it needs to be called... in the same sequence as every other window control that has an Opened event (pretty much all of them).

[Ivo]

Hi Dean,

I understand your frustration, about this breaking change. However this event was made obsolete over an year ago and we cannot just add it back. We removed it, because It didn't make sense to call two events that notify about absolutely the same thing. Our controls are now into their mature state so no more breaking changes will be required . Also the Loaded event will never be made obsolete as it is inherited from the FrameworkElement class.

Kind regards,
Ivo
the Telerik team

[Dean Wyant]

>>It didn't make sense to call two events that notify about absolutely the same thing
I disagree. It does make sense. It is an interface issue. Opened/Closed are a pair. It was a mistake to think it made no sense and to make it "obsolete".

You are saying that it was a mistake to code the Opened event in the first place.
Ok... maybe. But, it was a much bigger mistake to make it "Obsolete". Then, to keep it hanging around in the code - popping up in Intellisense... wasting time... 

It was another mistake to keep it "obsolete" after being informed that it was a "breaking" change.
This is a string of mistakes that have compounded and resulted in no benefit to anyone.

The Opened event made sense because of the Closed event... Opened/Closed are a pair. These are events expected to be in the interface. If Opened and Closed are provided for other controls, then it made sense to provide them for RadWindow. Telerik has made these events "common" events by providing them in their pop-up type controls. It makes perfect sense to have them in RadWindow also.

Who cares if there is no code between Loaded and Opened? Perhaps Telerik would like to add some later? 
I think there are fairly good arguments for the existence of the Opened event.
But, I see the argument for making it "obsolete" as very weak... especially since it is still causing problems.  

>> Our controls are now into their mature state so no more breaking changes will be required
I find it very difficult to believe that this change was "required". If this was changed before the code was in its "mature" state, then the Opened event should not even exist at this time!!! If the code is "mature", then the "Obsolete" events etc should be removed from the code!

Since Telerik is not going to provide an Opened event because it would fire at the same time as Loaded, then please remove the Opened event entirely so it does not show in the Intellisense for the control. If it has been "obsolete" for over a year, then surely it is time to remove it completely.

This is totally a bunch of silliness... :-)

[Ivo]

Hi Dean,

Thank you for your feedback.

The Opened event will be removed for the 2012 Q3 version of RadControls for Silverlight.

All the best,
Ivo
the Telerik team