This is a migrated thread and some comments may be shown as answers.

RadWindow.Opened is obsolete

10 Answers 247 Views

Window

This is a migrated thread and some comments may be shown as answers.

This question is locked. New answers and comments are not allowed.

10 Answers, 1 is accepted

answered on 21 Jul 2011, 03:52 PM

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

Register for the Q2 2011 What's New Webinar Week. Mark your calendar for the week starting July 18th and book your seat for a walk through of all the exciting stuff we will ship with the new release!

answered on 26 Jul 2011, 08:41 PM

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?

answered on 16 Jul 2012, 05:30 PM

>>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).

answered on 20 Jul 2012, 04:29 PM

>>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... :-)