Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Generating a wait state.
Message
From
20/11/1998 19:38:43
George Lee
Microcomputer Engineering Services, Llc
Huntington Beach, California, United States
 
 
To
20/11/1998 17:22:42
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00158843
Message ID:
00160054
Views:
31
>>
>>loCurObj = _SCREEN.ACTIVEFORM.ACTIVECOTROL.
>>
>>* Now get the type from the control source.
>>* Get the name
>>.
>>llCommandButton = .F.
>>DO CASE
>> CASE < commandbutton >
>> llCommandbutton = .T.
>> CASE TYPE < numeric >
>* HERE:
> loCurObj.Value=10
>> lcKeyBoard = "10"
>>ENDCASE
>>
>
>>
>>The point of the code is that I won't know what is on the page prior to running the code. Your keyboard example may not work for specific textboxes. This is a kind of programmatic interactive tester that based on the type of the control box, I will keyboard certain values. Now granted certain fields need special handling. But I am working on something that will do special handling based on properties and methods in the objects that I am looking at.
>>
>>In this kind of loop I need to keyboard. Get control back in the program. Keyboard again. And finally have some way of stopping. Here I am making an assumption that after tabbing through a number of fields, I will reach a command button and stop execution of the test. The test must run by itself. Eventually we plan to have it run a number of screens to simulate data-entry on several different machines for a more severe stress test.
>
>KEyboarding around was always working, to _some_ extent. With too much keyboarding you soon hit issues like hotkeys, focus not being where you expect it, user typing in between etc etc. Since you already have an object reference, why not simply fill its value and refresh() it, and, if this doesn't do enough, .SetFocus to it? Note the place where I wrote "HERE" in your code. It's much more reliable than KEYB, and sure executes several times faster.

Actually, the solution we're working on right now types in so fast we have to throw a delay loop. :) But the reason we wan't to keyboard is so that we can simulate more closely to what the user is doing not just simple validation on text boxes. If we have some kind of trapping of key presses, we want to make sure its working properly. Our original design actually did fill the value but we decided we wanted more. Always more. :)


Dan
Previous
Reply
Map
View

Click here to load this message in the networking platform