FiveTech Software tech support forums

Hi all,
This issue I have also posted on xHB NG, without any reply (yet)

I have noticed a strange behaviour of the ALT key if pressed alone on a dialog.
It is somehow related with the system menu (Move/Close) but then it is not pop up the system menu and still have to press SPACE key after the ALT key.
The strangest behaviour is that it makes all the TSBUTTONS in the dialog go bananas! They lose their colors and their bitmaps, and have to move the cursor over them one by one to make then reshow in normal color and redisplay their bitmaps.

I do not find this behaviour normal, and did not expect that ALT key alone would have any kind of effect, except for windows, where the menus are activated.

Any advise would be appreciated.

Kind regards to all
Evans

This is the normal ALT key behavior (check with other apps).

I don't use TSButtons and never see that strange effect on the FWH standard BtnBmp. That's why I think that it might be a bug of TSButtons.

EMG

EnricoMaria wrote:This is the normal ALT key behavior (check with other apps).

I don't use TSButtons and never see that strange effect on the FWH standard BtnBmp. That's why I think that it might be a bug of TSButtons.

EMG

It also happens to CLASS TDBtnBmp (dbutton)
Both SBUTTONs and DBUTTONs, are discolored in the dialogs
and lose their bitmaps...

Perhaps MANUEL MERCADO and SANTIAGO PEREZ MARQUEZ can help,
if the read this ...

Thanks anyway... I thought it only activated the system menu on windows, but you're right (again of course), it activates them on dialogs too.
The problem is the discoloring... and loss of the bitmaps...

You might need of an updated version of that third party buttons.

EMG

Evans,

Its fixed. Its a bug on the build that you are using. I email you the new files.

Please send to me also.
Thanks Mike.

Hello,

Listen - I'm getting a bit worried here!

There seems to be a great many message threads being started recently (since the February 2006 Build) which detail 'minor' bugs and 'fixes' for them.

I assume that all of these 'fixes' will be contained in the next release of FWH

I mean - I hope that I am not making changes to the FWH source (to incorporate these 'fixes' only to find that they have dissapeared after the installation of latest version of FWH

Regards,

Dale.

Dale,

> I assume that all of these 'fixes' will be contained in the next release of FWH

Yes

I am sorry to pick in , but have you read the thread regarding xbrowse , bpasteof and using vscroll barr to append ?

I am convinced that it is a bug , very easy to see with testxbrowse as described.

Frank

Frank,

We will review it asap,

Antonio Linares wrote:Evans,

Its fixed. Its a bug on the build that you are using. I email you the new files.

Antonio

I have the same bug with Tsbutton and ALT key and i use xhb commercial. What has to be changed ?

Richard

Evans:

In tsButton you must use de tsbutton.ch before Fivewin.ch and
in the resource declaration the button must be OwnerDraw.
The tsbutton.lib must be before the FWH´s libs.

Please taste and tell me if everything go ok.
Sorry for my Indian English.

Best regards

Ruben Fernandez.

Richard,

Basically this is the missing call:

Antonio Linares wrote:Richard,

Basically this is the missing call:

Code: Select all

METHOD HandleEvent( nMsg, nWParam, nLParam ) CLASS TButtonBmp

   local nResult

   do case
      case nMsg == WM_UPDATEUISTATE  // Buttons were erased when pressing ALT
           nResult = Super:HandleEvent( nMsg, nWParam, nLParam )       
           ::Refresh()
           return nResult
   endcase

return Super:HandleEvent( nMsg, nWParam, nLParam )           

Antonio,

Thank you

It works OK now

If anyone needs to change the tsbutton class, do not forget to add the following

#define WM_UPDATEUISTATE 0x0128

Richard

Antonio Linares wrote:Evans,

Its fixed. Its a bug on the build that you are using. I email you the new files.

Antonio
Thanks for the fix provided.
It works fine now.
Saludos,
Evans