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

Index of DockState not persisting

37 Answers 374 Views

Dock

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

LeBear asked on 10 Jul 2007, 07:09 PM

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.

37 Answers, 1 is accepted

answered on 11 Jul 2007, 08:18 PM

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.

answered on 09 Aug 2007, 02:47 PM

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.

answered on 30 Nov 2007, 03:43 PM

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

answered on 11 Jan 2008, 09:51 PM

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.

answered on 30 Jan 2008, 01:33 AM

:)

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!

answered on 30 Jan 2008, 11:33 AM

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.

answered on 12 Sep 2009, 05:59 AM

Wow, two years later, and this is still biting me in the ass!

I've updated my portal to abandon partial-page postbacks in favor of light, direct Ajax calls. Now the portal doesn't do any postbacks at all. My reimplementation completely creates the gadgets/docks in Page_PreRender. Since there is absolutely no postbacks, this should be fine - except for the fact that the index still doesn't get applied. I tried the LoadDockLayout thing, but since I'm building the docs in PreRender, it didn't apply (there were no docks yet since that's an event handler and PreRender happens later).

When a change is made to the position/status of the docks, I make an Ajax call passing in all of the docks, and the Ajax routine updates the database. When the page is loaded next time, the dock states are read from the database.

My only solution was to create the gadgets in the order they needed to appear in the zones.

This was rather annoying, to say the least. Do people actually get this to work, or do they not worry about the order of the gadgets?

answered on 15 Sep 2009, 12:29 PM

Hi Barry,

When the RadDocks are created dynamically they have to be recreated in the Page_Init method on every post-back. If you are re-creating them in the Page_Init (you mention that the docks are created in the Page_PreRender, but never mention when in the page lifecycle they are recreated) everything should be working fine and every RadDock should be placed in the respective zone at the respective index (position).

If you still have problems even if the docks are re-created in the Page_Init method, please send us a running project where this problem can be observed, and we will do our best to provide a working solution.

Best wishes,
Pero
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 15 Sep 2009, 04:13 PM

Hello Pero,

I'm actually not doing postbacks, so there should be no issue related to recreating the docks on a postback.

What I have done is to place the docks on the page during Page_PreRender. If they are moved around, a light-weight Ajax call updates the database with the dockstates. Next time the page is loaded (directly, and not via a postback), it uses that information to place the gadgets. They show up in the proper zones, but they don't show up in the proper order within the zones. I've done a lot of debugging to make sure the proper values are being preserved and applied, and I can assure you that they are.

To work around this, I added a column in the docks/gadgets database to store just the index so that I change the sequence in which the docks are actually added to the page by using an Order By clause in the SQL. This works.

To clarify via example:

I have 4 dock zones called DockZone1, DockZone2, DockZone3, and DockZone4.

I attempt to place docks on the page by selecting them from the database and adding them to their respective zones. For simplicity, I will only reference gadgets for DockZone1. If I retrieve gadgets from the database in the following order (showing their name and partial DockState only):

"Gadget 1", {"DockZoneID":"DockZone1","Index":"0"}
"Gadget 2", {"DockZoneID":"DockZone1","Index":"2"}
"Gadget 3", {"DockZoneID":"DockZone1","Index":1"}

they appear in the correct zone, but in the order: Gadget 1, Gadget 2, Gadget 3.

My workaround reads the same data from the database and executes the exact same code. The only change is the order in which the records are read from the database, and hence the sequence in which the gadgets are added to the page. Now I read in the order:

"Gadget 1", {"DockZoneID":"DockZone1","Index":"0"}
"Gadget 3", {"DockZoneID":"DockZone1","Index":1"}
"Gadget 2", {"DockZoneID":"DockZone1","Index":"2"}

By doing this, the gadgets are appear in the correct zone and order: Gadget 1, Gadget 3, Gadget 2.

When I place a gadget on the page, I perform the following tasks in order:

Create a new Dock.
Create a new DockState.
Deserialize the DockState data and store it in the DockState object.
Set Forbidden Zones for the Dock.
Set the Dock Commands.
Add the Dock to the DockLayout Controls collection.
Use ApplyState to apply the DockState to the Dock.
Dock the Dock in the appropriate DockZone.
Set the Index on the Dock directly from the value in the DockState.
Set the DockMode of the Dock to Docked.
Set the Title of the Dock.
Set the UniqueName of the Dock.
Set the ID of the Dock.
Add the User Control that contains my gadget functionality to the Dock's ContentContainer Controls collection.

If this is done in Page_PreRender, and we're not doing any postbacks, shouldn't the docks appear in the DockZones in the correct order according to the Index? Again, I've done a lot of debugging to make sure the correct data is being used in the Docks and DockStates. In fact, when I set the Dock's title, I set it to the DockZone ID and Index. The values displayed were correct, but the order within the zones were not.

I have to stress. There is no postback involved here.

Thanks.
--Barry

answered on 17 Sep 2009, 02:51 PM

saveraddockindb.zip

Hello Barry,

I understand that you are not doing any postback, but what if the ajax request (call) affects the RadDocks that are placed in a certain AjaxPanel (or an UpdatePanel), then they would not be recreated when the ajax call has finished and practically would not be rendered on the page. So it does not really matter if it is a full page postback or an ajax call if the control is affected by the page update.

The indices (indexes) and the positions of the RadDocks are applied in the LoadDockLayout event handler, after all of the RadDocks are created and are on the page. You can see that if you comment the code that is executed in the "RadDockLayout1_LoadDockLayout" event handler method (in the attached project), the indexes will not be applied correctly.

Please test the project and let me know if you have any problems or questions.

Sincerely yours,
Pero
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 17 Sep 2009, 03:11 PM

Hello Pero,

I should have been more clear. I'm also not using any AjaxPanels or UpdatePanels of any sort. All Ajax calls are via Javascript calls directly to web services, so there are no partial page postbacks at all.

Are you saying that if I have a page where the docks are created in Page_PreRender, I cannot expect the index values to be applied at all because they are only applied in the LoadDockLayout event handler? (That seems to be the case, as that is what I'm observing.)

If that's the case, then I understand the restriction as unfortunate as it is. After all, I have a workaround.

For the benefit of all, the reason I'm doing this as I am is that I have decided to abandon partial page postbacks. All of my ajax calls are via JavaScript calls to PageMethods and Web Services. I do this because I benefit from a pretty good performance boost through faster response times and less network traffic. It comes at the cost of a longer and more complex development time, but I'm up for the challenge.

Given this, I could create the docks earlier in the page lifecycle (i.e., in Page_Init), but it would take making changes to several layers of inherited objects that I would do only if I really needed to. As it is, if the page loads in such a way that the portal view isn't visible (such as when the user requests a configuration view), I don't even have to waste the time and resources building the gadgets.

If you can confirm the answer to my question above, I would appreciate it.

Thanks.
--Barry

answered on 21 Sep 2009, 03:16 PM

Hello Barry,

Yes, the index values are applied in the LoadDockLayout server side event handler method only. This event receives a parameter of type Telerik.Web.UI.DockLayoutEventArgs, that contains the Positions and Indices properties through which the index values and the positions of the RadDocks are applied.

Please note that this is so, because the RadDock's should be (re)created dynamically in the OnInit method so that the server side events (like [On]Command, [On]DockPositionChanged) are fired correctly and the ViewState of the RadDock's is loaded and persisted properly.

Best wishes,
Pero
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

Product Bundles

DevCraft

Web

Mobile

Document Management

Desktop

Reporting & Mocking

Automated Testing

CMS

UI/UX Tools

Debugging

Free Tools

Support and Learning

Productivity and Design Tools

Index of DockState not persisting

37 Answers, 1 is accepted