iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
We have a major problem that's cropped up and we need help as it's rendering our grids unusable. Our grids are customized with the first column always a check box. This is a Template column that hosts our own custom check box control. The issue I'm about to describe only occurs when the page is loaded without a post back. It works fine when it is a post back.
Each embedded check box has the generic ID of PrismCheckBoxRowChecker. The ClientID is something like ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewControl_ctl00_PrismCheckBoxRowChecker.
The problem upon loading the grid without a post back is that the ClientID portion that is serialized, i.e., ctl00, ctl01, ctl02, etc. is inconsistent and makes no sense. Some pages the initial page load would load fine and in order. But on other pages it may load in increments of 2 or 3 or 4 and so on which I don't understand. So the initial controls on the page may have the ctl00, ctl02, ctl04, ctl06, etc. which would be fine if it stayed consistent on post back. However, it does not.
On post back, it works correctly every time, i.e., the controls are serialized correctly as ctl00, ctl01, ctl02, etc. This creates a BIG problem because if the second row is checked and the page was rendered in, let's say, increments of 3, then the second control would be ctl03. On post back, however, this id represents the fourth control and would then render the selected item useless because it doesn't match. On some grids the initial load works just fine.
In the InstantiateIn method of our ITemplate control, the check box is created and added to the container.Controls collection. Below is an example of the container.Parent.Controls collection after the check box control is added via container.Controls.Add.
After the first Add, here's what's in the container.Parent.Controls:ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl00
After the second check box is added, here's what's there in addition to the line above:ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl00_PrismCheckBoxRowCheckerctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl01ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl01_ctl00ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl02
Why is this last control, ctl02, being added? I'm wondering if there's a bug in the underlying WebGridCellTemplateContainer code? This continues as the controls are added, i.e., after the third check box is added, the last controls is then:ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCtl_ctl04
Please help. Let me know what other information I can provide.
[EDIT] I did try a standard check box, i.e., System.Web.UI.WebControls.CheckBox and the behavior was the same by the way. Our templated class is this:
and it implements InstantiateIn as such:
Well, I have some good news. While I was preparing for recording the problem I found that it has been fixed in the latest update. I had run the Update Manager this morning and updated to the latest and whatever you guys did, fixed this issue.
The assigned IDs to the Template controls are now synced up correctly AFTER the grid rows are retrieved as in the code below:
foreach (ISNet.WebUI.WebGrid.WebGridRow row in oRows) { iRows++; ISNet.WebUI.WebGrid.WebGridCellTemplateContainer container = row.Cells[0].GetTemplateContainer(); PrismCheckBox cb = (PrismCheckBox)container.FindControl(PRISMConstants.PrismGridView.EmbeddedCheckBoxId); ...
So now the initial assigned ID to the Template control is retrieved correctly, e.g., the cb object in the above code reflects the assigned ID. So when the ids initially are 00, 03, 06, etc., then the Rows collection shows the cb.ClientID as 00, 03, 06 correctly rather than 00, 01, 02 incorrectly as it was doing earlier.
Now you can say it's resolved, but it was definitely a bug because it did not behave this way prior to the update I applied this morning.
I have a lead on this problem and it looks like a bug in the low level code. The increments are related to other Templated columns that are on the grid. In addition to our check box template column, we also use a Template column for our boolean columns so we can display our own check mark, e.g., isActive would show a check mark for 1 and nothing for 0.
If there are 3 Template columns, then the control is incremented for each one which is not good because it's not treated the same way on post back as initially described in the first post. I went to our boolean template and added an ID and you can see below:
ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl00ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl00_PrismCheckBoxRowCheckerctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl01ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl01_BoolColumnImagectl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl02
I can see the above happening if the control wasn't assigned an ID, however, in our case above, I would expect it to behave like this:
ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl00ctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl00_PrismCheckBoxRowCheckerctl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl00_BoolColumnImagectl00_ctl00_WebPaneManager1_ViewLeftSide_Content_View_PrismGridViewCarryingCost_ctl01
Hi,
If i am not mistaken, it is our WebGrid mechanism when you placed a control inside template. May i know about your scenario and why you need to use the ID? Maybe, i can figure out something to help you.
Regards,Handy
It's not so much what we do with the IDs, it's that they don't match against your row collection when retrieved from the grid. Our custom embedded check box uses LoadPostData to load it's checked/unchecked state. Here, it sets the server-side Checked and SElectedKeyValue properties from the hidden fields containing their respective values that are posted back in the postCollection. This part is handeled just fine even if the IDs are not in sequential order.
The problem occurs when we retrieve the rows from the grid after the data is posted back from an initial page load where the IDs were not in sequence. We call oGrid.RootTable.Rows to get the rows collection. We then iterate through it and get the check box control and check it's Checked property. The problem is, when we find the row with Checked as true, the data for that row does NOT match what the user selected.
The Rows collection contains the rows in sequence rather than what they actually were assigned on the initial load of the page. So if the page loaded with two Template columns, the check box would be assinged ctl00, ctl02, ctl04, etc. If the user selects the check box in the 3rd row (ctl04), then the Rows collection would return the data for row 5 since ctl04 would be for control 5 if the controls were created sequentially.
You can easily duplicate this from all the info I've given you. I've been able to do this with your grid with a simple check box.
I have a workaround in place for now but would prefer this work correctly since the workaround creates more overhead.
Yousif,
The ControlID is managed internally by ASP.NET Framework code, which is beyond the Grid's processing. However, if you can send us a working sample that reproduce the issue, we'll be happy to help you investigating the issue. And possibly make a fix on it if we can find a solid solution to the issue.
Thank you.
I've provided very detailed info in that you can easily create your own sample. It should take you 5-10 minutes to duplicate this.
Based on TemplatedCell sample (included in WebGrid C# samples), the ControlID numbering worked fine in both first load and postback. The sample used two templated cells, and if you notice, the ID is consistently incremented based on the cell-to-row order.
As told earlier, the internal ID is maintaned automatically by ASP.NET, and the numbering sequence relies on when the template is actually created and added to the page collection. In this case, the templates are created on all cells in a row first, then the next row.
Thus, it's clear that this issue wasn't a bug, unless there's scenario where the ID is generated inconsistently.
Based on TemplatedCell sample (included in WebGrid C# samples), the ControlID numbering worked fine in both first load and postback. The sample used two templated cells, and if you notice, the ID is consistently incremented based on the cell-to-row order. As told earlier, the internal ID is maintaned automatically by ASP.NET, and the numbering sequence relies on when the template is actually created and added to the page collection. In this case, the templates are created on all cells in a row first, then the next row. Thus, it's clear that this issue wasn't a bug, unless there's scenario where the ID is generated inconsistently.
The problem is not resolved, and I'm still able to reproduce the inconsistent numbering issue.
[Edited 10/26 per EULA, please respond politely and be constructive.]
Don't respond in a condescending manner and you'll get a polite response. It's very frustrating on this end when you do not respond with helpful information aside from "well it works in our samples then it must be not be a bug" type of answer.
We're running into real life usage of your product that are producing problems that are difficult to get over and we need your help. So please try to understand my frustration with that type of response. Thanks.
Yousif, I understand your point that you desire the numbering to be same within a row context. However, that is not the way how the template works. I believe the detailed information on how the template works is beyond our scope here -- the bottomline is, each cell has its own templated container, and thus each cell has its own ID, in such case, the ID is automatically generated by ASP.NET. Eg, ctl00 represents the container for CellA, while ctl01 represents the container for CellB.
That said, your desire to have the same controlID for both CellA and CellB is simply not possible (referring to your first post) because as we understand how the template works thus far, each cell requires its own unique template container, and thus automatically resulting in different ID when rendered by ASP.NET.
As such, I don't see where the inconsistent problem is, since the ID is properly incremented based on row-to-cell ordering. Again, the ID increment process has been discussed above and I hope you've understood it completely.
Let me know if you have any questions or other feedback. Thank you.
PS: If you're able to come up with a sample that shows the inconsistency issue which is based on the correct understanding on template process described above, please send over the sample and we'll be glad to investigate it for you.
You obviously do not understand what I have described in detail. I NEVER said I wanted the same conrol ID or numbering for anything. I just want the dang thing to work consistently like I've already described in detail.
I made a point of stating the difference between when the page first renders and when it post back. Please reread my detailed information slowly and get an understanding of the problem. Your response obviously shows that you still do not understand the issue and I have no more to add to it than I already have.
I'll see about recording a flash video of the issue being debugged since explaining seems to be too complicated.
Flash videos would be great! Looking forward to it, thanks.
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname
Creating your account...