WaitForString & WaitForCursor Help

[jdowski]

Hi All,

Just joined. First post...be gentle . I am using myEXTRA!Enterprise 7.11 and running my code from Access 2013 with a reference set to the Extra Object Library. While I am comfortable coding in Access, the Extra Basic stuff is new, exciting, but still confusing at times. I have code I have written that up til now worked fine. I was asked to add to it to pull a couple more fields and now it errors out. I had been using WaitHostQuiet at various places in my code to throttle it so that it wouldn't error out. However, I have run into issues where I believe I will have to use either WaitForString and/or WaitForCursor. I am looking for some examples that would make sure that the cursor had made it to a certain position and/or that the string I pushed to the screen has registered before hitting Enter. I can google VBA help all over the place... Extra Basic info & examples seem much harder to find..?

 

[SkipVought]

Hi,

Do Until oScreen.WaitForCursor(row, col)
   DoEvents
Loop

...where row, col are the screen rest coordinates.

 

[jdowski]

Hi Skip, Thanks! After posting I started search the forum here and did find some other threads with suggestions. I had heard recently that DoEvents should be avoided? You have any thoughts on that one way or another, or alternatives?
Thanks, Joe

 

[SkipVought]

see what happens.

 

[jdowski]

Good Morning Skip,

I've tried using both a WaitForCursor and a WaitForString. I'll get through about 10 records and then the session will lock up. I get the little icon in the session tray that looks like a little man with arrows for arms? After I break my code I hit Escape in the session to clear the little man icon and then if I let my code continue to run again, same thing, about 10 records read and then a lock.

I have attached the portion of code where the error is occurring. Best I can tell is the cursor is not getting to screen position 24,78 in time to receive the entry of "27" or the "27" isn't making it to the screen in time before the "Enter" key is sent. When I break the code after an error on the session screen I will either see nothing at position 24,78 (should I be seeing the underscore for the cursor?) or I see the 27.

The only other strange thing I noticed is the waitforstring command is not capitalized like the waitforcursor command is in my code? I have the Attachmate reference set in my VBE. I can look up the method in the Project Explorer?

        RS![DOS - Start] = Trim(.Screen.area(8, 26, 8, 33))
        RS![DOS - End] = Trim(.Screen.area(8, 38, 8, 45))
        RS![Group Name] = Trim(.Screen.area(6, 14, 6, 66))
        RS![Group Number] = Trim(.Screen.area(5, 48, 5, 71))
        RS![Product] = Trim(.Screen.area(7, 11, 7, 50))
        RS![Member ID] = Trim(.Screen.area(4, 45, 4, 59))
        RS![Check Acct-Num] = Left(Trim(.Screen.area(13, 17, 13, 30)), 6)
        RS![Check Date] = Trim(.Screen.area(13, 60, 13, 67))
        
        .Screen.moveto 24, 78
        
        Do Until .Screen.WaitForCursor(24, 78)
            DoEvents
        Loop
        
        .Screen.putstring ("27")
        
        Do Until .Screen.waitforstring("27", 24, 78)
            DoEvents
        Loop
        
        .Screen.SendKeys ("<ENTER>")
        .Screen.WaitHostQuiet (50)
        
        RS![LOB] = Trim(.Screen.area(10, 24, 10, 40))
        RS![Provider ID] = Trim(.Screen.area(7, 24, 7, 40))

 

[SkipVought]

Your terminal emulator is the I/O between your PC and the mainframe.

The process on the mainframe is asynchronous to your VB code process. The text you Put on the screen is there when you put it there. There is no delay, so the Do...Loops that you have in your code are utterly unnecessary!

Where you should have a WAIT is after you SendKeys to the mainframe to go off and process the data you have put on the screen: NOT JUST A MERE 10 milliseconds!!!! That's like waiting at a busy intersection for merely 5 seconds before blindly entering the intersection without regard to the traffic conditions. The result will be disastrous!

I'd surmise that this code is a portion of a larger LOOP. You must have the proper WAIT after each SendKeys! PutString needs no such delay! AND PutString has row/col coordinated, of which I observe none!.

PutString has NOTHING to do with the Cursor!!!

 

[jdowski]

Hi Skip, understood with your comments but the cursor should already be in the correct position from the commands just above?

BTW, are there any good books or sites dedicated to just AttachMate programming?

        RS![Member ID] = Trim(.Screen.area(4, 45, 4, 59))
        RS![Check Acct-Num] = Left(Trim(.Screen.area(13, 17, 13, 30)), 6)
        RS![Check Date] = Trim(.Screen.area(13, 60, 13, 67))
        
        .Screen.moveto 24, 78
        
        Do Until .Screen.WaitForCursor(24, 78)
            DoEvents
        Loop
        
        .Screen.SendKeys ("27")
        
        Do Until .Screen.waitforstring("27", 24, 78)
            DoEvents
        Loop
        
        .Screen.SendKeys ("<ENTER>")
        .Screen.WaitHostQuiet (50)
        
        RS![LOB] = Trim(.Screen.area(10, 24, 10, 40))
        RS![Provider ID] = Trim(.Screen.area(7, 24, 7, 40))

 

[SkipVought]

None of which I am aware.

The only hing that the cursor is relevant to is WaitForCursor, which I assume rests at 24,78.

I guess you ignored the rest of what I posted!

'
    RS![Member ID] = Trim(.Screen.area(4, 45, 4, 59))
    RS![Check Acct-Num] = Left(Trim(.Screen.area(13, 17, 13, 30)), 6)
    RS![Check Date] = Trim(.Screen.area(13, 60, 13, 67))
[b]    
    .Screen.PutString "27", 24, 78   'I assume that 24,78 is where you want "27" NO DELAY HERE
    
    .Screen.SendKeys ("<ENTER>")     'DELAY NEEDED HERE as the mainframe will respond ASYNCHRONOUSLY
    
    Do Until .Screen.WaitForCursor(24, 78)     'so here's the DELAY!
        DoEvents
    Loop
  [/b]  
    RS![LOB] = Trim(.Screen.area(10, 24, 10, 40))
    RS![Provider ID] = Trim(.Screen.area(7, 24, 7, 40))

 

[SkipVought]

BTW,

It seems we're starting in the middle of something, when, in my opinion, we ought to be looking at something much more basic and fundamentally important: your SCREEN NAVIGATION, which I perceive is grossly out of kilter!

If this code snippet you posted is so far off base with regard to your screen navigation, then your overall navigation needs attention!

 

[jdowski]

You're correct.