When I'm already in edit mode of a cell and I move the mouse to the outer edges of the cell right at the spot where the cursor changes from "I" to a regular mouse pointer (mouse is right on top of the border of the cell being edited) and I click down it triggers the Before/After commit events and then goes right back to RequestEdit event and puts the cell back into edit mode.

I did not notice this behavior in iGrid 2.55 and it's causing some issues with how I am implementing some things within the iGrid control using version 4.6. Specifically with my custom dropdown. What I am doing is creating my own dropdown list with AutoComplete as I did not like the inherit behavior available. Now when a user clicks in-between the cell and the dropdown control (right on the border of the cell being edited) it commits that change and then goes back to RequestEdit. At worse it was causing the listbox to go away and then redraw itself, which I have fixed by using a global variable but was wondering if this was a known bug and was going to be fixed in some later version?

Can you prepare and send us a sample that demonstrates this issue?

Should be attached. I also included an image (Sample Image.png) within the zip that describes the issue.

I analyzed this issue. To edit the text of a cell, we place a textbox control over its text and activate it. To finish the editing (one of the several ways), you can click anywhere outside of this textbox control. This allows the user to finish editing by clicking outside of the cell text, which is good in the case when the cell contains other parts - such as cell image. When the user clicks the cell image, the editing is finished. Clicking the cell's horizontal grid line at the bottom is also the case.

However, according to another iGrid rule related to the editing process, the grid should activate editing if the selected cell is clicked. That explains why the cell is put into edit mode again. But as you wrote, this is not a correct behavior and may cause side effects and problems.

I agree with you. But looking at all this, we should pose the following question: what actions and related events should be done/raised in this scenario? What is your opinion?

It's not too much of a problem for me anymore as I coded around the situation. I do understand how it could go out of edit mode because a textbox is being used that all makes sense.

I tried a few possible solutions on my end but kept on hitting a road block or the solution was getting too clunky which could lead to other bugs. The biggest problem is in the order the events are fired. The Before/After Commit edit events are triggered before any mouse-click events. This makes it difficult to determine what cause the initial request to go out of Edit Mode in the cell and triggered the Before Commit Edit event. It could happen to be a mouse click or the user hit a certain key on the keyboard. You would have to account for all the possible ways to get out of a cell edit mode and determine if it was a mouse click event. Once that is determined you would have to not raise the Before/After/Request Edit events if the mouse click happen to be for the same cell that was just in edit mode. As that mouse click would exit out of edit mode, fire the events and go back into edit mode. Instead it could still ext out of edit mode, DO NOT FIRE EVENTS, go back into edit mode.

Without going into the source code and only trying to do this with the inherited events available with the iGrid control, this was not really possible, or at least not without some clunky solution.


So my answer would be to NOT raise the events at all since it will go right back into edit mode of the cell, but determining when NOT to raise the events and when to raise them can get sloppy if not being careful.

Even if you coded a workaround, I'd like to enhance the component's logic to avoid such issues in the future. Are you ready to discuss this problem more and help me to build the proper solution if it is possible? However, I think, it would be better if we continue this dialog in email correspondence.

This makes it difficult to determine what cause the initial request to go out of Edit Mode in the cell and triggered the Before Commit Edit event.

The internal validation logic we raise the BeforeCommitEdit event from is based on the standard .NET Validating event for the textbox. It is raised in all situations when the user tries to leave the textbox control (pressing TAB, clicking the grid or another form control, etc). In this case we raise the BeforeCommitEdit event and set e.Cancel to True if BeforeCommitEdit returns 'proceed'.

This works fine but does not allow us (you) to distinguish whether the user used the mouse to finish editing, or pressed a key, etc. But do you think we really need this? Perhaps, a better option is to just finish editing if the user clicks outside the textbox - even within the rectangle of the current cell. The user intended to finish editing by clicking outside of the edit box, that's all.

Yes we can take this conversation off to email. Just send me an initial email of the approach you want to take and I'll work with you on a solution.

How can I prevent/disable edit mode for some columns?
I'v some columns with DropDownList and want to edit theirs but others dont.
If I set ReadOnly mode for grid in that case DropDownList do not appear.

How can I prevent/disable edit mode for some columns?
I'v some columns with DropDownList and want to edit theirs but others dont.
If I set ReadOnly mode for grid in that case DropDownList do not appear.

I do this by catching "RequestEdit" event and check if column need to be edited or not.
If not then set iGRequestEditEventArgs.DoDefault to false