Script hangs on child IE window

[Marcus Tettmar]

I have tested this and did indeed replicate an error with this website when the script ended, but not every time. We'll continue to investigate.

[Marcus Tettmar]

Just to let you know we have identified the cause of this and it is now fixed in dev along with a number of other code improvements. We will release this fix in the next public maintenance release.

[newuser]

Just to let you know we have identified the cause of this and it is now fixed in dev along with a number of other code improvements. We will release this fix in the next public maintenance release.

Hi Marcus,
Is it possible to made the ms native killprocess function so that it have the same killer effect as microsoft taskkill or pskill in your next maintenance release?

Thank you.

[Marcus Tettmar]

Just to let you know we have identified the cause of this and it is now fixed in dev along with a number of other code improvements. We will release this fix in the next public maintenance release.

Hi Marcus,
Is it possible to made the ms native killprocess function so that it have the same killer effect as microsoft taskkill or pskill in your next maintenance release?

Thank you.

This is completely off topic and has nothing to do with the IE.. functions.

However, the answer is no: I have already answered your other post. I explained that KillProcess already uses the standard Windows TerminateProcess function. I reviewed the code and it does everything in accordance with the Microsoft documentation, including request the correct access permissions in OpenProcess. We're using industry standard code and using the Microsoft API in accordance with the Microsoft documentation.

If you wish to terminate security processes that are presumably there for a very good reason, and probably do things to prevent being terminated, you are on your own.

[Marcus Tettmar]

Macro Scheduler 14.0.11 is now available and fixes the IE function issue that this thread relates to.

[Enricoys]

So if you're going to use v14 then modify the code to use v14 native functions. Then you don't need any runtimes and you'll be using the latest code. As follows:

Code: Select all

//Move the mouse cursor out of harm's way to avoid causing mouseover events to interrupt
MouseMove>0,0
Let>delay=1
IECreate>IE[0]
IENavigate>%IE[0]%,http://www.webmaster-talk.com/html-forum/32504-hyperlink-target-open-in-new-tab.html,r
IEWaitDocumentComplete>IE[0],r

Let>TagValue={"http://www.w3.org/TR/2004/WD-css3-hyperlinks-20040224/"}
IEClickTag>%IE[0]%,,,A,TEXT,TagValue,r
IEWaitNew>IE[1]
IEWaitDocumentComplete>IE[1],r
Wait>delay

IEQuit>IE[1],r

This code works perfectly in v14 for me.

Marcus,
In my script I observed the problem that the script keeps waiting for command IEWaitNew as soon as I open a new Internet page on a new tab. I found your example script above and tried to run it. However, I observe also in this example the same problem. At my system your script keeps waiting at the line "IEWaitNew>IE[1]". When I manually stop the debugging then I have to kill Macro Scheduler by Taskmanager since a normal close (with 'X') doesn't work anymore. What I'am doing wrong?
I'am using version 14.0.18 on Win7 with IE9.

[Marcus Tettmar]

You might need to disable tabbed browsing so that new windows open in new windows rather than new tabs.

I'm aware that this may not be possible in the very latest version of IE and we are therefore investigating alternative solutions.

[Enricoys]

Tnx Marcus, this was indeed the 'solution'. I can use now this workaround, however please let me know when it also works for tabbed browsing.

[Enricoys]

Now another problem with a hanging IEWaitnew appeared. I my main script clicking on button to open in a PDF-file in a new IE-window did indead open the PDF in a new window, however it hangs at IEWaitnew. I found a website to show you the problem. See script below. To overcome earlier problems with IEWaitenew I'am using the non-tabbing mode (so each time a new IE-window is opened). I'am using: Win7, IE9 and Macro Scheduler: 14.0.18. Looking forward to an answer.

Code: Select all

//Move the mouse cursor out of harm's way to avoid causing mouseover ev
//Move the mouse cursor out of harm's way to avoid causing mouseover events to interrupt
MouseMove>0,0
Let>delay=1
IESetTimeout>10,ie_res
IECreate>IE[0]

//Probably you need to accept Pop-up's for this website to let it work
IENavigate>%IE[0]%,http://www.computerhope.com/issues/ch001285.htm,ie_res
IEWaitDocumentComplete>%IE[0]%,ie_res

MessageModal>{"1: Open PDF"}
IEClickTag>%IE[0]%,{""},{""},{"IMG"},{"CLASSNAME"},{"floatRight"},ie_res

MessageModal>{"2: IEWaitNew"}
IEWaitNew>IE[1]
// It hangs here!


MessageModal>{"3: IEWaitDocumentComplete"}
IEWaitDocumentComplete>%IE[1]%,ie_res

MessageModal>{"4: Complete"}

[Marcus Tettmar]

Could be because it is a PDF the new window is not a pure browser window - no doc view - so the command never sees a new browser document.

We are currently investigating improvements for IEWaitNew and will look into this also.

[shadowesq]

Hello all.

Well, even though this thread is some six years old, the fun continues in 2020.

I have a script which is hanging on the IEWaitNew>0,IE[1] command. There is a pdf page in the child window. The script opens the new window perfectly. However, after that, the script hangs on the IEWaitNew command.

And then it gets even worse.

After the system hangs on the IEWaitNew command, it locks up the actual Macro Scheduler editor itself, so that you CANNOT close the script. Pressing the Close option from the File dropdown menu does nothing. Right clicking the icon at the bottom of my screen and clicking on Close does nothing. The only way out is to go into Task Manager and kill the Macro Scheduler task.

But, wait, there's more.

I reproduced this bug on TWO separate systems, two Dell laptops, each with 16 GB of memory. System One CPU is an Intel Core i7-7820HQ CPU @ 2.90GHz. System Two CPU is an Intel Xeon E-2276M CPU @ 2.80GHz. On both computers, the script hangs on the IEWaitNew command. And on both computers, the Macro Scheduler editor locks up, so that you CANNOT close the script.

I am currently opening child windows in a new tab, which is my preference. However I did try changing the settings to open the child window as a separate window. The same problems persisted - the script froze and the editor locked up.

The ability to use this feature would really help my business and make my coding much easier. But right now I am stuck.

I have a small code sample which I can provide to reproduce the error. I can't post my code here because of the confidential nature of my work, but I can provide my code to support privately, so that you can run it and see for yourself.

I do all my work on Macro Scheduler 15.0.05
My IE version is 11.371.16299.0

The detailed data on my two computer systems is attached.

Thank you for any help you can provide!

[Marcus Tettmar]

Feel free to send your script to support via https://www.mjtnet.com/contact.htm

Could you use a WaitWindowOpen instead of the IEWaitNew? Then use IEGetFromURL to get a reference and continue. Thus avoiding IEWaitNew completely.