AutoHotkey Community

it is true that inexperience is the biggest hurdle

these are things that make handling a MODAL more challenging than a standard IE Browser

• MODALS do not appear in the ShellWindows collection
• while the parent browser may be queried the MODAL window cannot itself(as far as i can tell anywhere) be queried successfully for an iWebBrowser2 interface but you may ask for the document which should be adequate for most automation
• MODALS are a way to return data to a web script (VBScript or JScript) that typically requires user interaction to arrive at the desired return value. so by design the browser (firefox IE whatever if support MODAL) requires the process to halt untill the MODAL is dispatched

final point MODALS are not the only instance of this alerts messageboxes and many others if triggered directly via automation all manifest the same behavior. why is becoming such a hot topic when those do not?

I want to clarify these things I'm stating are true regardless of the language. these are not problems with AHK's implementation of COM its the way MODALS are created that make these things true

It may be easier to hack the pages script and insert the predetermined for automation returnvalue for the MODAL than to allow it to spawn in the first place

Bottom line these are not problems Sean, myself or really anyone can solve for you within COM or AHK itself. since it is the architecture of external technologies that create this challenge. Dealing with MODALS with automation should not be done by novices since doingso may require some unique to your situation creative coding.

which is why if the example solution i provided isnt adequete its likely your going to need to just create something else.
@Sean I will not for fear of hijacking this thread post on this subject further as its not a COM problem but a problem of understanding the architecture of browsers. I regret having already showing how to handle MODALS in this thread

@Joy2DWorld
Yes it would still hang

_________________
No matter what your oppinion Please join this discussion
Formal request to Polyethene

In short, I think that multi-thread support is more a problem incurring than solving, especially from the point of view of developers/script providers, in a script environment where the code is plainly exposed to be freely altered.

Yes, I admit it can be handy for simple background jobs, however, those are not un-replacable by other means like SetTimer etc although they may be more cumbersome to use.

Strictly speaking that's not the characteristic of DllCall itself, but that of the API it's calling. DllCall is merely a means to reach the API. Think about then why the API was designed from the start in that way. Could be just for simplicity for some of them, however, there exist ones for which it was crucial. Synchronization is the keyword for them. With multi-threading it's like that you just break those system-provided design and declare you'll take care of all yourself, either consciously or unconsciously. If you got feeling about how much experience it's gonna take to do it correctly (and how easily it can be breakable), I suggest to implement what you suggested lately in this thread using CreateThread etc.

1. settimer won't solve dll as AHK is using psuedo threads.

2. have extensively experimented with AHK using script new thread solutions, and not happy results. EASY to implement as AHK native function, not reliable as far as I've found from within AHK (problem with inserting return values)


3. dependency on DLL to return *is* a serious AHK limitation that I have encountered in many different contexts.

_________________
Joyce Jamce

I'm aware that some members already reported about the ill-behaviors. Nevertheless, I think at least you got the feeling how much you should take into the consideration for your suggested solution, which appears simple, calling COM/iWeb functions from another thread to be correctly behaved.

Why is it a limitation? Or you just wanna have a separate DllCallAsync or alike?

Very nice speech, tank.

1. from my own play with threading in AHK, the problem is AHK internals not with simplicity of creating new thread to call dll from. if AHK internally just creates a threaded DLL call it can manage the return values exactly as handling callbacks right now.

2. unless am missing something the issue is of allowing dll call to new thread. AHK does not need to support AHK multi-thread to do that. Just to allow DLLCALL into new thread & insert return values (even if by callback type approach).

There are many dll calls for scanning/net functions like file downloads, all kinds of apis for dll called programs, etc., where the called routine takes a long time to respond. AHK is 'hung' for this entire time. just as one example.

_________________
Joyce Jamce

Windows usually provides asynchronous support to those APIs which are supposed to take long time to complete, either through optional parameters or with separate APIs. Anyway, if you feel the need of DllCallThread why don't you post about it in Wish List section? Have you already done that?

Actually, Fiigured that no one else would need the function. This thread seems to indicate that maybe it would actually be generally useful, at any rate.

_________________
Joyce Jamce

I downloaded the COM_U.zip files and placed them in C:\Program Files\AutoHotkey\Lib directory which I created. Not sure about the '_U'.

I keep getting 'illegal character' messages when I try to use the com functions.

You need AutoHotkeyU, the Unicode version of AutoHotkey. There's a link to it in my signature.

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Does this replace AutoHotkey Version 1.0.48.05?

Will my other stuff still work?

Is there a version of COM.ahk that works with the standard AutoHotkey?

Thanks

COM.zip is the one for the official build.

Hey Sean, just wanted to know if you might have some guidance for me to troubleshoot a script that uses a lot of COM calls.

In the last couple of weeks my script has been prone to randomly locking up after I'd fire some hotkey that calls COM_Invoke and I wasn't able to pull up the lines most recently executed. When I was finally able to pull it up (momentarily) the last few lines that had executed appeared to be from COM_Unicode4Ansi, specifically:



I never use that call but I did trace it back to COM_Invoke, but I don't know what would cause a COM_Invoke call to "terminate" in that function. There's no particular hotkey I can find that causes the problem, the most typical ones I've used when it occurs were ones I use to click buttons on a web page and one that copies data out of a cell in an Excel spreadsheet. The hotkey always completes its task but I'll have to close the process and restart it.

I haven't changed anything about the COM functions and I downloaded a fresh copy and used it just to make sure the problem was still occurring. Any thoughts on where to look for a problem?

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

How rapidly did you fire the hotkeys? As a first attempt to remedy, I suggest to add Critical into the hotkeys or into COM_Invoke.

If the hotkey takes a little time to complete, it might help to also use the N parameter; e.g. Critical 1000 makes AutoHotkey wait 1000ms between checking for messages. A_IsCritical can be used to save the script's current state for later restoration.
It's almost impossible for the script to stop at Return &wString. Much more likely (especially for COM_Invoke) is something like this:
When evaluation of the line begins, the DllCall line is logged. DllCall itself isn't called until after COM_Unicode4Ansi is called and is logged in ListLines. If nothing appears after COM_Unicode4Ansi in ListLines, it's probably stalled in the DllCall. Here's a more practical example:

It's most likely stalled in pdsp->Invoke (i.e. the particular method you're calling to "click buttons on a web page").


Edit: (on an unrelated note)

Sean, would you mind making COM_SysString an alias for COM_Unicode4Ansi in COM_L? It would make supporting COM_L and COM_U together easier. Actually, might be a good idea to add it to COM.ahk as well...