List skip one row

[ajenat]

Hello..
In VFP9, if we press downarrow just when/before creating the list box, the second item is skipped and third item is selected.
SET TALK OFF
clear
DIMENSION myarray(6)
myarray(1)='Ashwani Khurana'
myarray(2)='Aditya Pasricha'
myarray(3)='Arjuna Panday'
myarray(4)='Dalip Kumar'
myarray(5)='Komaljit Kaur'
myarray(6)='Naresh Gupta'
STORE 1 TO my1list,my2list
@2,2 SAY 'my1list'
@2,36 say'my2list'
@15,1 say'Press <TAB> and <DownArrow> as quickly as you can to minimise delay between them.'
@3,1 get my1list from myarray
READ
@16,1 say'In my2list Selection will reach at 3rd item instead of 2nd.'
@3,35 get my2list from myarray
READ time 1
IF my2list=3
@17,1 say'See you press downarrow once but 2nd item skipped.' colo RGB(255,0,0,255,255,255)
else
@17,1 say'Oops, try again.' colo RGB(255,0,0,255,255,255)
ENDIF
* Behaviour remains same in Forms.

 

[TamarGranor]

If you're working in Visual FoxPro, not FoxPro 2.6 or earlier, then don't use @Say/@Get. Use forms.

Tamar

 

[ajenat]

you are right. but same thing happens in Forms and Listbox control.

 

[Mike Lewis]

same thing happens in Forms and Listbox control

Can you be more precise? How are you setting up the listbox? What exactly is going wrong?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mJindrova]

The code works right in VFP 9 SP2.


MartinaJ

 

[Mike Lewis]

The code works right in VFP 9 SP2.

I agree. Most of the time, the code works as expected.

But it is possible to reproduce the problem. If you "Press <TAB> and <DownArrow> as quickly as you can" when in the first listbox, focus moves to the second listbox, and the the third item will indeed be selected. By it's not clear why you want to do that. If you use a different key to exit the first READ (such as <RightArrow>), it seems to work OK.

In fact, the whole interface looks a bit weird, especially the way that the second listbox only becomes visible when you exit the first. I'd also suggest removing the timeout on the second READ, which doesn't appear to serve any purpose and only confuses the issue.

My advice would be to abandon the whole thing and to switch to using Listbox controls. You say you have done that and it still doesn't work. If you could provide the information we need to reproduce the problem, we might be able to see what's wrong.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ajenat]

Please check screen recorded video (of 13 seconds) I have uploaded. I have clicked DownArrow ONCE just after Tab but pointer moved to third item instead of second.
[URL unfurl="true"]https://res.cloudinary.com/engineering-com/video/upload/v1666859417/tips/screen_srz2br.mp4[/url]

 

[Mike Lewis]

Please check screen recorded video I have uploaded.

Sorry,but I don't have the time or patience to download and play a video. Instead, please address the points already made, especially regarding using VFP-style controls rather than @/SAY and READ. If the problem exists with VFP controls, please post some code that will enable us to reproduce the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ajenat]

I have also tried this code in VFP9 SP2 but result is same.

oLstForm=Createobject('FORM1')
oLstForm.list1.AddItem('Ashwani Khurana')
oLstForm.list1.AddItem('Aditya Pasricha')
oLstForm.list1.AddItem('Arjuna Panday')
oLstForm.list1.AddItem('Dalip Kumar')
oLstForm.list1.AddItem('Komaljit Kaur')
oLstForm.list1.AddItem('Naresh Gupta')
oLstForm.list2.AddItem('Ashwani Khurana')
oLstForm.list2.AddItem('Aditya Pasricha')
oLstForm.list2.AddItem('Arjuna Panday')
oLstForm.list2.AddItem('Dalip Kumar')
oLstForm.list2.AddItem('Komaljit Kaur')
oLstForm.list2.AddItem('Naresh Gupta')
oLstForm.list1.Value=1
oLstForm.list1.SetFocus
Read Events

Define Class form1 As Form
Height=285
Width=450
Add Object list1 As ListBox With HEIGHT=204, LEFT=17, TOP=8, WIDTH=150
Add Object list2 As ListBox With HEIGHT=204, LEFT=200, TOP=8, WIDTH=150
Procedure Load
This.Visible=.T.
Endproc
Procedure unLoad
CANCEL
Endproc
Enddefine

 

[Mike Lewis]

That's better.

I can now reproduce the behaviour you are seeing - but only some of the time. Most of the time, it works as expected, but it sometimes does what you described. I can't see any pattern.

Certainly, if you pause for, say, half a second between the two keys, it always works OK. Also if you use a different key to move between the listboxes; also if you use the mouse.

Sorry I can't suggest a solution. I don't remember ever seeing this before. Maybe someone else can help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mJindrova]

Hmm, this weird behavior can disable [tt]CLEAR TYPEAHEAD[/tt] after first [tt]READ[/tt] command.

mJindrova

 

[ajenat]

Hmm, this weird behavior can disable CLEAR TYPEAHEAD after first READ command.

I already tried it.. but no difference.

 

[ajenat]

if you pause for, say, half a second between the two keys, it always works OK

You are right, but we can't tell that to operator.

Sorry I can't suggest a solution. I don't remember ever seeing this before. Maybe someone else can help.

Thanks Mike Lewis for your time. Maybe someone else can help..

One more thing I want to add that same thing also happens in Menu created in VFP.

 

[Chris Miller]

It's hard to produce at all.
I added

Procedure List2.InteractiveChange()
   Activate Screen
   ?? '.'
EndProc

And even in the case the downarrow skips down two items instead of one, there only is one interactivechange event happening.
That explains why CLEAR TYPEAHEAD does not do anything, but it does not explain why the listbox sometimes skips down 2 items with one downarrow keypress.

I can't see what's the reason behind this. You would have to dig down very deep with analysis what happens and is the difference between the normal skip 1 and the skip 2 cases.
I see a possible workaround if you introduce a property lastvalue. In Interactivechange check if lastkey() is downarrow and value is more than lastvalue+1 and then adjust it to lastvalue+1.

Chriss

 

[Chris Miller]

using the tag property of a listbox, you can use this self correction mechanism:

Procedure List2.ProgrammaticChange()
   This.Tag = Transform(This.Listindex)
EndProc

Procedure List2.InteractiveChange()
   If Lastkey()=24
      If This.Listindex>Val(This.Tag)+1
         This.Listindex = Val(This.Tag)+1
         Set Message To '++++ Skip correction ++++'
      Else
         Set Message To 'Listitem skipped 1 (all is good)'
      EndIf
   EndIf 
   This.Tag = Transform(This.Listindex)
EndProc

It'll only act in case of Downarrow usage (Lastkey()=24). The change back to the previous item is visible, ie you see the selection skip down 2 first, then skip back 1.
But no idea what causes this.

Chriss

 

[Mike Lewis]

To be honest, if I was in your shoes, Ajenat, I would be tempted to ignore it. It's frustrating not to be able to get to the root of the problem, but it's not a particularly destructive error. It only happens in very specific cases; it should be obvious to the user that it has happened; and it should be easy to recover from. I would try to live with it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ajenat]

In fact, the whole interface looks a bit weird, especially the way that the second listbox only becomes visible when you exit the first.

In my opening example I used <TAB> button to reach list box control which behaved weird. But it doesn’t matter how we reach to that control it'll behave like that.
This weird behaviour of Listbox can be seen when <UpArrow> or <DownArrow> is pressed just before/when the control is being activated, no matter how we reach to that control.

 

[ajenat]

To be honest, if I was in your shoes, Ajenat, I would be tempted to ignore it. It's frustrating not to be able to get to the root of the problem, but it's not a particularly destructive error. It only happens in very specific cases; it should be obvious to the user that it has happened; and it should be easy to recover from. I would try to live with it.

I am migrating an accounting software from FPD to VFP. Almost every window/screen uses List control (@Get).

In an accounting software List box is the only and easiest way to present long data. We also use it to ask selection from huge list of options.

While working with an accounting software, when hundreds of entries are being entered, the user never read each option again&again. He just operate speedily while reading documents and expects selection/actions according to buttons pressed.

That’s why we can’t ignore it but need it to work properly.

 

[Chris Miller]

Do you realize my sample using the InteractiveChange event solves your problem?

Chriss

 

[Chris Miller]

By the way, you also have new ways of picking from a list, by using the autocomplete feature of a textbox, but as Tamar said initially, by all means move from @et to VFP forms and controls with their events you can program, to have most everything about behavior in your hand.

Chriss