Tbutton:click() and button ID

[Taavi]

Hello,
got a strange problem here with latest FWH (maybe all 32-bit) builds.

Seems like when creating button (tbutton) from resource with ID 1 it behaves like button having Default push button style. i.e. FWH generates tbutton:click() message when ENTER is pressed in dialog (also, when some other button is click-ed on some child dialog)

Call stack for this click looks like this:

....TBUTTON:CLICK0 TBUTTON:HANDLEEVENT0 _FWH0 WINRUN0 TMDIFRAME:ACTIVATE0 ...

Just changing button ID in resource file (from 1 to 1000 for example) seems to fix this problem but we have a lot of dialogs to fix...

Does this make any sense? Is resource ID 1 somehow different from ID 1000 for FWH event generation system? And can we disable this click()?
Nobody is clicking on this button at that time...

Taavi.

[ukoenig]

Hello,

With ID no 1 it is true.
As a sample, you use it for the exit-button, a return
inside of a get field will jump to this button.
You have to use a different ID-No, not 1.

To change it, just open the resource ( RC ) with a text-editor
and replace ID No. 1 with a different number.

Regards

Uwe

[Taavi]

Hello,
strange, this behavior did'nt show up with 16-bit FW: we use the same dialogs also in 16-bit with no problems. Maybe because we had to modify FW classes to get what we need at the beginning times of FW.

Is the ID "1" the only ID with predefined purpose? I never actually cared about the ID values I used in RC files...


Thanks
Taavi.

Hello,

With ID no 1 it is true.
As a sample, you use it for the exit-button, a return
inside of a get field will jump to this button.
You have to use a different ID-No, not 1.

Uwe

[ukoenig]

Hello,

It is just ID - No. 1

Regards

Uwe

[Antonio Linares]

Taavi,

> Is the ID "1" the only ID with predefined purpose?

1 is equivalent for IDOK and 2 for IDCANCEL.

You have to change those values if you don't want to use those predefined behaviors.