I think I get it, and that seems like a good approach. Our approach is
a little different, but they definitely overlap in what they
accomplish:
On 5/10/05, bhaq1972 <[EMAIL PROTECTED]> wrote:
> I had a universal cellrenderer based on Ali's combobox cellrenderer
> with more controls.... but it was so sluggish to render.
Exactly! This was the main thing we were trying to get around with our
implementation (which I refer to as "delayed cell renderer
instantiation"). As you probably know, the reason the basic cell
renderers are so sluggish to render is because every control is
created when the grid is created. So, if you have a grid with 20
cells, each containing a ComboBox, 20 ComboBoxes are being created
when the grid is created. This is in contrast to the behavior when
*not* using custom cell renderers, where 20 Labels are created when
the grid is created, and a single TextInput is created when a cell is
focused. So, why not mimic this behavior and create 20 Labels and
create a single ComboBox when a cell is focused? Of course, this is
what both of our approaches do, but in different ways.
We did this by extending the cell renderer API to include a few extra
hooks in our cell renderers: focusInCell() and focusOutCell(). These
two functions are called by our subclass of the DataGrid in
setFocusedCell() and disposeEditor(), respectivly. The crazy part is
that some of the other hooks we needed in our cell renderers are
already built-in to DataGrid (albeit undocumented). I'm speaking
specifically of the isCellEditor boolean and the getValue() function.
By setting this boolean to true and implementing the getValue()
function, our cell renderers work perfectly with the editCell()
function of the DataGrid, so we don't have to do any extra work there.
We've used this approach with both a ComboBox cell renderer and a
DataField cell renderer, and it works well and definitely speeds up
load time. There are still a few little oddities. The ComboBox
dropdown issue was one, although unlike your problem, we couldn't
actually "see" the dropdown, but it was there, and it was goofing
things up if you clicked where the drop down was. With our DateField
cell renderer, we had an issue with hitTest not recognizing when the
DateField was expanded. Also, there is a issue if you "refocus" a cell
too rapidly (which is why their is a delay built into setFocusedCell()
in our WGDataGrid)
> With the cellrenderer approach (which is absolutely fine) you cant
> really pass any extra parameters like editable=false|true.
>
> So what i do instead is i add these extra parameters as extra
> attributes to my extended datagridcolumn (Dirk Eismann uses this
> idea) eg
I like the idea of passing parameters to the cell renderer via column
attributes ... currently we just use different cell renderers extended
from a common base class, if different attributes are required.
> i also add
> cellEditor.addEventListener("focusOut"), "change" etc....so i do
> some validation on the data the user enters.
>
> Now, because myCombo, myTextInput all have a <mx:Validator> tag, i
> can get that lovely red box+error message (as long as i remain
> focused on the cellEditor)
This is something that I am interested in: Is it possible for you to
provide an example? Including some validation (at least with
TextInput) is something I'd like to do. In the little bit I've played
around with it, it seems that getting the validation message to show
up properly (just around the focused cell and not around the whole
grid) is a real pain ... this would definitely be useful in the
columns which represent required field.
Well, it's cool to hear how someone else approached a similar problem! Thanks!
Jim
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
