2010Q1.SP1: Popups are not being removed from the RadWindowManger causing multiple popups

[Jeff]

After taking the latest 2010Q1.sp1 release we have found the following behavior in our site causing multiple popups to appear.

The Behavior:

• We have a grid, each row of the grid has a content menu with options. 
• One of those options brings up a popup ("edit detail of record") type of thing. 
• The the user closes the popup by hitting the Red X in the upper right.
• The user picks another row, picks the content menu and again is presented a popup detailing the row.

However, both row 1 and row 2 popups are rendered

We repeat and find that every popup that we open and close, is redisplayed, so soon we have dozen of popups when we go to open just one.

The Code:
Below is the code we have been running that brings up the popup detailing the selected record

                        RadWindow wnd = new RadWindow();

                        wnd.NavigateUrl = viewDetails;
                        wnd.Width = 900;
                        wnd.Height = 620;
                        wnd.Top = 120;
                        wnd.VisibleOnPageLoad = true;
                        wnd.OnClientShow = "OnClientShow";

                        Master.RadWindowManager.Windows.Add(wnd);

The Debugging Walk Through:
What we have found, is that the rad window manager is no longer removing the closed windows.  So while debugging the code the RadWindowManager.Windows collection had 0 objects, then 1, then 2, then 3, then 4 ....

And everytime we then run this code, all the past windows are again rendered.

We need the windows to remove themselves from the RadWindowManager when the user closes the window. 

Thank you.
Tim

[John Cooney]

HELP!

I have a very similar problem in 2010 version.  I duplicated code I had working fine from a prior Telerik version and have now blown a whole day trying to figure out what is going on.

I have attempted to fix with adding in:

addsectionwindow.DestroyOnClose =

True

 

and

addsectionwindow.Behaviors = WindowBehaviors.Close

to no avail.

It seems that you can't destroy the old window so each subsequent time you come into the modal window you have yet another new window.

[John Cooney]

I just found this in another post.

set enableviewstate = false in the radwindowmanager solves my problem.

Apparently that setting was not necessary in the 2009 version because my old code worked fine without this.

[Jeff]

We have had several  breaking changes with this lastest release.

We really need more detail about this change from Telerik besides a quick patch.

Service packs should not break existing functions.

[Georgi Tunev]

Hello Tim,

This feature (RadWindow in RadWindowManager preserves its state) was included in the Q3 2009 release and we published information about in the release notes and the Changes and backward compatibility section in the documentation.

Best wishes,
Georgi Tunev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Jeff]

Thank you for the link.  Our team will try the suggestions today.

We had failed to implement the 2009.Q3 release as it had too many breaking changes that affected our product. 

I do appreciate the support we recieve in the forums, but please send a message back to your development teams that changes to existing behaviors are rarely ever appreciated.

We are now entering our 3rd week of regression testing after taking this last 2010Q1 install and are still finding changes that are taking down our product.

[John Cooney]

You people have a fantastic product here and it is very well supported.

I would agree with Tim though that the backward incompatible updates should be kept to an absolute minimum whenever possible.

I did not apply 2009 Q3 and never read the notes for that.

[Georgi Tunev]

Hi guys,

We perfectly understand your concerns and I can assure you that we do our best to minimize the impact of such changes. In this case we are talking about missing functionality, that has been requested many times by different customers, so we've had to add this feature to our product. We added the info about that change in the documentation and as far as I remember, we've had a sticky forum post about it for some time.

I would like to use the opportunity to ask something in relation to this topic. What, in your opinion, is the best way to inform you about such changes? I will be grateful if you share your thoughts about that.


Best wishes,
Georgi Tunev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Jeff]

Good question.

I get the the first pass of information from the release notes when the product is finally released and downloaded. 

I do not have time to keep up with the blogs, betas, forums.  I really only get the "Telerik" hat on when it is time to get the latest version integrated into our product.

As mentioned, we failed to integrate the 2009Q3 into our product and now it is my turn to attempt to integrate the 2010Q1.  This of course means I'm two releases behind.

One suggestion is in the release notes, we were to have links to the blogs, and forum posts that occurred during the development cycle.  Otherwise, I have a release note item like "changed the reporting parameter object" and I have to stumble into the ramifications as I implement.

[John Cooney]

Again, I would reiterate that overall I think you guys have an excellent well supported product.

I work as an independent consultant, so a week in which I've spent a couple days trying to get a certain functionality to work and a few days installing releases, reviewing release notes, and bringing my application up to date with the new release could be a week in which I earn $0.00.  For somebody who works on a development team it may be a different story.

One idea, if you are going to make significant changes that break old code is to come out with RadWindowManager2.  That way old code looks at the old control and when people develop new code they can drop in the new control.  That may ease the transition process.

Another idea I would give you is to create a Best Practices type of help file.  In my case, I needed to have a form, pop up a child window, gather some data in the child window, then close that child window and populate the parent window with updated data.  This is a very basic and obvious need for a developer.  I poked around in your examples, found a way to do this and got it to work.  If that code example had been referred to as 'Methodology A' for instance and I could then go back to the Best Practices file and find that 'Methodology A' is no longer considered current as of release 20XX or that 'Methodology A' requires these changes as of version 20XX or whatever.

I guess my point is that you have a ton of great support material available to us but coming up with ideas to help people navigate this vast material in the most efficient manner would be appreciated.

[Jeff]

I went back to the prior Q3 release notes (including service packs) and found no mention of this change in default behavior of opening up all past windows for the RadWindow. 

Additionally, I had another RadWindow skin change that was introduced in Q3 but I do not see that mentioned in the release notes either.  That forum post is here ...2010 Q1: Window Icon in Upper Left is now Green



2009.3.1103

• RadWindow

  What’s New

  • Added ability to close a RadWindow from inside the content page by calling window.close as an alternative for GetRadWindow().close()
  • ContentTemplate –ability to load content (controls) from the current page instead of showing a different page.
  • If you have multiple window managers on the page, you can call radalert, radconfirm and radprompt for each individual instance (manager.radalert())
  • New property Opacity which controls the opacity of RadWindow. It could be set both on the server and on the client and it gets values between 0 (transparent) and 100 (opaque)
• 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  2009.3.1208
  

  RadWindow

  What’s New:

  • New AnimationDuration property
  • Added ability to clear the cached properties when cloning RadWindowManager/RadToolTipManager
• 2009.3.1314

[Georgi Tunev]

Hello again guys,

John, regarding the "Best Practices" help, we are currently creating scenarios for the Telerik's Visual Studio Extensions Template Wizard. I will make sure that we include templates for scenarios as the one that you described. In addition, we consider to change and reorder the way the support articles are provided which will make the search in different resources much more easier, but this will take some time as the process is quite complex.

Tim, the problem with the ViewState is mentioned in these release notes - in the Fixes section:
Fixed: ViewState problem with RadWindows declared in a RadWindowManager
Of course not providing enough information regarding this change is our mistake for which we apologize.


Greetings,
Georgi Tunev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.

[Matt Ray]

My question is this, then: I am creating multiple windows dynamically over the course of different postbacks. I noted that closing the window did not remove it from the Window collection (as noted in this post). The suggested resolution is to set EnableViewState to False. When I do that, however, I seem to only be able to keep one window in the collection at a time between postbacks. How do I balance being able to properly dispose of windows as they are closed (via the "x" button built into the window), but also manage multiple windows being visible at once?

[Georgi Tunev]

Hello Matt,

The behavior that you experience is expected. DestroyOnClose destroys RadWindow's client object - it does not affect the control on the server. RadWindow does not provide the requested functionality out of the box (because this would mean that you would need to make a trip to the server every time you click the [X] button).
To implement the desired logic, we would suggest to manually clear the Windows collection on the server when needed.

I hope this information helps.

Kind regards,
Georgi Tunev
the Telerik team