WM_HELP not always working

[davidgraham]

I have the following code snippet in many dialogs - and most work and call Help.
When stop the code I find WM_HELP is decimal 83 (HEX 53)
In just a few cases WM_HELP is not working and Help is not being called.
I have added some code to see what key is being pressed and is says decimal 260/261,
HEX 104/105 - key up/key down (not HEX 53).
I'm not sure why in most cases it is working, but in a few it is not. Is there any other setting that is not causing it to work?

Another case where it is not working is from a sub menu - I'm not sure if I should be testing another constant.  
   

integer*4 function ChamfcProc(hwnd, message, wParam, lParam) 
 !**********************************************************
 !MS$ATTRIBUTES STDCALL, ALIAS : '_ChamfcProc@16' :: ChamfcProc

 write (c8,'(i7,A)') message,char(0)
 call display_prompt(c8)

    select case (message)
 case (WM_HELP)
  call help ! help not accessed??
   
    case (WM_INITDIALOG)
  ChamfcProc=1
  return

    case (WM_SHOWWINDOW)
  if (wParam) then
  endif
        ChamfcProc = 1
        return

 case (WM_MOVE)
  lret=GetWindowRect(hWnd,rectW)

 case (WM_MOUSEMOVE)
  call MouseMove (lparam,rectW)

[mecej4]

davidgraham wrote:
When stop the code I find WM_HELP is decimal 83 (HEX 53)

WM_HELP is a named constant (in WinUser.h of the Windows SDK) with the value 0x53. Unless something has gone seriously wrong, its value should never change. If you have seen its value being incorrect, the culprit could well be in the parts of the code that you have not shown.

davidgraham wrote:
In just a few cases WM_HELP is not working and Help is not being called.

It is hard to understand what you mean. As pointed out  above, WM_HELP is a named constant. What do you mean by saying that a <constant> is "not working"?

I do not see any Fortran-related issues based on the code snippet. If some Windows service routines are not working as expected, and you are satisfied that you are calling them with the proper protocol, you might consider asking your questions in a Windows GUI programming forum (e.g., MSDN).

[Les_Neilson]

After reading mecej4's reply and re-reading the original post the fault does not lie with WM_HELP "not working" but with the fact that "message" is being passed in with a value that is not == WM_HELP so the case test is skipped.

As you (davidgraham) say: message has the value x104 or x105 so the fault lies with whatever code is calling your ChamfcProc function

<edit> Again from re-reading the original, it is catching the "key-up" or "key-down" events but not the actual key being pressed </edit>

Les

[davidgraham]

Thanks for your feedback. I did not word the problem well.

In most dialogs when I press F1, the case (WM_HELP) is activated, but in a few cases when I press F1 it is not. Does anyone have any suggestion why it is not working.

[andrew_4619]

Indicates that the user pressed the F1 key. If a menu is active when F1 is pressed, WM_HELP is sent to the window associated with the menu; otherwise, WM_HELPis sent to the window that has the keyboard focus. If no window has the keyboard focus, WM_HELP is sent to the currently active window.

Maybe the message is not being sent to your dlgproc and is going elsewhere?

[IanH]

WM_HELP is generated in response to the processing of other messages (e.g. WM_KEYDOWN) by the default window procedure.  If you are intercepting those other messages, such that the default window procedure doesn't get to process them, then your window won't be sent WM_HELP.

How's that for a guess?

[davidgraham]

Thanks for the suggestions. I will copy a dialog routine that works and modify it to give it the same functionality that one that doesn't - hopefully that will solve the problem. 

[davidgraham]

I have been working on this.

F1 help works on all dialogs except 5.

I got one to work. I re-entered the dialog and when I press F1 the help appears. I could not see what was different.

I am working on the second dialog, I have re-entered the dialog it and gradually reinstating the code.

On case (WM_SHOWWINDOW), if I remove iret=EnableWindow(GetDlgItem(hWnd,IDC_NEWGRADEJOB),.FALSE.) then I can press F1 and the help is displayed, I do not remove the line and press F1 the help is not displayed.

I cannot see how changing just this one statement causes F1 Help to work or not.

[IanH]

Isolated snippets of code are impossible to debug.

I wildly speculate that the control that you are disabling has the focus at the time it is disabled, and therefore keyboard handling for that dialog ceases until you set the focus to another control.  https://blogs.msdn.microsoft.com/oldnewthing/20040804-00/?p=38243

Why are you disabling a control in response to the WM_SHOWWINDOW message?  Control enable/disable states in a dialog typically reflect the state of the data that the dialog is manipulating, not the visibility of the dialog window.

[davidgraham]

Sorry, it is part of a very large project and is difficult to show part of the program, but here is part.

I'm using EnableWindow & false to disable some of the fields. When I do it for IDC_NEWJOB when I press F1 the help is not displayed. If I remove that line then when I press F1 the help is displayed.
As far as I can see the same logic is used in all the other dialogs and 95% of them work.
I am creating the dialog using Resedit as I cannot edit them within VisualStudio (I don't know if this is causing a problem).   
   
     integer*4 function ChaHtProc1(hwnd, message, wParam, lParam) 
 !**********************************************************
 !MS$ATTRIBUTES STDCALL, ALIAS : '_ChaHtProc1@16' :: ChaHtProc1
 
    
    use grad_inc
        
 include 'resource.fd'
 
 ! omited other includes,common & local variables 

 ! Unreferenced variables
     lparam = lparam

    select case (message)
 case (WM_HELP)
  call help
  
    case (WM_INITDIALOG)
  ChaHtProc1=1
  return

    case (WM_SHOWWINDOW)
  if (wParam) then
             lret=GetWindowRect(hWnd,rectW)
   iret=ShowCursor(.TRUE.)
            
   Title='Change Multiple Feature Codes'c
   hDataList=GetDlgItem(hWnd,IDC_DATATABLE)
   hMapList=GetDlgItem(hWnd,IDC_MAPPING)
   iret=EnableWindow(GetDlgItem(hWnd,IDC_JOB),.FALSE.)
   iret=EnableWindow(GetDlgItem(hWnd,IDC_TITLE),.FALSE.)
   iret=EnableWindow(GetDlgItem(hWnd,IDC_DATATABLE),.FALSE.)
   iret=EnableWindow(GetDlgItem(hWnd,IDC_MAPPING),.FALSE.)
   iret=EnableWindow(GetDlgItem(hWnd,IDC_NEWJOB),.FALSE.) ! this stops help working
   !iret=EnableWindow(GetDlgItem(hWnd,IDOK),.FALSE.)
  endif
        ChaHtProc1 = 1
        return

 case (WM_MOVE)
  lret=GetWindowRect(hWnd,rectW)

 case (WM_MOUSEMOVE)
  call MouseMove (lparam,rectW)


    case (WM_COMMAND)                       ! message: received a command
  iCtrl=LoWord(wParam)
  select case (iCtrl)

  
  case (IDOK)    ! OK
   lret=EndDialog(hWnd,jchaht)
            ChaHtProc1 = 1

  case (IDCANCEL)  ! System menu close command?
            lret = EndDialog(hWnd,0)
            ChaHtProc1 = 1

  end select

 case default
  ChaHtProc1=0
 end select

 return

 end function ChaHtProc1