It is not easy to work up a simple AnyScreen combo control test because so much depends upon the supporting class. Therefore, I offer a simple description of what I see in desktop vs AnyScreen. I will file this as a PTSS, but I have 0% confidence based on past actions that SV will respond.
**Procedure
Two combo controls.
Selection made in first resets choices available in second (typical parent/child).
**Desktop
a) Enter a single character; combo1 auto fills & displays first selection.
b) Hit Tab to select and move to combo2 control.
c) Combo2 has been reset with correct child values and is ready for entry.
**AnyScreen
a) Enter a single character; combo1 auto fills (after short delay) & displays first selection.
b) Hit Tab to select and move to combo2 control.
c) Combo2 has NOT been reset and has no child values.
AnyScreen continues to fail in my book with V11.1.13742. Attached is a test app that only needs to be compiled with shipping templates. To test in desktop vs AnyScreen:
- Enter D in first combo (it will autofill)
- Tab to second combo
- Enter D in second combo (will autofill on desktop, queue is empty w/ AnyScreen)
AnyScreenSchool.zip (45.7 KB)
Well I’m honoured to be included in such a student list 
But you’re right the behaviour is different in the latest 13742 Build.
Do you want me to post this on the AnyScreen newsgroup?
Glad you are so honoured.
I have continued to add to my PTSS, but one never knows when/if it actually gets noticed.
So yes, put it on the AnyScreen newsgroup.
My guess is that AnyScreen does not process some events as expected. Could be a problem for more than the combo example.
Thank you.
Posted on the AnyScreen newsgroup.
It’s being discussed with Marko Golem at the moment.
Having a bit of trouble convincing him of the different behaviour.
In my post I mistakenly identified you as Don Ridley - Jeff Slarve noticed the error and it’s sorted out now - apologies.
Very much appreciated. The fact that the second combo does not reset the queue after a tab from the first combo indicates to me a problem with EVENT:Accepted.
Hi Douglas,
Response from Marko Golem
The field when autocompletes does not post event:accepted in the anyscreen mode
because after it receives the value from the server on newselection (the
autocomplete part) the value is not changed so client does not posts
event:accepted when moving from the field.
Need to rethink how this should work without messing up normal behavior of the
combo control.
So progress 
On one hand I can understand Marko’s thinking, on the other hand, it does not seem AnyScreen should take priority over Clarion behaviour. I believe EVENT:Accepted is posted not upon autofill but when Tab is used to move to the next field - ie a value has been entered in the combo, it “matches” the lookup criteria, therefore Tab implies acceptance.
Graham - I very much appreciate your assistance with this. It goes back to the very first AnyScreen release.
Very quick turnaround time. Just received v13743 with the fix included.
