FiveTech Support Forums

Hi,

how can I define my own code blocks for some standard keys, e. g. K_RIGHT, , K_LEFT, K_DEL, or K_CTRL_DEL, in a xBrowse?

You can't use codeblocks, but you can try redefining them at the top of xbrowse.prg and compiling and linking it with your application. The downside is that you will have to update this with each new version of FWH.

I don't recommend redefining these keys as they are standards and your users will be confused by it, and probably not happy.

James

Don't know if you can trap left, right etc but you can do this:

oBrw:bKeydown := { | nKey | BrowseKeys(nKey) }

STATIC FUNCTION BrowseKeys(nKey)
IF nKey == VK_F3
ENDIF
RETURN NIL

Regards,

Pete

James,

thank you for the quick answer.

I agree with your opinion, regarding the standard navigation keys as follows: K_RIGHT, K_LEFT, K_UP, K_DOWN, K_PGUP, K_PGDN, K_HOME, K_END, ... So I will not redefine these keys.

But what about these keys: K_DEL, K_CTRL_DEL, K_INS, K_CTRL_INS, ... These keys were not trapped by 'oBrw:bKeyChar', though the have no function inside xBrowse! Why?

I also don't understand the reason why the keys K_CTRL_HOME and K_CTRL_END have the same function as K_HOME and K_END. I have a lot of browses with an active OrdScope() and hoped that I could use these keys to change the scope of the table to the first, respectively to the last range.

Frank,

My apologies for saying you couldn't use a codeblock, I had a brain fade and forgot about bKeydown.

Can I see the codeblock you have defined, and function you are using to trap the keys?

James

Frank,

Yes the two methods, KeyDown() and KeyChar(), do make it more confusing. Perhaps Antonio can explain why there are two? It is probably a Windows thing.

I don't think the "K_" values are necessary--they are either reduntant to the "VK_" values or not used (remember, unlike Harbour, in FW everything goes through the Window event handler. You may note that there are no "K_" values used in FW's own code.

I do agree it would be nice to have one codeblock that we could use to trap all keys (or, at least most keys, since Windows does not allow trapping of certain keys like F1, F10, etc.).

As an alternative interface idea, consider making a right-click pop-up menu with all your options on it. This is a Windows standard and users will automatically try this. Unless your users are expert users that use the program a lot, they will not remember the hot-keys. At the very least consider doing both. All hot-key options should also be on a menu anyway for less than expert users.

James

As an alternative interface idea, consider making a right-click pop-up menu with all your options on it. This is a Windows standard and users will automatically try this. Unless your users are expert users that use the program a lot, they will not remember the hot-keys. At the very least consider doing both. All hot-key options should also be on a menu anyway for less than expert users.

1. For ‘Normal’ hotkeys, e. g. ALT-A…Z, CTRL-A…Z, etc., only a menu item is necessary
2. Hotkeys which aren’t trapped by the menu, but by bKeyDown like K_DEL, K_CTRL_DEL, K_INS, K_CTRL_INS, ...,
3. Hotkeys which were trapped by bKeyDown after modifying ‘METHOD KeyDown()’, like K_RIGHT, K_LEFT, K_UP, K_DOWN, K_PGUP, K_PGDN, K_HOME, K_END, ... Example: For trapping K_CTRL_LEFT, modify the case condition to ‘nKey == VK_LEFT .AND. !GetKeyState( VK_CONTROL )’
4. For the key K_ESC and perhaps some others, the user defined function have to be placed directly in the method ‘METHOD KeyDown()’! This doesn’t work:, ‘oBrw:bKeyDown := { | nKey | IIf( nKey == VK_ESCAPE, oWnd2:End(), My_Keys( oBrw, nKey ) ) }’! One more difference compared with bKeyChar[/list:u]

When I create a menu for Child window, it automatically replaces main menu when Child window has focus. You can also have a toolbar on each window.

Gale,
thank you for the tip, which direct me in the right direction.