Index of DockState not persisting in UI for ASP.NET AJAX Dock

LeBear

233 posts

Member since:
May 2006

Posted 10 Jul 2007 Link to this post

Hello,

I have to start with the general kudos on this version again. I've got an awesome system going here where I'm creating dynamic docks and loading them with user controls for a really cool portal interface. Almost everything works perfectly; I'm only stumbling on the nit picky stuff now.

I'm successfully loading the user's page with all of their gadgets (docks loaded with custom user controls), and I have a "Save Layout" button on the page. When they click that, the DockState of each of the docks is stored in the database with the user's configuration. Awesome new change: I can read the DockState to determine just what is in there. Thank you for that!

Now, when the page loads, I read all of the gadget configuration data from the database and build the docks with their user controls in a somewhat arbitrary order (the order in which they were initially added to the page.) As they are created, they are added to the page's DockLayout, but not to any specific DockZone. AFTER they're all loaded, I run through the configuration data again, applying the DockStates stored in the database. When I do this, they are all placed in the appropriate DockZone, but within each zone, they are displayed in the order in which they were created - not in the order in which they were saved when the DockStates were saved. I can view the DockStates in the database. What I see is that the DockZoneID is correctly set as are the values for Index (starting with 0, they are numbered in order - 0, 1, 2). However, since 2 (for example) was created first, it still shows at the top of the indicated DockZone, and not at the bottom as it should.

Side Note: Originally I applied the DockStates as the docks were created, but I thought I might fix this by having all of the docks loaded then going back and applying their states. It didn't work. A side question would be - Should I need to apply the DockStates only after all of the docks are loaded?

Any help on this?

I could save the individual settings of the DockState in the database and then load them on the page in order, but if you're supposed to be handling this for me, I'd rather take advantage of it.

Note that, as I would expect, when you click the "Save Layout" button, the page loads with the gadgets in the correct order, but only because it's loading the page from a PostBack.

Thank you.

LeBear

233 posts

Member since:
May 2006

Posted 10 Jul 2007 Link to this post

Doing some playing...

Immediately after applying the DockState to the Dock, I specifically set the Index value on the Dock to the value of the Index in the DockState, and it works.

I wouldn't think I would need to do this.

----------------

And, to answer my side note above, I can apply the DockState at the time the Dock is created/loaded. I don't have to go back in a second loop to do it.

Petya

Admin

869 posts

Posted 11 Jul 2007 Link to this post

Hello Barry,

Applying the state when the docks are created should correctly set the index as well - make sure you are using the latest version of the control. Here you can find a sample project we created demonstrating a possible approach to dynamically creating RadDocks and preserving the state information in database. You will notice in the code that upon creation of each dock we call dock.ApplyState(DockState) which correctly sets all the necessary state data to the dock including the index as well.

All the best,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 11 Jul 2007 Link to this post

On first glance, I'm doing the same thing you're doing:

        D_lob = New RadDock()
        DS = DockState.Deserialize(ViewState_ast)
        D_lob.ApplyState(DS)

However, in my system, I later force the gadget to the first docking zone if they've just added the gadget (and as such, there is no DockState yet), or they've selected a new page layout that has less docking zones (and as such, the DockState references a non-existent docking zone.) To do this, I added the following code (after application of the DockState):

        If D_lob.DockZoneID = "" Then
            D_lob.DockZoneID = "DockZone1"
        End If

        ZoneID_lin = CInt(Mid(D_lob.DockZoneID, 9))
        If ZoneID_lin > LastZone_gin Then
            D_lob.DockZoneID = "DockZone1"
        End If

When I added this, I got an error that said I either had to use the dock method (passing the docking zone, which I don't have available in this scope) or make sure the dock is added to the dock layout. I chose to make the dock layout available in this scope, and I added the following statement:

        DockLayout_gob.Controls.Add(D_lob)

(Note that I'm testing with gadgets placed in Zone 4 when there are at least 4 zones, insuring that all of my gadgets have valid DockStates and I'm not overriding them to be in Zone 1.)

What I've found through testing this out quite a bit is that if I use this statement, I lose the index and the gadgets are displayed in the zones in the order they were created.

It doesn't matter if I apply the DockState first or if I add the dock to the DockLayout first. Either way, I have to manually set the dock's index to the value in the DockState in order for it to display the gadgets in the proper order.

The code that creates the dock now looks like this:

        D_lob = New RadDock()
        DS = DockState.Deserialize(ViewState_ast)
        D_lob.ApplyState(DS)
        DockLayout_gob.Controls.Add(D_lob)
        D_lob.Index = DS.Index

Later in the code, I do the assignment to Zone 1 ONLY IF the dock was supposed to be in a now non-existent docking zone, or if it had none assigned.

I don't know if this is an anomaly in the code or if it has a purpose for working this way, but it seems pretty clear what's happening now.

Thanks.

Petya

Admin

869 posts

Posted 12 Jul 2007 Link to this post

Hello Barry,

Now that you provided detailed information on your scenario, we investigated the issue and discovered that it is truly a problem due to the specifics of the control. We are glad that you found a solution and apologize for the time you lost investigating this odd behavior. We have logged the issue in our system and will try to improve the control so that scenarios like yours work without the need to set again the index. Thank you for your feedback that will help us improve the quality of our products.

Regards,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 12 Jul 2007 Link to this post

Apologies are appreciated, of course, but not necessary. I don't think there's a developer in the crowd that doesn't expect issues to come up now and again. I'm glad to have been of service to help improve your products - you certainly have helped to improve mine!

Thanks.

LeBear

233 posts

Member since:
May 2006

Posted 23 Jul 2007 Link to this post

Hello Telerik,

I'm finding that my trick isn't always working. It seems to improve the results, but I still end up with things out of order. I'm working on ways around this, but it's not proving to be fruitful.

Can you tell me if this will be address in an upcoming maintenance release, and if so, when?

Thank you.

Valeri Hristov

Admin

2252 posts

Posted 24 Jul 2007 Link to this post

Hello Barry,

We will try to provide a bugfix by the end of the week. Check this forum again in a couple of days for a sticky thread with the latest build.

All the best,
Valeri Hristov (Senior Developer, MCSD)
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

Dave

37 posts

Member since:
Jan 2007

Posted 03 Aug 2007 Link to this post

Has this been fixed yet, I am also having the same issue.

Petya

Admin

869 posts

Posted 07 Aug 2007 Link to this post

Hi dedbauer,

This issue has not been addressed yet. We will try to work on it soon and provide a solution. However, I cannot specify any time this will be done due to scheduled work on the control.

Best wishes,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 07 Aug 2007 Link to this post

:)

Please... oh, please put this on a higher priority. (Said with complete ignorance of whatever issues you may be having to address...)

I'm using this in a prototype application for a customer, and while I can certainly deal with this, I'd really like for them to see it working.

Thanks.

Petya

Admin

869 posts

Posted 09 Aug 2007 Link to this post

Hello Barry,

I saw in another thread that you have written that the issue was solved - are you referring to this issue or to another one. For the issue in this thread with the index - it is difficult to fix it because it requires some modifications in the logics of the control which takes longer time to implement and test afterwards.

Kind regards,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 09 Aug 2007 Link to this post

No, I was NOT referring to the issue in this thread. (Emphasizing, not yelling.)

The index issue is still a problem.

Thanks for the update on the magnitude of the issue. It's am important issue for me and I appreciate an understanding of this that I can report back to my customer.

As a temporary work-around, I was going to re-order my data before building the docks so that they would be created in the order they needed to be displayed on the page. I'm not certain this will help, though. Can you shed any light? Will the docks always be displayed in the order they are created, or does it somewhat random. (Through casual observation, I thought first they would appear in the order they were created, then I wasn't sure.)

Thanks.

Petya

Admin

869 posts

Posted 09 Aug 2007 Link to this post

Hi Barry,

If you do so, most probably you will get ViewState errors of the kind "Failed to load ViewState". One possibility might be to handle LoadDockLayout event and set the correct index for every dock there taking it from your data store. In this way you re/create them in the standard manner avoiding the ViewState problems and handle the index issue manually in LoadDockLayout so that in Render the docks will have the correct indices and will render in the correct order. Hope this helps.

Regards,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 12 Aug 2007 Link to this post

Ah, yes, of course.

If I do any sort of postback and the control tree on the page ends up being built differently than when the page originally loaded, this can certainly happen. I should have thought of that.

I will check out LoadDockLayout event.

Thanks.

LeBear

233 posts

Member since:
May 2006

Posted 20 Aug 2007 Link to this post

:(

I've added a DockLayoutHandler. Inside the handler, I set the DockZoneID and the Index on both the DockState and the Dock itself. It's still displaying them in the order the docks are created, ignoring the index.

So, um, when do you think there will be a fox for this?

Petya

Admin

869 posts

Posted 21 Aug 2007 Link to this post

Hello Barry,

We have currently concentrated on the coming release in September and this is why the issue has not been addressed yet. If you are pressed by deadlines, we could try to review your code when you attempted the last thing we discussed if you send us a running project and see why it does not work this way. We will try to address the issue right after the release, but nothing is certain because of the specifics of the issue itself - as I wrote you it requires modifications of the logic of the control.

Greetings,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

Dave

37 posts

Member since:
Jan 2007

Posted 10 Oct 2007 Link to this post

Any update on this timeline for the fix to this issue?

Valeri Hristov

Admin

2252 posts

Posted 16 Oct 2007 Link to this post

Hi dedbauer,

Unfortunately the work on RadDock was postponed this quarter in favor of RadEditor. RadDock will receive upgrade in the upcoming quarter for sure, we will update the "best practices" examples and the control itself in order to provide smoother operation and several new features.

Greetings,
Valeri Hristov (Senior Developer, MCSD)
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 31 Oct 2007 Link to this post

Is there going to be a patch for this, or do we have to wait until the next quarter's release. My customer is starting to use this more, and as such, they are dropping hints at how nice it will be when it's fixed.

I'd like to provide a fix before the move on from just dropping hints - but I also have no problem waiting for it to be done right.

Thanks.

LeBear

233 posts

Member since:
May 2006

Posted 28 Nov 2007 Link to this post

Here it is a month since I last asked about this and 3 weeks after an SP has been released, and I just found out about the SP 2 release. I'm in the process of installing it, but I'd like to know if this is addressed in the SP.

--update--

:( Doesn't look like it's fixed.

Ivo

Admin

689 posts

Posted 30 Nov 2007 Link to this post

Hello Barry,

Please, accept our sincere apologies for all the delay and confusion we have caused here. Let me shed some more light on the problem at hand and our plans for addressing it:

We have attempted to improve RadDock behavior but unfortunately fixing the problem causes side effects which we can not overcome with an easy patch. We need to change the architecture of the control and provide better flexibility. That being said, we do not want to risk breaking key features with this fix (as we now have little time before our Q3 2007 release) and we will address the problem thoroughly in the beginning of next year.

Once again, I am sorry for making you wait so long for a fix on this but the problem seems more fundamental than we initially though.

Thank you for your understanding and patience.

As previously discussed, the problem can be overcome with external code which eventually seems to be the best option for the time being, because of the implications and possible breaking changes if RadDock itself is changed now.

Regards,
Ivo Nedkov
Unit Manger, RadControls for ASP.NET
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

Kris

1 posts

Member since:
Jan 2007

Posted 11 Jan 2008 Link to this post

Good afternoon just looking for an update on this issue,

We've been experiencing issues with the latest version of the Prometheus dock control whereby the docks are rendered in the order they are added to the control collection instead of using the index, the same issue discussed in this thread. Our problem stems from the fact that we have software being used by our clients that has the dock functionality using a version before the index bug was an issue and now we have a requirement to move to the new Prometheus tree view from the older tree view. By the looks of this thread a fix should be coming this year, is this fix intended for Q1 or later in the year?

Assuming the changes to the Promtheus dock are coming in Q1 that would make it sometime in the neighbourhood of late march or early april correct? Understanding of course that those dates would be difficult to nail down at this point in time.

Thanks guys,

Kris.

Petya

Admin

869 posts

Posted 15 Jan 2008 Link to this post

Hello Kris,

We will do our best to approach this matter for Q1. However, if we see that the changes needed to be made in the control's code would break backwards compatibility, then we will likely search for a solution where you can add some additional code to workaround the issue. And yes, Q1 is to be in the spring with rough estimates for April.

Best wishes,
Petya
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

LeBear

233 posts

Member since:
May 2006

Posted 15 Jan 2008 Link to this post

Please, oh please do your best to fix this bug - for that's what it is. It would be unfortunate to have to code around the bug with a workaround.

For, in fact, I attempted the workaround previously suggested, and it didn't work. Granted, I didn't investigate much after the attempt to see why. It's possible I didn't do it right, or it's possible that it just didn't resolve the problem, but either way, it's way preferable to not have to write workarounds for known bugs.

Thank you for your efforts in addressing this.

LeBear

233 posts

Member since:
May 2006

Posted 29 Jan 2008 Link to this post

Ok, so apparently, on the same day as my last post (2 weeks ago), a rather quiet new version was released. On it, under radDock, I see the following:

New DockCommandsCollection Insert method so that docks can be added at a specific index server-side.

Can it be so? Is this new feature a fix for this problem???

LeBear

233 posts

Member since:
May 2006

Posted 29 Jan 2008 Link to this post

Oh the agony of it all...

I see that this (as stated) affects the DockCommandsCollection. Instead of being able to add docks at a specific index, you're able to add dock commands... :(

LeBear

233 posts

Member since:
May 2006

Posted 29 Jan 2008 Link to this post

:)

I think I'm on to something!

It was suggested a while back that I try using the LoadDockLayout event to work around this problem. I had attempted to do this, but I wasn't able to solve the problem. I admitted that I didn't do my homework to determine why it failed or even if I had done it correctly, and instead I just decided to wait for a fix from Telerik.

When looking at this latest patch release, I did some more browsing through the documentation, and found the article, Dynamically Created Docks. By implementing the CurrentDockStates property and the LoadDockLayout and SaveDockLayout event handlers, I made some real progress.

I've done a few quick tests and the order of the docks seems to stick after saving the layout (dock states).

A problem I've noticed is that the CurrentDockStates property seems to be storing the list of DockStates in the session, so when I lose my session, I lose the order of the docks. My next test is to store the list of DockStates in the database along with where I store the individual DockStates for each of the docks instead of using the session. I'll post an update once I've had a chance to test this out.

Keep your fingers crossed!

LeBear

233 posts

Member since:
May 2006

Posted 30 Jan 2008 Link to this post

Well, I got up earlier than I wanted to today, but I'm feeling good!!

What was happening:

During the Page Init processing, I load my portal page, applying the dock zone and index to each of the docks and their states. By the time the page was rendered, only the value for the index was being overwritten.

What I did:

I used the LoadDockLayout event to apply the dock states' zone and index to the DockLayoutEventArgs as documented in Dynamically Created Docks. This wasn't working, so I added some diagnostic outputs during the event and saw that the docks and their states had their index values altered. Apparently, they were being overwritten according to the order they had been created.

Rather than going back to the database to fetch the dock states again, I decided simply to create an array of independent dock states that I created as I created the docks. My goal was to have a collection of dock states that I knew could not be altered elsewhere. Then, during the LoadDockLayout, instead of using the docks or their states, I used my personal collection of states to apply to the DockLayoutEventArgs. This is working!

The upshot of this is that the documentation online (Dynamically Created Docks) works, but it still doesn't appear it should be needed. All other dock state information is preserved. It's just the index that is lost/overwritten.

I'm hoping that when this is addressed I can simply remove the event handler and also that leaving it in won't cause other problems at that time. Any advanced insight into how this will play out would be appreciated.

Regardless, I get to be the hero at my client site today!

Thanks.

Tervel

Admin

1337 posts

Posted 01 Feb 2008 Link to this post

Hi Barry,

We are glad that you found the time to implement a workaround. It would be great if you share some code with the community for other people to use.

As we stated earlier, we believe that having the code outside the product itself, rather than integrating it might turn out to be the preferable option - as it might break other scenarios that worked properly. Once we get to this issue and investigate and test it in more detail, it will become clear what the preferable approach should be.

Best regards,
Tervel
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center