Is there a way to determine whether the START-SEARCH event o

Posted by Admin on 19-Jul-2011 14:13

Is there a way to determine whether the START-SEARCH event of a browse has been triggered by a keyboard or a mouse event?

Here is why I ask:

With a standard browse, if the user puts focus into the browse and then hits "C" on their keyboard, the browse by its default behavoir repositions to the first row that has data starting with the letter C. If they hit "C" again, it repositions to the next row that has data staring with the letter C, and so on.

In our application, we've defined code for the START-SEARCH event of the browse to run a procedure to resort the temp-table/query that holds the data for the browse. So when a user clicks on Column Heading 1, the browse gets resorted by that Column. Very basically, the code looks something like this:

ON START-SEARCH OF br-generic IN FRAME {&FRAME-NAME} DO:
       
   APPLY 'END-SEARCH' TO br-generic.

   RUN resort-browse-procedure.
  
END.

The problem is that this code effectively disables the default browse behavior of alphabetic repositioning when the user types in a letter on their keyboard. What I am trying to accomplish is to be able to run the code in the START-SEARCH event when that event has been raised by a mouse event (so that the browse resort procedure gets fired off), but skip all of the code in the START-SEARCH event when the event has been raised by a keyboard event (so that the alphabetical repositioning happens instead).

I initially tried capturing this by defining an ANY-KEY event and then redefining the START-SEARCH code like this:

ON ANY-KEY OF br-generic IN FRAME {&FRAME-NAME} DO:

    /*code to assign a global variable to identify that the keyboard has just been pressed...*/
    ASSIGN browse-search-by-keyboard = YES.
   
    APPLY "START-SEARCH" TO BROWSE br-generic.
   

END.


ON START-SEARCH OF br-generic IN FRAME {&FRAME-NAME} DO:
       
   IF browse-search-by-keyboard = NO THEN
   DO:
       APPLY 'END-SEARCH' TO br-generic.

       RUN resort-browse-procedure.
   END.
  
   ASSIGN browse-search-by-keyboard = NO.
  
END.

However, by defining the ANY-KEY event it seems to disable the browse's ability to alphabetically reposition itself. Any help would be appreciated.

All Replies

Posted by Admin on 19-Jul-2011 14:27

One clarification:

Defining the ANY-KEY event disables the browse's alphabetic repositioning behavior. In addition to that, if at any point "END-SEARCH" is applied to the browser that will also disable the alphabetic repositioning.

Posted by Admin on 20-Jul-2011 01:58

In the DataDigger, I have to trap whether the user did a right-mouse click to access the context menu or pressed SHIFT-F10. This is because I trap the exact position of the mouse when the user right clicks. Obviously, this does not make sense when she presses SHIFT-F10.

I solved it by using this inside the trigger code:

if last-event:label = 'SHIFT-F10' then .....

I must admit that I used it in the MENU-DROP trigger

Posted by Admin on 20-Jul-2011 06:40

Thanks, I never knew you could use LAST-EVENT like that. That gets me significantly closer to what I'm trying to accomplish. I've removed the code for the ANY-KEY event, and now just have this:

ON START-SEARCH OF br-generic IN FRAME {&FRAME-NAME} DO:
       
   IF INDEX(LAST-EVENT:LABEL,"Mouse") > 0 THEN
        DO:


             APPLY 'END-SEARCH' TO br-generic.

            RUN resort-browse-procedure.

     END.  

  

END.

However, I still have the problem that once an "END-SEARCH" event has been applied, the browse no longer seems to recognize keyboard events as a trigger to start the alphabetic repositioning. I've checked the ALLOW-COLUMN-SEARCHING property after the fact and it remains set to YES, so I'm not sure what else I need to do to get the browse to start firing off the alpha repositioning again.

Posted by Admin on 20-Jul-2011 07:31

I think ultimately my best solution is to just remove the APPLY 'END-SEARCH' from the code altogether.

Posted by Admin on 20-Jul-2011 07:32

Use LAST-EVENT:LABEL to see what caused the event to fire off.

This thread is closed