FiveTech Support Forums

I don't know why, but ONLY ALT doens't work...

Try:
CTRL+ALT
SHIFT+ALT
CTRL+SHIFT+ALT

PS: I think that it doesn't work because the windows use it to MANY things, like "&Exit" in buttons, ALT+F4, etc...

I think Alt-C and Ctrl-Break key combinations were reserved for terminate application.
You might try SetCancel( .f. ) and then see if the set key command works.

seems to be another bug in FWH 11.12

frose wrote:seems to be another bug in FWH 11.12

The "special" keys: Ctrl, Shift and Alt, can't be intercepted using SetKey().

For Shift and Ctrl you can use:

GetKeyState( VK_SHIFT ) --> lYesOrNo

GetKeyState( VK_CONTROL ) --> lYesOrNo

Alt is a system key and usually gets routed through the Method SysCommand(). Windows uses Alt for some system actions, so its better not to use it. In some cases we can redefine a Method SysCommand() to trap the System Alt+Key that we need to intercept. In example, Windows uses Alt+F4 to close the app.

Non system used Alt+... combinations are usually reserved for menuitems actions, and hotkey accelerators.

frose wrote:Hi,

want to set a codeblock to the key 'ALT-C' with

Code (fw): Select all Collapse

SetKey( K_ALT_C, { || my_function() } )

but it doesn't work!
Any idea?

- worked in FWH 11.06[/list:u]

- doesn't work anymore in FWH 11.12[/list:u]
2 - SetCancel( .F. ):

- has no effect in FWH 11.06 Alt+C andCtrl+Break are still active[/list:u]

- in FWH 11.12 the Hotkey Alt+c ist active![/list:u]
Sample Code:
Code (fw): Select all Collapse

FUNCTION Main()

   LOCAL oDlg
   LOCAL oCheck1
   LOCAL oCheck2
   LOCAL lValue := .T.
   
   SetCancel( .F. )
   //SetKey( K_ALT_C, { || My_End() } )
   SetKey( 302, { || My_End() } )

   
   DEFINE DIALOG oDlg size 400, 400 TITLE "A Dialog Box"

   //@  1,  1 TO 5, 30 LABEL "&This is a LABEL for anything:" OF oDlg

   @  2,  2 CHECKBOX oCheck1 VAR lValue PROMPT "This is the first CHECKBOX" OF oDlg ;
      ON CHANGE SAA_Change_dCheck( oCheck1 )

   //@ 3, 3 CHECKBOX oCheck2 VAR lValue PROMPT "&ClickMe" SIZE 100, 20 OF oDlg ;
      
   @  3,  2 CHECKBOX oCheck2 PROMPT "This is  a second CHECKBOX" OF oDlg

   @  5,  4 BUTTON "&Confirm" OF oDlg SIZE 40, 12 ACTION oDlg:End()

   ACTIVATE DIALOG oDlg

RETURN NIL

FUNCTION SAA_Change_dCheck( oTCheckBox )
   oTCheckBox:SetCheck( .F. )
   oTCheckBox:SetText( "New Text" )
RETURN NIL

FUNCTION My_End()
   nMsgBox( "Here is 'My_End()'!", "My_End()" )
   QUIT
RETURN NIL




Antonio wrote: Try to implement a menuitem or a control with such accelerator and assign it an action


Ok, understand, the function 'My_End()' will not be executed out of a dialog via 'SetKey()' - BTW same behavior in Clipper/Console app -, have to implement something like:
Code (fw): Select all Collapse

   @  5,  4 BUTTON "&Confirm" OF oDlg SIZE 40, 12 ACTION My_End()


Still wishing that SetCancel() and SetKey() working in FWH as in Clipper

Frank,

SetCancel() is a Harbour (from Clipper) function. FiveWin has never used it, and if there has been some change with it, it may be because Harbour has change the way it implements it.

In which way have you been using it with FWH ? I mean, whats the desired effect that you expect using it ? To stop the user from pressing Alt+C ?

Traditionally Alt+C has been a console feature to stop a running process, thats why I can't see what meaning it has under Windows.

I appreciate your comments, thanks

Antonio,

yes, it's for stopping a (long or endless) running process without killing it via the task manager.

I want to switch it off with 'SetCancel( .F. )' and link the keys Alt+C, Ctrl+Break and Alt+F4 to the same controlled ending process (logfile, etc.) with the SetKey() function.

Alt+F4 is still implemented in the dialogs, so regardless if the app is in a waiting state or processing something, the user/developer can end the app by pressing one of these keys

My console app use it this way (Alt+C, Ctrl+Break and Alt+F4), so if I'm migrating to FWH the user expects the same or similar functionality!

Antonio,

if you don't want or can to implement it, I can live with it, but please don't change the behavior of FWH too often from one version to the other

Frank,

Thats for sure a Harbour/xHarbour issue. Only Harbour implements SetCancel() and just for console mode. Have you recently changed your Harbout version and then noticed these effects ?

Besides that, I have never seen a Windows app that process Alt+C as a console app. Anyhow, it is fully respectable if you want to keep offering it. I would not recommend it.

For many years we have done always our best to keep FiveWin backwards compatible and at the same time to offer more and more features and enhancements. We pay special attention to this as we understand that it is extremelly important for all of you that have large existing apps.

Please check when you changed your Harbour/xHarbour version. Surely thats where the problem comes from. If so, then we could see what have changed between your current used Harbour and the older one and try to provide you with some backwards compatibility issue. But again, I insist, this is a Harbour issue, not a FiveWin one, as we have never supported or interfere with console mode Alt+C behavior.

Antonio,

now I'm even more confused!
Do you mean, you have the same behavior with FHW 1107 and 1112, when trying my sample code?

frose wrote:Antonio,

now I'm even more confused!
Do you mean, you have the same behavior with FHW 1107 and 1112, when trying my sample code?

Antonio,

I'm still stucked with xHarbour.com as you can see in my signature, only replacing the folder c:\FWH.

Hoping you'll find the right way out of this ...