Hello,
I have 16.1.20161.1000. I can not reproduce the scenario on my side, but my client constantly reproduces.
UC:
1. Filter column by pasting value from excel on the ultragrid in the filter row.
2. Leave the grid and open other screen.
3. Back to the grid and paste value from excel again.
Issue: After doing this repeatedly filter row/cell is disabled.
I wrote additional logs on the events BeforeRowFilterChanged/AfterRowFilterChanged.After the problem was reproduced again for client - we noticed that ActiveCell is null.
Do you happen to know if any similar issue with disabling the row when repeatedly pasting the value into the filter row?
Hi Paul,
I've never heard of an issue like that. And I can't imagine any way in which any user action (like pasting) would somehow disable anything in the grid. The only way to disable a row, cell, or column in the grid is via code - there is no UI in the grid where the user can disable anything.
My best guess here is that there's some place in your code where you are disabling... whatever object is getting disabled and that code is getting hit unexpectedly for some reason.
What, exactly, is getting disabled? Just the filter row? Is it the entire row?
Is there anything special about the cell being pasting into? Is it an unusual data type?
Is this user selecting the cell and pasting? Or entering edit mode, selecting text in the cell, and then pasting?
It might give us a clue if the user could provide a video so I could see it for myself, but frankly, I doubt it would help all that much.
>> Just the filter row? Is it the entire row?
The entire rows, meaning all rows in the grid are disabled to paste anythingUser had to close the screen or is taking a break and when he is getting back it is unfrozen again. The quicker decision is to close the screen and open it again. It is not frozen after.The more user is doing this the quicker it is getting frozen.
>> Is there anything special about the cell being pasting into? Is it an unusual data type?It doesn't seem so. This is just an excel values ( number)
>>Is this user selecting the cell and pasting? Or entering edit mode, selecting text in the cell, and then pasting?We will ask user
So it eventually re-enables if you wait long enough? That's really strange.
Are the rows visually disabled? In other words, is rows turning gray? Or is it just that the grid is unresponsive?
If there's a visual change and you can see that the rows are disabled, then that has to be something in the code doing that. If it's just unresponsive, then some process must be going on that is CPU intensive. The latter would make more sense, but that doesn't explain why it only happens on the user's machine and not on yours.
How many rows are in the grid?
And this ONLY happens when pasting into the grid from Excel and only the second time? What if you paste from Notepad?
Hi
>>Are the rows visually disabled? In other words, is rows turning gray? Or is it just that the grid is unresponsive?No, no visible changes, it just don't want to paste anything
>>How many rows are in the grid?It was selected about 6 rows at that moment
>>And this ONLY happens when pasting into the grid from Excel and only the second time? What if you paste from Notepad?it is not only the second time, it can happen 3rd time or more, not stable. The more you are doing this repeatedly - more chances it reproduces per user's words.We will ask about copying from the notepad.
>>So it eventually re-enables if you wait long enough? That's really strange.Yes, he had a break about 20-30 mins and when coming back it was enabled.
Well, that's all very strange. I've never heard of anything like that.
At this point, my only guess is that you have code in some event of the grid that is getting triggered when the user edits the filter cell. This could be the Before/AfterRowFilterChanged event, CellChange, or any other event that fires when you edit a filter cell. And that code is initiating some process that is locking up the application - I am assuming the whole application is locked up and not just the grid. If it's just the grid and the rest of the application is responsive, then that would be really unusual.
The only other possibility I can think of is that the user's machine just has some kind of file corruption or general problem with the DotNet framework or the application itself. If that's the case, it will be impossible to track down and you would have to resort to trying things like uninstalling and re-installing the application, the DotNetFramework, or the O/S.