Bug in wxToolbar?? [2.8.2, winXP, VC2005]

[Yaron Tadmor]

> 
> YT> I ran into something that looks like a small conceptual bug in PC
port
> YT> of WX (perhaps this manifests in others as well).
> YT> The toolbar's tool ID's are noted as ints. On PC port these are
4-byte
> YT> integers.
> YT>
> YT> However, the PC implementation passes the ID in the WPARAM of the
> YT> windows message. This means the ID is cast to a 2-byte integer
which
> YT> causes it to be truncated.
> 
>  Indeed.
> 
> YT> If indeed this IS a bug I can think of several ways to solve it:
> YT> 1)	Change the API so it reflects the correct data size
> 
>  Unfortunately this won't be very helpful as C/C++ compilers happily
cast
> int to short implicitly anyhow.

I think you misunderstood me. What I meant is to change the API of
wxToolBar so for users of wxToolBar it's clear that the ID's are shorts
and not ints.

> 
> YT> 2)	Add asserts on PC to make sure the ID's are in the
correct
> YT> range.
> 
>  Yes, this is the only thing to do. There is already such assert in
> wxWindow::Create() so I guess it should be added to wxToolBarToolBase
ctor
> as well.
> 
> YT> 3)	Use a different parameter of the message to pass the
proper
> ID.
> 
>  This is impossible as the native controls themselves use WPARAM to
pass
>

To pass what? Your text was cut in the middle I think.
In any case the toolbar class can perform some kind of hashing from
4-bytes to 2-bytes for the windows system. What I mean is this:
1) When adding a tool the toolbar will allocate a 2-byte int for the
4-byte ID and keep it in a map.
2) When the button is pressed and the toolbar gets the event with the
2-byte ID, it will use it to look up the real 4-byte ID.

I think such a solution is quite easy to implement and will keep the
wxToolBar API which allows 4-byte ID's the real and proper API.

Yaron