Browse positon cursor on the last record

questions
1

I have a browse procedure with range limits acting as a lookup to select a record from a file. By default, the first (topmost) entry is selected when the procedure is called. How can I position cursor on the last record when opening the procedure?

Currently I have this code

 OF EVENT:OpenWindow
    PRESSKEY(EndKey)

but that is not a very elegant solution.

2

If you are using ABC, you might get a smoother effect if you use:

  YourBrowse.TakeScroll(Event:ScrollBottom)

It’s been a while since I’ve used ABC, but I think that’s the one.

3

Or it should work in ABC or Legacy to Post the Scroll Bottom Event to the Browse’s LIST Control FEQ e.g. ?Browse:1

POST(Event:ScrollBottom, ?Browse:1)
1 Like
4

Thanks for your quick replies.
I’m using ABC, here is my code at the end of ThisWindow.Init just before “RETURN ReturnValue”

      IF ThisWindow.Request=SelectRecord THEN
         ?MessageString{PROP:Text}='Select record and press this button --> '
         ?MessageString{PROP:FontStyle}=FONT:bold
         SELECT(?Tab:2)
         PRESSKEY(EndKey)      ! This code works, cursor is posittioned at the bottom 
         POST(Event:ScrollBottom, ?Browse:1) ! This code also works, cursor is posittioned at the bottom 
    !! BRW1.TakeScroll(Event:ScrollBottom)  ! This code compiles, but desn't move the cursor
      ELSE
         ?MessageString{PROP:Text}=''
      END

Posting event to my browse control does the trick and is probably safer than calling PRESSKEY which posts the same event but only provided that ?Browse:1 is selected. However it still posts an event to the browse making it move the cursor from top to bottom. I was hoping there is a property I could set to change the initial cursor position when browse opens.

5

If you know the last record and it’s currently fetched, you can set YourBrowse.StartAtCurrent = TRUE after the Init() .

But since you’re using a range (and maybe a special filter), you might not know the exact record. Maybe try my suggestion. It is faster than posting the event.

6

PRESSKEY is usually a bad idea, I try to never use it. If its a Ctrl+Key that can cause a stuck down Ctrl, same for Alt+.

If a Browse is called with Request for Select Record I think the normal behavior should be to locate to any record currently picked. E.g. if my Customer has Salesman “Willy Loman” picked previously then when the […] button is clicked the Select Salesman Browse should locate to “Willy Loman”. In ABBrowse .SetSort() you will see the code that executes when .StartAtCurrent=True also executes when .Selecting=True i.e. Select Record.

What I suggest is you only Scroll Bottom if the record is blank or zero.

      IF ThisWindow.Request=SelectRecord THEN
         ?MessageString{PROP:Text}='Select record and press this button --> '
         ?MessageString{PROP:FontStyle}=FONT:bold
         SELECT(?Tab:2)
         IF Pre:UniqueCode = 0 THEN   !record active calling Browse is Zero so Nada
            POST(Event:ScrollBottom, ?Browse:1) !scroll to Last
         ELSE
             !Browse Class will locate to current record
         END

So I typed all this, but it may not apply to your situation.

7

Please tell me in which place it is optimal to make an insert: YourBrowse.TakeScroll(Event:ScrollBottom) ?

OF EVENT:OpenWindow 
     YourBrowse.TakeScroll(Event:ScrollBottom)

? Thanks ! :slight_smile:

8

I think somewhere in OpenWindow should be OK.

Sometimes, if you wish to minimize the flickery stuff that can happen when a busy window opens, you can hide the window after it opens, then unhide it in EVENT:OpenWindow. But that can get tricky sometimes.

9

Curious, might you explain the technical term tricky?

10

Thank you. That’s how we work. I was hoping that it was possible to move the list positioning from the ACCEPT loop to the ABC methods of the class.

11

It might be possible, but my memory of ABC is a bit sketchy, so I’m not sure the point at which you can count on the browse being fully inited and filled.

12

It’s the replacement term for whatever profanity you need to use at the time. I’ve had situations where code in certain classes/templates responded to the visibility of certain controls, etc.
Stuff happens.

13

Thanks for clarifying. It will be included in my technical vocabulary. A bit more concise than “never sufficiently cursed.” I had thought that you were stating the setting of PROP:Hide on the window itself was tricky.