DataViewCtrl - AppendToggleColumn

The above doesn't allow to be editable and ignores the Alignment.

Even if not editable I think it should show in the same colour, i.e. not greyed out, i.e. like the Genre column.

Attached a modified demo file showing the problem.

Werner

DVC_DataViewModel.py (9.51 KB)

The above doesn't allow to be editable and ignores the Alignment.

It looks like the toggle renderer is using the dv.DATAVIEW_CELL_ACTIVATABLE mode to control whether it is enabled or not. This seems a little strange to me but the docs say that ACTIVATEABLE means that double-clicking on a cell makes something happen, and EDITABLE means that the data can be edited in-place. IMO a toggle control is a little of both, but whatever...

Please create a bug report about the alignment.

Even if not editable I think it should show in the same colour, i.e. not
greyed out, i.e. like the Genre column.

Attached a modified demo file showing the problem.

Re: AppendBitmapColumn

This one does not work at all and I don't get any traceback either.

Maybe/probably a problem with the code I did.

There are some problems with your sample code, but also bitmaps won't work at all until after my changes from the other day are rolled out.
I think that the toggle type should work with the current code however.

The issues with your sample code are:

* GetColumnCount is not reporting the correct number of data columns in the model, and you are adding more columns to the view than there are reported data columns.

* GetColumnType is returning "string" for all columns, but the toggle renderer is going to expect a "bool" type by default and the bitmap renderer (when it works) is going to want a "wxBitmap". Some variant types can auto-convert if needed, (such as a string "yes" to a bool True) but not all. In order to use string data for a toggle column I think you would have to create the renderer separately, passing "string" for the varianttype parameter, create a column object and assign the renderer to it, and then add the column object to the dvc. IOW, you won't be able to use the AppendToggleColumn convenience function.

* GetValue is still returning strings for all columns. See above.

* SetValue is not saving any changes for the toggle column.

I'm in the process of updating my sample to show how to use more than just strings, so it should be easier to figure out how to do things with the DVC then, and more of these wrapper issues you are discovering will be resolved before the release.

···

On 1/6/11 7:36 AM, werner wrote:

--
Robin Dunn
Software Craftsman

Hi Robin,

The above doesn't allow to be editable and ignores the Alignment.

It looks like the toggle renderer is using the dv.DATAVIEW_CELL_ACTIVATABLE mode to control whether it is enabled or not. This seems a little strange to me but the docs say that ACTIVATEABLE means that double-clicking on a cell makes something happen, and EDITABLE means that the data can be edited in-place. IMO a toggle control is a little of both, but whatever...

Please create a bug report about the alignment.

Done - 12852

Even if not editable I think it should show in the same colour, i.e. not
greyed out, i.e. like the Genre column.

Attached a modified demo file showing the problem.

Re: AppendBitmapColumn

This one does not work at all and I don't get any traceback either.

Maybe/probably a problem with the code I did.

There are some problems with your sample code, but also bitmaps won't work at all until after my changes from the other day are rolled out.
I think that the toggle type should work with the current code however.

And some are pretty stupid too:-[ .

The issues with your sample code are:

* GetColumnCount is not reporting the correct number of data columns in the model, and you are adding more columns to the view than there are reported data columns.

* GetColumnType is returning "string" for all columns, but the toggle renderer is going to expect a "bool" type by default and the bitmap renderer (when it works) is going to want a "wxBitmap". Some variant types can auto-convert if needed, (such as a string "yes" to a bool True) but not all. In order to use string data for a toggle column I think you would have to create the renderer separately, passing "string" for the varianttype parameter, create a column object and assign the renderer to it, and then add the column object to the dvc. IOW, you won't be able to use the AppendToggleColumn convenience function.

* GetValue is still returning strings for all columns. See above.

* SetValue is not saving any changes for the toggle column.

I'm in the process of updating my sample to show how to use more than just strings, so it should be easier to figure out how to do things with the DVC then, and more of these wrapper issues you are discovering will be resolved before the release.

Great, looking forward to the next release.

I am just trying to get a feel for it and see what I would be missing if I switch from ObjectListView to dv.

Should I keep reporting problems I find or should I just wait for the next release? Don't want to waste your time on chasing down my coding mistakes;-) .

Werner

···

On 07/01/2011 02:31, Robin Dunn wrote:

On 1/6/11 7:36 AM, werner wrote:

Go ahead and keep reporting them if you think it is something that won't be corrected by what we've already discussed. For any issues that are just cosmetic (or mostly) you can just create tickets for them as I probably won't have time to deal with them myself.

···

On 1/7/11 12:46 AM, werner wrote:

Hi Robin,

On 07/01/2011 02:31, Robin Dunn wrote:

I'm in the process of updating my sample to show how to use more than
just strings, so it should be easier to figure out how to do things
with the DVC then, and more of these wrapper issues you are
discovering will be resolved before the release.

Great, looking forward to the next release.

I am just trying to get a feel for it and see what I would be missing if
I switch from ObjectListView to dv.

Should I keep reporting problems I find or should I just wait for the
next release? Don't want to waste your time on chasing down my coding
mistakes;-) .

--
Robin Dunn
Software Craftsman