Hello Team.
We have some scripts using EHLLAPI Extenders with 2016 and 2019 Winbatch versions.
This scripts connect Excel and AS400 Application.
Last week the script stop working showing this kind of errors.
(See attachment)
I had to use several TimeDelay(.5) and TimeDelay(3) but I have 8 different scripts and this make a processing time to be augmented by almost 45 minutes.
We also have
;Command to allow CTRL-BREAK to stop the script.
IntControl(12,4,0,0,0)
;Command to wait 2000 milliseconds before each communication with a PC application, which is Excel and the host emulator in this script.
;This was found to make the script run more reliably.
IntControl(35,2000,0,0,0)
But I do not understand what this IntControl makes and I found no documentation related to.
Does anyone have a similar situation?
I have 2 years learning about winbatch scripting documentation based and I have no clue on what's next.
Thanks.
Here the issue.
Both IntControl 12 and IntControl 35 are documented in the Consolidated WIL Help file. There is no reason to repeat their purpose here (likely with typos...)
If your scripts stopped working, you need to ask yourself what changed. Is it a network issue, an OS update of some kind, a security policy change or something else?
I don't believe you can reliably use TimeDelay() when attempting to communicate with a host application using ehllapi. Your program should be using extender commands such as ehllapiWait which waits for the presentation space to be available. Then use other commands such as ehllapiFindFieldPos() and ehllapiCopyTextToField() to reliable enter data into the host application.
Good advice.
Quote from: nrr on December 17, 2019, 06:33:54 AM
I don't believe you can reliably use TimeDelay() when attempting to communicate with a host application using ehllapi. Your program should be using extender commands such as ehllapiWait which waits for the presentation space to be available. Then use other commands such as ehllapiFindFieldPos() and ehllapiCopyTextToField() to reliable enter data into the host application.
Yes I guess it should be some windows updates but I work for a IT Managed enviroment :(
Quote from: nrr on December 17, 2019, 06:33:54 AM
I don't believe you can reliably use TimeDelay() when attempting to communicate with a host application using ehllapi. Your program should be using extender commands such as ehllapiWait which waits for the presentation space to be available. Then use other commands such as ehllapiFindFieldPos() and ehllapiCopyTextToField() to reliable enter data into the host application.
This is pretty much a good advice However I notice that the issue in not with the host itself, most likely 99% of errors are related to the excel input/output.
So if there is any ehllapiwait that actually works in excel could be awesome.
I've never had issues with "waiting" for Excel. Once it initializes, it's consistently available. Can you debug this through the debugger? Just guessing but perhaps the value of your RowNumber +1 or WorkItemCol variables has become invalid.
Quote from: nrr on December 17, 2019, 11:47:34 AM
I've never had issues with "waiting" for Excel. Once it initializes, it's consistently available. Can you debug this through the debugger? Just guessing but perhaps the value of your RowNumber +1 or WorkItemCol variables has become invalid.
Thank you for your answer.
Actually we do not change anything, If I use the debugger it takes more time to complete but it works fine, when I run the script the issue raise. That's why as a workaround I use the TimeDelay but some points I can use the TimeDelay on .5 but some other points I have to use up to 8 seconds :(
As the original author of the EHLLAPI extender, I can confidently make the statement that the time delay operations in a WinBatch script have no direct effect on the operation of the EHLLAPI programming interface that is used to allow a WinBatch scrpt to interact with a 3270/5250 terminal emulator. The only effect that it might have is change the point in time at which a screen-scraping key-send operation occurs and whether or not host application in an appropriate state for the screen content to be appropriate or for the key to be sent to be acknowledged by the host application.
I also noted that the WinBatch pop-up error message indicated a COM-related error had occurred, which has to do with Excel, not with the EHLLAPI extender. Whatever is going wrong with the communication with Excel via COM is producing that error message and the underlying root cause needs to be identified.
Quote from: ChuckC on December 18, 2019, 09:42:48 AM
As the original author of the EHLLAPI extender, I can confidently make the statement that the time delay operations in a WinBatch script have no direct effect on the operation of the EHLLAPI programming interface that is used to allow a WinBatch scrpt to interact with a 3270/5250 terminal emulator. The only effect that it might have is change the point in time at which a screen-scraping key-send operation occurs and whether or not host application in an appropriate state for the screen content to be appropriate or for the key to be sent to be acknowledged by the host application.
I also noted that the WinBatch pop-up error message indicated a COM-related error had occurred, which has to do with Excel, not with the EHLLAPI extender. Whatever is going wrong with the communication with Excel via COM is producing that error message and the underlying root cause needs to be identified.
Hi Chuck, thank you so much for your reponse.
Yes, actually I'm currently working with this script and issue persist, I'm pretty sure is more related to some Excel/Windows updates because i.e. the one I have at this momento is that do not have enough time to send the save process to excel :facepalm:
BTW thank you for such amazing Ehlappi feature, more than 10 years up and running and excel is the one creating the conflict.
I use AS390 with Personal Communications Software!
Thanks you sir!
@Forum, anyone that is currently this kind of issues excel related?
Thanks.
Is your Excel file on a network drive? If so, I would look there as a potential intermittent failure.
ChuckC ... I also offer my thanks for the ehllappi extender. I've used it quite a bit over the years at different client sites.
Quote from: nrr on December 19, 2019, 06:33:19 AM
Is your Excel file on a network drive? If so, I would look there as a potential intermittent failure.
Local File, we create every day different excel files, we process a lot of files a week lol
Update,
I just reinstall Office and appears is working fine, I'm allowing a whole week expecting for errors.
next step Windows fresh install.
Thanks!