xBrowse standard keys

[frose]

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?

[James Bott]

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

[PeterHarmes]

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

[frose]

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.

[James Bott]

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

[frose]

Hello Peter, hello James

doesn't know until now that there are two different methods, bKeyChar and bKeyDown, to catch key strokes, thank you Peter.

Fortunately bKeyDown trap the keys K_DEL, K_CTRL_DEL, K_INS, K_CTRL_INS, ..., so my function can react on them.

One more difference is the value of <nKey> in bKeyDown, so I have to fix my function as follows:

Code: Select all  Expand view

STATIC FUNCTION My_Keys( oBrw, nKey )

   IF nKey >= 97 .AND. nKey <= 122
      nKey := Asc( Upper( Chr( nKey ) ) )
   ENDIF
   
   IF nKey == K_CTRL_F .OR. nKey == Asc( Upper( "F" ) )
      //
      // Filter setzen
      //
      IF GetKeyState( VK_CONTROL )
         My_Filter_FiveWin( oBrw )
      ENDIF
   ELSEIF nKey == K_CTRL_RETURN .OR. nKey == VK_RETURN
      //
      // Edit all marked records
      //
      IF GetKeyState( VK_CONTROL )
         My_Edit_Dialogbox_FiveWin( oBrw )
      ENDIF
   ELSEIF nKey == K_CTRL_S
      //
      // Toggle security flag
      //
      Toggle_Schutz()
   ELSEIF nKey == K_DEL .OR. nKey == VK_DELETE
      //
      // Delete records
      //
      IF GetKeyState( VK_CONTROL )
         MsgInfo( "The function for the key 'Strg-Entf' (K_CTRL_DEL) is not yet implemented!" )
      ELSE
         MsgInfo( "The function for the key 'Entf' (K_DEL) is not yet implemented!" ) )
      ENDIF
   ELSEIF nKey == K_INS .OR. nKey == VK_INSERT
    //
    // Insert
    //
      IF GetKeyState( VK_CONTROL )
         MsgInfo( "The function for the key 'Strg-Einfg' (K_CTRL_INS) is not yet implemented!" )
      ELSE
         MsgInfo( "The function for the key 'Einfg' (K_INS) is not yet implemented!" )
      ENDIF
   ELSEIF nKey == VK_CONTROL .OR. nKey == VK_RETURN
    //
    // Do nothing
    //
   ELSE
       //MsgInfo( "The function for the key '" + AllTrim( Str( nKey ) ) + "' is not yet implemented!" )
   ENDIF
RETURN nKey

Maybe there are some more differences?

If I still want to change the functionality for K_CTRL_HOME, K_CTRL_END and perhaps other standard keys, I have to change the 'METHOD KeyDown( nKey, nFlags ) CLASS TXBrowse' in xbrowse.prg. I've just tried it and it works.

Of course, a better solution is to change the xBrowse class, having user defined codeblocks for all keys

[James Bott]

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

[frose]

Hello James,

you wrote:

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.

Yes, I totally agree upon. So all functions will be – in any case – in the menu of the application, special functions are reachable via toolbar and/or right-click pop-up menu!

Cause it is an MDI app, only with one main menu – not a separate menu/toolbar for each module, I have to adjust the menu/toolbar when the user switch between already opened windows or open new ones.

Although I don’t want to discuss the pros and cons of SDI/MDI apps anymore, I appreciate to get some more tips or ‘best practices’ to manage the above described scenario from you or other forum members.

Meanwhile I have analyzed key trapping in an active xBrowse/bKeyDown in more detail and find out that I have to handle keys in four different ways:

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

[Gale FORd]

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.

[frose]

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