kefka95 Absent Member.
Absent Member.
1363 views

SendControlKeySync clarification

I'm looking for some clarification as to how exactly the SendControlKeySync method works. My impression is that it sends the control key, then does an implicit WaitForHostSettle afterwards. However, I'm having issues getting this to work cleanly. On queries that take more than about a second to process, the method ends up returning almost immediately, even though the host is still processing. In my experience, this usually points to a timeout value that's too low, but I don't see anywhere to set a timeout value on the SendControlKeySync method. I know it relies on the ScreenSettleTime property, but I didn't see anything about the timeout value.

In any case, I've been able to work around it by using the regular SendControlKey and then doing an explicit WaitForHostSettle with a specific timeout and settle time, but I just wanted to make sure I wasn't missing something on the Sync version of the method.
0 Likes
3 Replies
vfast Absent Member.
Absent Member.

Re: SendControlKeySync clarification

The docs for this method say that: "The method does not return until the screen has settled for the time duration measured by the ScreenSettleTime property." I take this to mean that that timeout value on it will be indefinite - after sending the keystroke, it should wait forever until the terminal is unlocked for at least the ScreenSettleTime, which by default is 500 milliseconds. That's pretty short. You should be able to increase reliability on this by boosting the ScreenSettleTime to 1000 or more.
0 Likes
vfast Absent Member.
Absent Member.

Re: SendControlKeySync clarification

Futhermore 🙂 to get the best performance for scripted automation of terminal sessions, stay away from the generic "Wait" methods that rely on a settle-time to insure that the terminal is ready for continued activity from you. Most of the time, you will know exactly what screen is going to appear next after you send enter. In that case, use WaitForText, or WaitForCursor, which both provide excellent synchronization for scripted interactions, without introducing unnecessary settle-time delay. Only use WaitForHostSettle or SendControlKeySync when you have no idea what screen will be coming up next after the enter key.
0 Likes
kefka95 Absent Member.
Absent Member.

Re: SendControlKeySync clarification

Thanks for the reply. I don't believe the issue is the settle time. If I call WaitForHostSettle with a settle time of 0, it works perfectly fine, and correctly waits until the host has responded. I think it's just something funky the "Sync" methods in particular. Typically the largest settle time we ever use is 50 milliseconds, and often we use 0. Our applications can sometimes go through tens of thousands (if not hundreds of thousands) of screens, and waiting a full second between each one would be unusable!

I agree that the WaitForText runs faster in general, but it also poses its own problems. Specifically, it means that every single screen change has to have its own individual logic in the code, which gets extremely messy to both code and maintain, especially when there are lots of different screens involved. It also means that if the text you're waiting for ever changes or moves, then your entire process breaks down. I've also had issues when the WaitForText value is at the top of the screen. It's almost as if the top of the screen is drawn first, and the code sees the wait value and continues on, but it hasn't actually finished loading the entire screen yet, which in turn leads to code that's out of sync. That's why we tend to use WaitForHostSettle. It's clean and easy and just "works" without any further headache.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.