AutoHotkey Community

Modal windows are supposed to freeze the calling program? On what level does that make sense to you, that a modal window will freeze a separate running program? Clearly it's the COM library that is puking all over itself when these modal window open.

incith,

your tone is maybe more disrespectful than intended ?

How is the COM modal window acting for you different than say, a native AHK msgbox command ?

_________________
Joyce Jamce

Sorry, not trying to be disrespectful of course. The COM library is not something I could create. Still, it is irritating when people dismiss what you are saying, or do not believe you at all. I'm just trying to solve a problem or limitation here.

It's simple really. I'm doing this:


After I close the modal window, then the Send() code is executed. As the comment I wrote indicates, the entire AHK application freezes completely while the modal window is open. I cannot do anything or code around this currently. I don't need COM or iWeb to manipulate the fields in the web page dialog; I just need AHK/COM to not freeze while it is open.

what is the function "iWeb_clickDomObj" look like ?


also if you settimer, somesub, -100
into the call, does ahk still hang ?

(ie, create a psuedo thread to execute the iWeb_ function)

_________________
Joyce Jamce

As I already said, this is a perfectly normal/expected behavior. COM/iWeb function is synchronous, i.e. will not return, is waiting until the opened modal window is closed. In your case, I think it's slightly more involved, actually is waiting for SendMessage to return behind the scene. As a side-effect, all AHK's GUIs will be irresponsive too during. If you don't like it, use other asynchronous means like Click/ControlClick etc.

if am understanding, the iWeb is doing
COM_Invoke(pWin,"Document.all.item[" obj "].click")

Maybe use a better DOM approach for single object ?

or even wouldn't injecting javascript get same result without delay ?

also,

@Sean,

possible to option COM sync calls as a sync ??

_________________
Joyce Jamce

Ah, I understand now. Sorry about that Sean.

Yeah, async would of course be nice.

It depends on objects themselves, however, there is no way of the asynchronous support for IDispatch objects which COM_Invoke is dealing with AFAIK. BTW, I suppose javascript injection will do the trick, so may use it instead in this case.

nope javascript injection will manifest the same behavior the IE frame will be frozen untill the MODAL is dispatched


as Sean so reverently tried to explain COM is async
you will need to spawn a secondary script to deal with the modal or use com to set focus and then send the enter key to spawn the MODAL.

why this makes sence the MODAL is actually waiting for the return value of the function that spawns the window if you dont like this behavior compain to w3c and or the site designer for using it

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

Yes, however, that was not his issue. He seemed to understand the part that a modal window disables/freezes its owner window, iexplore.exe in his case, but not the part that it'll not return to the caller, ultimately AHK in this case, until dismissed.

So the question is: when the called function returns, before or after going into the actual routine of say, showModalDialog or alike. I supposed the javascript injection, through either execScript or Navigate, would return before executing the injected code, but I haven't tested it.

I have tested execscript and the result is the same execscript causes ahk to wait for the function to return before going on I have tried thru navigate tho so in fairness you may try
start herefor understanding how to control it after wards

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

have not played with it, but seems that new thread can be opened for the actual COM DLL call that 'hangs' waiting for the call to return.


maybe even worth a feature request for AHK, a of DLLCallThread() function..

_________________
Joyce Jamce

Oh I see. Sorry, looks like I somehow missed those posts in this very thread. Actually I was aware of them, however, I suppose I only scanned them. BTW, the control itself shouldn't be a problem as it's identical to that of a non-modal window. The problem is that many users will be lost on how to trigger it.

I'm dubious that you're gonna really like having it. Speaking for myself, I reckon I'm gonna even more picky in posting scripts than now, unless can protect the code from being arbitrarily altered by inexperienced users.

@Sean,

have personally leaned mountains from so much you've posted. Would hope that you'd continue to post freely.


as for result := DLLCallThread(), can think of *a lot* of places where would come in handy.

Currently AHK script *must* wait for DLLCall to return. Why ?? (Not in why must that be with simple DLL Call, but.. why keep that limit when can be removed by simply allowing DLLCallThread().

_________________
Joyce Jamce