Steve,
Here is another question/problem I am having.
Say you have editable grid and you click on a cell causing keyboard to come up, while keyboard is up keep clicking on MANY other cells to get them into edit mode.
Dismiss the keyboard and you will see that number of rows/scrolling area of the grid increased in proportion to number of cells you clicked causing keyboard to come up.
Is it a bug or there is something I need to do to handle this?
Thank you
Mark
Hey Mark,
I was able to reproduce it in our samples browser as well. Looks like a regression issue that slipped in.
I've made a fix for the issue already. It will be in the upcoming SR in the next couple of weeks. But if you need it sooner, let me know and we'll get you out a private build.
Thanks for reporting this, and also for the sample!
-SteveZ
Can you provide me please with SR (private build) fixing this issue. I have so many problems editing grid so perhaps they are all related to the scrolling issue.
So the way that you're using the DSH and ColumnDefinitions is a bit outside how they were supposed to be used.
Basically, the idea behind the DSH was a shortcut for binding an array of data to the grid. If your data was already organized in an array, you could assign to the the DSH, and you'd automatically get a grid. You could then tap into that a little more with ColumnDefinitions, as they allowed you to turn on and off features and control the appearance of whats displayed, in a structured way.
Obviously, everything done in the DSH could be done externally, as it was using the same API's that anyone else had access to.
However, since you're not binding an array of data to the grid, things get a little bit weird when using the DSH, as thats how it was designed to work.
If i were you, i'd approach this in one of the following ways.
1. If possible, i'd organize my data into an array. You could thus just give that data to the DSH, and you could write a LOT less code. Also, we would not need additional workaround and to re-implement methods, as everything would go down the correct code path.
2. If thats not possible, i would avoid using the DSH. Instead i'd basically write my own, specifically geared to what i need. The DSH does a lot, as it tries to incorporate all the features possible in the Grid. But thats not necessary if you know what features you need. Instead, i would create my own reusable version, that just did what i needed it to. I would also still try to keep structure. So i'd have my own version of a column, just for organization purposes. Basically, you don't want a ton of if stmts in the CreateCell method of your own DSH. Instead you want to break it out so that you're code is separated into nice clean chunks.
These are just my personal preferences, so feel free to ignore them, if you're content with the current implementation.
If you have any more questions about either of my suggestions, let me know, as i'd be happy to help out and point you in the right direction.
steve,
Thank you.
what would be the recommended way to create horizontal editable grids? Am I doing it right by using native base implementation for displayeditor?
Ok, so this is another case where because you're partially using part of the base classes methods, and partly not, you're getting odd results.
Basically, whats happening is RemoveEditor is getting called twice.
This is happening, b/c in DisplayEditor, you're using the base implementation, which hooks up some delegates to the UITextField, and sets a private field that says we're in edit mode. The problem is that when RemoveEditor is called, you do not call the base implementation, so basically the column still thinks you're in edit mode. When the text editor closes up, that editor's delegate says its finishing editing, and if the column is still in edit mode, it triggers an endEditing. Thus calling RemvoeEditor again. And now you've double unregistered the keyboard, so all state is lost. Which is causing the issue you're seeing.
So, if you want to continue using the native base implementation for DisplayEditor and not RemoveEditor, you can do that, but just make sure you use a flag, that you set in DisplayEditor and undo the flag in RemoveEditor, then only run the RemoveEditor if that flag is set.
Btw... i was not able to see the really long time to dismiss the keyboard. I tried the simulator and a device and it always closed up. The only issue i was seeing was the cells being displayed under the keyboard.
I got private build and have different scrolling issue.
1. run example2. click on a cell "13.5" - the keyboard comes up and the cell is scrolled above the keyboard. All good here.3. click on cell 12.4 (for example) - the cell is scrolled under the keyboard and I do pass to RemoveEditor TRUE in anotherCellEnteringEditMode field.
another problem1. click on 13.5 cell again2. remove the keyboard - somehow it takes really long time to dismiss the keyboard
Is there something I am not doing right?
Thank youMark