Hello, all.
I have a perplexing question regarding the RadDock's state properties and JSON. I'm building an application that has a custom dashboard that will allow the users to add, remove, move, and expand/collapse various .ascx controls; this string will be stored in a SQL database. As it stands right now, everything works the way it should with no issues.
Since there will be a large amount of users using the application, it was decided that we don't need to physically store every dock state property for all the docks since there are quite a few that can't be changed from a user perspective (docks will never be pinned or resized; the top and left will always be 0, etc.) so we created another table that holds the properties that are changeable (zone, title, etc.). I changed the SaveDockLayout's handler to save into both tables until I get this new method working and tested. One table is storing the whole string as per the Telerik demos, the other is taking only the state properties we're saving and inserting/updating/deleting from the database as needed. So far, this has worked perfectly.
Since we're not storing the whole string as one database field anymore, we're creating a JSON string on the fly in a stored procedure that's loading from the new table. The values that don't change are hard-coded into the procedure; the others are selected from the database per our criteria. The results are then output to a JSON-formatted string and then looped through and split as per the code examples. Docks loaded this way have all the states from the JSON string applied correctly and they render fine.
Here's the hitch. When the SaveDockLayout event fires when the docks have been loaded with the generated string instead of the stored one, the table that's storing the whole dock state is updating the properties just fine, yet the part of the subroutine that's breaking apart the states doesn't seem to recognize that anything has changed. For example, if I move a dock from zone 1 to zone 3, the whole dock state is updated correctly in the old table, yet the property going into the new table will still show zone 1. The same results occur if the title is changed, if the dock is expanded or closed, etc.
So my question is, is there a fundamental difference between storing the whole state string vs. generating one? I've done a side-by-side comparison of the JSON output of my generated string to the text of the stored string and there's no noticeable difference. Both strings are created as NVARCHAR(MAX). All the properties are paired correctly and in the same order. Each dock is surrounded by opening and closing braces, the docks are separated by a pipe delimiter, each name/value pair has quotes around each part with a colon in between the name and value, plus there's a comma separating each pair. Is there something else I'm missing that would cause the properties to be updated correctly for one procedure but not the other?
I have a perplexing question regarding the RadDock's state properties and JSON. I'm building an application that has a custom dashboard that will allow the users to add, remove, move, and expand/collapse various .ascx controls; this string will be stored in a SQL database. As it stands right now, everything works the way it should with no issues.
Since there will be a large amount of users using the application, it was decided that we don't need to physically store every dock state property for all the docks since there are quite a few that can't be changed from a user perspective (docks will never be pinned or resized; the top and left will always be 0, etc.) so we created another table that holds the properties that are changeable (zone, title, etc.). I changed the SaveDockLayout's handler to save into both tables until I get this new method working and tested. One table is storing the whole string as per the Telerik demos, the other is taking only the state properties we're saving and inserting/updating/deleting from the database as needed. So far, this has worked perfectly.
Since we're not storing the whole string as one database field anymore, we're creating a JSON string on the fly in a stored procedure that's loading from the new table. The values that don't change are hard-coded into the procedure; the others are selected from the database per our criteria. The results are then output to a JSON-formatted string and then looped through and split as per the code examples. Docks loaded this way have all the states from the JSON string applied correctly and they render fine.
Here's the hitch. When the SaveDockLayout event fires when the docks have been loaded with the generated string instead of the stored one, the table that's storing the whole dock state is updating the properties just fine, yet the part of the subroutine that's breaking apart the states doesn't seem to recognize that anything has changed. For example, if I move a dock from zone 1 to zone 3, the whole dock state is updated correctly in the old table, yet the property going into the new table will still show zone 1. The same results occur if the title is changed, if the dock is expanded or closed, etc.
So my question is, is there a fundamental difference between storing the whole state string vs. generating one? I've done a side-by-side comparison of the JSON output of my generated string to the text of the stored string and there's no noticeable difference. Both strings are created as NVARCHAR(MAX). All the properties are paired correctly and in the same order. Each dock is surrounded by opening and closing braces, the docks are separated by a pipe delimiter, each name/value pair has quotes around each part with a colon in between the name and value, plus there's a comma separating each pair. Is there something else I'm missing that would cause the properties to be updated correctly for one procedure but not the other?