Wt

Hey Vincenzo,

The documentation for CheckStateRole says: data for this role should be a bool. When the Wt::ItemIsTristate flag is set for the item, data for this role should be of type Wt::CheckState.

In case the item is not checkable, then data will be empty (boost::any()).

Regards,
koen

Understood. As I am trying to study better the documentation, would please point me to where that piece of information is?
I'd like to post more interesting questions with answers other than "RTFM"! :-)

Hey Vincenzo,

http://www.webtoolkit.eu/wt/doc/reference/html/group__modelview.html#gga0ae864e12320f9f89172735e075ed068aad55e3ad8d7b76279adfc160bcb74940

Regards,
koen

Undesrtood.
Now I'me gettin this runtime error:

"boost::bad_any_cast: failed conversion using boost::any_cast"

boost::any_cast<bool>( data( r,0,CheckStateRole ) )

Things are getty weirder ...

fprintf( stderr,"typeinfo:%s\n",headerData( fp,o,CheckStateRole ).type().name() )

typeinfo:v

Don't mind my previous remark, as typeid( 3.14).name() returns "d" and there seems to be a major issue with my environment.

Okay.

[enzo@feynman:~/w]$ c++filt -t v
void
[enzo@feynman:~/w]$ c++filt -t d
double

All the checkbox that have never been checked ot set by software have type any(), that is void.
As soon as they get checked or set by software they get the proper type.
I'm not sure whether this is a feature or a bug, though, as I would say that a tristate checkbox should have type Wt::CheckState while a normal
checkbos should be bool, despite it's been set or not. IMHO.

A few details for the sake of completeness and to link to my other post.
In the method connected to the headerDataChanged() you need to filter out all the events to "untyped" headers as soon as possible.
Something like this:

 if( headerData( col,or,CheckStateRole ).type() == typeid( (void) 0) )
    return;

  if( item->row() < 0 || item->column() < 0 )
    return;

In the method connected to the headerDataChanged() you need to filter out all the events to "untyped" headers as soon as possible. Something like this:

 if( headerData( col,or,CheckStateRole ).type() == typeid( (void) 0) )
    return;

Or check for headerData(col, or, CheckStateRole).empty().

But, in this case, I believe that rather then doing this, you should set proper initial CheckStateRole data in your model yourself, since the view widgets will be looking for it anyway.

In the method connected to the itemChanged() you need to filter out all the events to the root item as soon as possible. Something like this:

  if( item->row() < 0 || item->column() < 0 )
    return;

Or rather: !item->isValid() -- the fact that row and column are -1 for an invalid (root) index is not documented.

Just curious, were these the only checks you needed to avoid the improper behaviour, or did you also have to make sure that you do not try to update other checkboxes when this was not needed ?

Regards,
koen

In the method connected to the headerDataChanged() you need to filter out all the events to "untyped" headers as soon as possible. Something like this:

 if( headerData( col,or,CheckStateRole ).type() == typeid( (void) 0) )
    return;

Or check for headerData(col, or, CheckStateRole).empty().

But, in this case, I believe that rather then doing this, you should set proper initial CheckStateRole data in your model yourself, since the view widgets will be looking for it anyway.

In the method connected to the itemChanged() you need to filter out all the events to the root item as soon as possible. Something like this:

  if( item->row() < 0 || item->column() < 0 )
    return;

Or rather: !item->isValid() -- the fact that row and column are -1 for an invalid (root) index is not documented.

Just curious, were these the only checks you needed to avoid the improper behaviour, or did you also have to make sure that you do not try to update other checkboxes when this was not needed ?

Regards,
koen

Koen Deforche wrote:

But, in this case, I believe that rather then doing this, you should set proper initial CheckStateRole data in your model yourself, since the view widgets will be looking for it anyway.

Already tried. It didn't help out.

Just curious, were these the only checks you needed to avoid the improper behaviour, or did you also have to make sure that you do not try to update other checkboxes when this was not needed ?

I followed your great suggestion to oly update those items that needed an update.
This avoids the loopback.

Is it normal for invalid items to trigger signals or is it a bug?

Hey Vincenzo,

Okay, I believe we can fix Wt to not indicate a data change if the data hasn't effectively changed, avoiding the loop altogether.
You should indeed not get a signal for an invalid item. If you have any hint on how I could reproduce that, I would appreciate it.

Regards,
koen

Koen Deforche wrote:

Or rather: !item->isValid() -- the fact that row and column are -1 for an invalid (root) index is not documented.

bool WStandardItem::isValid() method doesn't exist!
isValid() method is only found in:
Wt::WAbstractItemView::isValid()
Wt::WDate::isValid()
Wt::WDateTime::isValid()
Wt::WModelIndex::isValid()
Wt::WTime::isValid()

Koen Deforche wrote:

You should indeed not get a signal for an invalid item. If you have any hint on how I could reproduce that, I would appreciate it.

That seems to be a mistake of mine, but still have to figure out where the problem is.
The attached code is a test rewritten from scratch. And the issue with invalid items is not there.

Hey Vincenzo,

I intended to check WModelIndex::isValid() indeed.
If you are using a WStandardItemModel, then the only item that can be 'invalid' is the invisibleRootItem().

Regards,
koen

I've sorted out the strange behavior with invalid items in the model.
This happens when you connect the event handler before filling the model.
What I presume is that while defining a model item for the very first time the handler is fired before (of course?) the item itself is filled in.
In my attached code fragment the connect() is called only after the model is filled in (defined, actually).
In my production code, instead, the constructor of a class (embedding both a WTableView and a WStandardItemModel) was doing an "early" connect to the event handler (as there was no way to know later that the model was filled in) thus finding non-existent items in place.
Forcing a delay in the call of the connect solved the problem with the invalid model items.
The same happens for headers.

Now, is it correct that the event handler is fired during the call to model->setItem()?

I'd say "no" (1st guess) because it's the application that's changing (or better, defining) the item, not the user.
I'd say "it depends" (2nd guess) because it'd be the programmer's duty to ask whether application generated events will fire event handlers.

Hey Vincenzo,

Got it! Indeed, there seemed to be an unnecessary call to itemChanged() when a new item was being added.

Regards,
koen

Koen Deforche wrote:

Hey Vincenzo,

Got it! Indeed, there seemed to be an unnecessary call to itemChanged() when a new item was being added.

This again links to my discussion about "programmatic" and "UI" events.