Event handling using tags

[steved]

I've added an option to widgets to assign a 'tag' value (as is done in Delphi) which can greatly simplify event handling - overall it may well save both RAM and code space in some applications - no need to do lots of comparisons with widget pointers.

For example, a keypad can assign tags which convert readily to ASCII characters, permitting use of generic decoding routines.

The notes in the attached files give an example.

Very simple addition.

event_handling_using_tags.zip

[inmarket]

I will integrate this over the next few days. Thanks.

[inmarket]

This has been integrated into the repository.

I have changed the names a little to be more consistent with other uGFX names and added support for returning the tag in each widget that create events.

Thanks for this, it has been a good addition.

[Joel Bodenmann]

I took a look and I see one potential problem: The gwinGetTag() routine returns the tag of the widget or 0 if it is not a widget. However, it is completely valid to set the tag of a widget to 0. I think that this behavior should be changed.

~ Tectu

[inmarket]

Getting round this behaviour is difficult and relies on "error" values. It is easier to assume that 0 is that error value. It correspond nicely to an default initialised init structure. As the user sets tag values there is no reason that zero is any worse an error value than any other and there are a number of implemtation reasons why it makes a good one in this situation.

[Joel Bodenmann]

Probably we could just typedef the widget tag type so it is a signed value and we can use -1 for an invalid widget (so the user can check for < 0) and use the positive values including zero as the real tag values?

Otherwise I'll just note that down in the documentation very very carefully.

~ Tectu

[steved]

I took a look and I see one potential problem: The gwinGetTag() routine returns the tag of the widget or 0 if it is not a widget. However, it is completely valid to set the tag of a widget to 0. I think that this behavior should be changed.

~ Tectu

I took the view that we don't care where the tag comes from; our only concern is that if it's non-zero we process it, and carry out some action determined by the tag's value. So zero for 'do nothing' is convenient.

[inmarket]

If using consecutive tag values starting from 1, 0 as the do nothing case works well as the compiler should generate a switch jump table where 0 is the first element of that table thus leading to the most efficient code (no table offsets to add by the compiler).

[Joel Bodenmann]

I know that this starts to get unrelated but in my opinion the efficiency of the error branch (0 returned) is far from important as the expected behavior should be that in 99.9999% of the cases a proper tag is returned.

~ Tectu