SOLVED: Question About Browse EVENT:ScrollDown and Alert Key

1

Hello Everyone,

I’m using this code when an alert key is pressed:

If ThisWindow.Run(1,ChangeRecord) = RequestCompleted
	IF BRW4::NoScrollDown
		BRW4::NoScrollDown = False
	ELSIF KEYCODE() <> MouseRight
		POST(EVENT:ScrollDown,?ListCostItems)
	END
End

The code does what I want in that the update form is called and the browse row moves to the next record. However, if I try to press the alert key again, the alert key event does not fire. I have to manually click on the browse to get the alert key event to fire.

I’m guessing perhaps there’s a browse reset or window method I need to call.

Thank you!!

2

Im guessing here but;

Assuming the Alert is tied to the vontril, not the Window, your problem is Focus.

When you return from the Form the List Control does not have focus. So pressing the key does nothing. Clicking on the control gives it focus.

You coukd either alert the key at the Window level, or add a SELECT to your code to set the focus on return from the form.

3

Thank you Bruce.

I’ve Tried SELECT(?ListCostItems,Choice(?ListCostItems)), after EVENT:ScrollDown, to no avail.

Basically, my client wants to iterate through the browse one row at a time with the ability to Alert(F2Key) along the way with F2 calling the update form.

4

Have you tried Alerting F2 at the Window level, not the Control level?

5

Yes sir. It’s been window level from the start.

6

I suspect you’re missing something - some detail you’ve overlooked. If the key is Alerted at the window level, then you’ll get the Event at the window level when the key is pressed. I suggest you chase that a bit to see who is “swallowing” it (likely via an Event:PreAlertKey)

7

A Sub class procedure would show that.

8

Yeah, move your alert key from the window to the browse.

In the embed for the browse alertkey place…

IF KEYCODE() = F2Key
  POST(Event:Accepted,?YourBrowseUpdateButton)
END

In the embed for immediately after the call to your update procedure, place…

ThisWindow.Run PROCEDURE(USHORT Number,BYTE Request)

ReturnValue          BYTE,AUTO

! Start of "WindowManager Method Data Section"
! [Priority 5000]

! End of "WindowManager Method Data Section"
  CODE
  ! Start of "WindowManager Method Executable Code Section"
  ! [Priority 2500]
  
  ! Parent Call
  ReturnValue = PARENT.Run(Number,Request)
  ! [Priority 6000]
  
  IF SELF.Request = ViewRecord
    ReturnValue = RequestCancelled                        
  ELSE
    GlobalRequest = Request
    UpdateStudents  ! YOUR update procedure
    ReturnValue = GlobalResponse
  END

! [Priority 8500]

IF Request = 2 AND ReturnValue = RequestCompleted
POST(EVENT:ScrollDown,?Browse:1) ! YOUR BROWSE LIST CONTROL
END

  ! End of "WindowManager Method Executable Code Section"
  RETURN ReturnValue
9

Rather than calling ThisWindow.Run(1,ChangeRecord) in the Alert Key Event I would try to run the Change button code so all the Browse refresh happens as normal. You just need a Local variable Flag. I’ll take some of Purple Edge’s code.

In the embed for the Alert Key Event:

IF KEYCODE() = F2Key   |
AND ~?ChangeButton{PROP:Disable} THEN   !if no records its Disabled
    MoveDownF2 = True
    POST(Event:Accepted,?ChangeButton)
END

In the Embed for the Change button after the Update check if the F2 Move Down flag is True and do your code. This way .Update() runs all the Browse Refresh code:

 OF ?ChangeButton
    ThisWindow.Update()  !<--- Generated
    ! [Priority 8500]
    IF MoveDownF2 = True THEN 
       MoveDownF2 = False
      ... your code to move down ...
    END

This will always Move Down even if the user cancels. I think that’s ok. If you want to prevent that then at the end of ThisWindow.Run() check for Cancel:

 IF Request = 2 AND ReturnValue <> RequestCompleted
    MoveDownF2 = False
 END

Another approach to consider is instead of using an Alert Key set the attribute KEY(F2Key) on the Change button. That will make F2 press the Change button where you can check for F2

 OF ?ChangeButton
    IF KEYCODE()=F2Key THEN MoveDownF2 = True.

    ThisWindow.Update()   !<--- Generated

    ! [Priority 8500]
    IF MoveDownF2 = True THEN 
       MoveDownF2 = False
      ... your code to move down ...
    END
1 Like
10

Solved!

This turned out to be a Noyantis DockingPanes issue.

So in the parent window that contains the DockingPanes OLE control,EVENT:GainFocus,I had to call this method:

DockingPane5.GainFocusChildWindow('ChildPaneID')

Then, in the window inside the docking pane,EVENT:GainFocus, I made a call to this Win32 API:

SetFocus(HWND hwnd), LONG, PROC, PASCAL, NAME('SetFocus')

with the focus being set on the browse.

1 Like