XCLOCK = xNO_STATUS before all data displayed 1

[adalger]

Hi, all. I have an issue.

I'm doing this:

Dim esys As ExtraSystem
Set esys = CreateObject("Extra.System")

Dim essn As ExtraSession
Set essn = esys.Sessions.Open("Session1.EDP")
essn.Visible = True

Dim escr As ExtraScreen
Set escr = essn.Screen

escr.Synchronous = 1

Dim eoia As ExtraOIA
Set eoia = escr.OIA
Do While eoia.XStatus = xBUSY
    DoEvents
Loop
    
Ef escr.search(<startup text>) = "<expected text>" Then
    <do something>
Else
    <do something else>
End If

The problem is, it always comes up false. Now, I know a potential solution is to use instead:

dim blnFound as boolean
blnFound = escr.WaitForString("<expected text>")
If blnFound then
(etc)

Unfortunately, I need a more general solution for a case in which I will be sending arbitrary commands to a host screen and may not know in advance what text I'm looking for -- particularly, when all the text I *know* will be on the result screen is already on the screen on which I'm entering the commands. Is there a more general and *reliable* way to know that the host has finished sending information and all the information is available to the Screen object?

Thanks for any insight,

--
Rob

 

[IknowMe]

You could try something like this. It will store the current screen issue the call for the next screen and hold until the new page is loaded.

Dim temp1 As String

temp1=escr.Area(1,1,24,80,0,3).value
escr.sendkeys ("<TRANSMIT>") 'or whatever you do to navigate to the next page

Do 
             ' add some timer or jump out here in case  
             ' screen never changes
  DoEvents ' This is a hard loop and my pc fan
             ' "helicopters" without the doevents
loop until temp1<>escr.Area(1,1,24,80,0,3).value

Wow, I'm having amnesia and deja vu at the same time.
I think I've forgotten this before.

 

[adalger]

This looks like a very likely solution, but my laziness tells me it isn't quite perfect. It doesn't distinguish between "The host never responded" and "The requested screen is identical to the previous screen", which forces me to determine in code whether the screen displayed is already the one requested. This special case is isn't very unusual; a <PA1> refresh attempt may result in either a redraw of the current screen or a return to the sign-on screen as a result of timeout.

I can, of course, track what request is currently being answered and simply ignore a duplicate request, but that seems like it's going to be a lot of work; I'd have to account for the cases where duplicate requests are in fact valid because of multiple-page responses.

 

[IknowMe]

Does a multiple page response return identical screens?? No change in information or even a page x of y footer ect.

Just curious as I see no reason to request a page identical to the page currently displayed.

Wow, I'm having amnesia and deja vu at the same time.
I think I've forgotten this before.

 

[adalger]

The primary reason to request a page identical to the page currently displayed is to determine whether the login has timed out. The response will be either a page identical to the page currently displayed, or the login screen.

The secondary reason to request a page identical to the one currently displayed is so I don't have to know what the page currently displayed is when I frame my request.

The actual answer to your question is, for multi-page responses, there will always be at least one point of difference. The supplemental answer is, it is possible in some cases for two different requests to generate identical response pages.

I think my point of unclarity was, I want to be able to request a page identical to the current page not because it is inherently useful to do, but because it is frequently useful to not care at all what page I'm on when I make my request. Does that make sense?

 

[IknowMe]

Point taken. I do mostly batch processing so I had a hard time seeing the side you've explained. I'll give the problem some more thought.

Wow, I'm having amnesia and deja vu at the same time.
I think I've forgotten this before.

 

[calculus]

I use a "Wait" Function that looks like this in code:

Wait "Enter", optional WaitForString here

Sub Wait(Optional Action, Optional WaitForString)
With Sess0.Screen

If IsMissing(Action) Then Action = "<Enter>"

If Left(Trim(Action), 1) <> "<" Then Action = "<" & Trim(Action)
If Right(Trim(Action), 1) <> ">" Then Action = Trim(Action) & ">"

.SendKeys Action
Do While .OIA.XStatus <> 0
    DoEvents
Loop
If .GetString(24, 11, 14) = "REASONABLENESS" Then Wait "Enter"

If Not IsMissing(WaitForString) Then .WaitForString WaitForString

End With
End Sub

The important part of the code and the simple answer to your original question is:

Do While .OIA.XStatus <> 0
    DoEvents
Loop

I think the problem your having is that the OIA object is returning some other code than the one your looking for, but it's still not done with the screen. Waiting for the XStatus = 0 says that the XStatus is gone from the screen.

calculus

 

[adalger]

Thanks for that, but I've actually tried that before. That's where the original post title comes from: xNO_STATUS is the constant for the value 0. The OIA.XStatus call returns 0 before the data is actually displayed on the screen.

Just to make sure, I put my code back to that check, and it's still broken.

Another issue with this is, I'd like to be able to recover gracefully if XStatus changes to something other than xBUSY or xNO_STATUS as a result of either operator interference or erroneously placed characters. If a persistent non-zero XStatus arises, your function perma-loops; this is highly suboptimal for my conditions.

 

[Skie]

I use a method similar to MrMilson's. Are you able to clear the screen prior to initiating the next command? This should solve your two screens being the same issue. The first screen is a clean slate except for the command, and the second screen is the response to that command.

 

[adalger]

I can't clear the screen, no, but I could go to each screen the long way from the main access screen. This is the solution I adopted for a batch job. Unfortunately, many of the commands are context-dependent. That means, if I clear the screen or return to the main access screen, I lose all the context that modifies the command. I don't want to do this, because it's a system for live phone reps, and if the system is bogged, this loses massively on time compared to just using the terminal interface.

 

[Skie]

You could have it time out after so many loops. Have it treat a time out as a duplicate screen. To be on the safe side you could have the program reinitiate the original command at this point. Basically, have 2 duplciate screens register as an actual duplicated screen. About the only thing that would impact this is a slow response time.

 

[adalger]

Well, everybody, thanks for the advice. It looks like my best bet is a hybrid approach: take a screen cap, send my command, wait for both xSTATUS <> xBUSY and escr.Area(<the whole darned thing>) <> the screen cap, and then grep for identifiers that will tell me whether I got the screen I wanted. It's not as beautiful as I'd like, but it'll let me respond appropriately to both timeouts and system down screens.

Again, thanks. Now on to the heavy design work. Yippee.