Difference between CellTypes

What difference does TypeEditable make from TypeNormal? What is the best of making a listbox not editable. I know you could just use self.SetFocus and then me.SetFocus, to take the focus to the window instead of the listbox and then set the focus back to the listbox but this may interfere other things, depending on how the code is written.



TypeEditable allows you to edit the individual cell when double clicking. TypeNormal does not allow for this behavior when double clicking the cell. We use TypeNormal if all we want to do is display data. SetFocus doesn’t really have any relevance as it applies to cell types.

I wish there was a way to extend the defined ListBox.CellTypes. I have an app with a ListBox that contains a column of dates. I would like to be able to do something like lb1.ColumnTypeAt(1) = ListBox.CellTypes.DateValue so that later I could query the column type the same way I can now for a Checkbox column.

@Dale Arends, For that you’d better just create you own array in the listbox subclass.

Use the Celltag to hold whatever, then create a subclass to access it any way you want… Specifically for dates you don’t even need the Celltag as Datevalues can be converted from and to strings

Normally that is what I would do, Karen, but the CellTag is already being utilized for the SQLDate so that I can sort the column correctly. Using CompareRows, I intercept the column by column number, which breaks if I have to rearrange the listbox. Being able to query the columntype for datevalues would alleviate that issue.

BTW if you really want to define cell types that way, you shook[quote=468911:@Dale Arends]Normally that is what I would do, Karen, but the CellTag is already being utilized for the SQLDate so that I can sort the column correctly (using CompareRows).[/quote]

I had to deal with used CellTags for my mergeable cell listbox design… This is one solution… I can think of others:

Create a new class called say MyCelltag
With these properties:
TypeEnuman as CellTypeEnum
CellTagValue as Variant
CustomTag as Variant

In your subclass override Overide Listbox.CellTag with getter and setter, create a CustomTag getter and setter, and And Celltype Getter and setter.

When any one of those is assigned, of it does not exist already have it create and and assign an instance of myCelltTag under the hood to the true listbox celltag and then assign whatever the right property of the instance… For getter teh other way around

That way you do not break any existing code using Celltags

And You van do:

If Listbox.CellType(row, col) = myCellTypes.Date Then the date = Listbox.CustomTag(row.Column).DateValue

Or if you want to be more specific instead of the Using CustomTag you can have the property and access method be specific to Date object and on assignment have it also write a date string to the cell directly as well as save teh date value…

Well there are a million various depending on how septic or general you want to be and how much generic functionality you want to add.

Do you see what I am getting at?


BTW if you don’t want create a celltag class you could just put an array of variants and have your code use the index for the “property” you want, and handle all datatype specific stuff in the code of the methods.

Just FYI, you could just put the sqldate in the Cell itself and you’d get the sorting for free. Then you just override the CellTextPaint event to have it draw the date the way you want it.

Karen, Greg, thanks. Both ideas are interesting. I’m going to spend a bit of time experimenting with them.

Greg’s solution is simpler , though you would still need a way to know if the cell holds a date if you want a general (and generalizable for other data types) solution for the subclass, not just for a specific column in a specific situation.

But for sorting usually the whole column is a single datatype… In that case you could use the ColumnTag to hold the data type and use Greg’s solution.

If you need the columnTag for other things you can use the principle I used for CellTags to still have ColumnTags variable for other uses.

If I am writing a listbox subclass that I intend to reuse in different situations, and I use cell, row or column tags in it, I tend to implement that mechanism so it does not limit things I may do with the subclass in the future … basically I like to keep the full Xojo API capabilities in the subclass for future use if possible. I do that with events I implement as well.

For a one off use I would not subclass at all as I would know which columns held dates upfront…

And after seeing Greg’s solution i would do that by implementing the CellTextPaint event as he suggested for those columns. (In the past I have stored the date instance in the CellTag and sorted by TotalSeconds.)

If you’re not mixing data types in a column why not just use the columntag to hold the column data type?

That’s what I wound up doing, combined with Greg’s suggestion, to give me the flexibility needed. I created an enum with the existing celltypes plus a few special values for columns like dates and others that may need special handling. I’ll use them in the ColumnTag when the listbox is created.