Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

COM Standard Library


  • Please log in to reply
669 replies to this topic
incith
  • Members
  • 130 posts
  • Last active: Apr 03 2010 03:08 AM
  • Joined: 01 Oct 2005
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.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Apr 30 2013 09:57 PM
  • Joined: 04 Dec 2006
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 ?

incith
  • Members
  • 130 posts
  • Last active: Apr 03 2010 03:08 AM
  • Joined: 01 Oct 2005
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:
; click the Reset Password button, which opens a Modal Web Page Dialog
      iWeb_clickDomObj(pwb,"ResetPassword","23,58")
      ; nothing after the click will be processed, at all.  once the modal window is closed, everything after this point will execute just fine.  but while the modal window is open, the GUI window of the AHK application is frozen and cannot be used or interacted with in any way.  This is not the behavior of modal windows.
      ;iWeb_Release(pwb)
	   ;iWeb_clickDomObj(pwb,"ResetPassword","23,76")
	   ;iWeb_complete(pwb)
      Sleep, 1500
	   if (myPass)
	     Send, %myPass%{Tab}%myPass%{Tab}

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.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Apr 30 2013 09:57 PM
  • Joined: 04 Dec 2006
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)

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
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.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Apr 30 2013 09:57 PM
  • Joined: 04 Dec 2006
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 ??

incith
  • Members
  • 130 posts
  • Last active: Apr 03 2010 03:08 AM
  • Joined: 01 Oct 2005
Ah, I understand now. Sorry about that Sean.

Yeah, async would of course be nice. :)

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
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.

tank
  • Moderators
  • 4192 posts
  • Last active: Yesterday, 05:36 PM
  • Joined: 21 Dec 2007

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 :wink: 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

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

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

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.

tank
  • Moderators
  • 4192 posts
  • Last active: Yesterday, 05:36 PM
  • Joined: 21 Dec 2007

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 :D 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
COM_CoInitialize()
pwb:=iWeb_newIe()
iWeb_nav(pwb,"http://www.google.com")
COM_Invoke(pwb,	"Navigate",	"javascript:window.showModalDialog('http://www.google.com','','')",	navTrustedForActiveX,	"_self")
MsgBox
COM_CoUninitialize()
start herefor understanding how to control it after wards

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Apr 30 2013 09:57 PM
  • Joined: 04 Dec 2006
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..

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

start herefor understanding how to control it after wards

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.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007

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

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.

Joy2DWorld
  • Members
  • 562 posts
  • Last active: Apr 30 2013 09:57 PM
  • Joined: 04 Dec 2006
@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().