669 replies to this topic

[tank]

this_page:=IE7_Get("")

I know i explained this before but this whould not work at all
you need to use a page title
as for the why it works one one machine and not the other im at a loss

are they both the same browser ie7 or 6
is the one at work what browser?

[Sean]

Function Name “ parentWindow”
ERROR: Unknown Name.
(0x80020006)

Shell.Windows retrieves not only the opened windows/tabs of iexplore.exe but also those of explorer.exe. Judging from the error message I guess it's produced by one of the windows of explorer.exe. Do you have any explorer.exe window opened whose address bar's URL contains http inside it?

[CannedCheese]

Thanks guys. I was able to get it running when I reinstalled IE7 at work (run IE7 on both), changed my IE7_Get target to "AutoHotkey" when on the AutoHotkey page, closed all explorer windows, and then hit the hotkey.

Strangely,

this_page:=IE7_Get("AutoHotkey")

... and then I hit F5 with with "google" as my only open IE Window-- and it works as well.... weird. Maybe the page handle is unneeded?

The other (maybe) strange thing is

;com_init() ; COM_INIT() is COMMENTED OUT!
this_page:=IE7_Get("AutoHotkey")
msgbox,,, this_page %this_page%, 1
IE7_InjectJS(this_page, list_elements)

doesn't display a page handle but still works (msgbox is blank)
When I add in COM_INIT(), it displays the page handle in the msgbox also seems to work. I do get it to blow up in both cases when I don't close the popup window and hit the hotkey again (using tanks elements code, the popup window has the same name, so i guess its a known issue), but it certainly works for my purposes.

Now I'm just trying to dig up why it does what it does. Like I said, it works enough for me, so don't burn any unnecessary brainpower at my expense. Thanks again for your help guys.

@Tank, I may take this to your thread when you're done with your tutorials, but do you think you can include a function parameter so that IE7_Get retrieves the active tab (i.e., what I failed to do with IE7_Get(""))?

@SEAN Apologize for thread hijack. Thanks again for turning on debugging (I didn't even know it was an option, your COM script is intimidating). It allowed me to rule out javascript and ActiveX settings as likely causes to my errors.

[Sean]

@SEAN Apologize for thread hijack.

No problem.

Thanks again for turning on debugging (I didn't even know it was an option, your COM script is intimidating).

It's a recent addition. I haven't officially announced it yet as there exists some conflict between the two recent additions: this one and the other to allow omitting the suffix = from the PropertyPut function name. Although there was really one error in your case, there can be actually two consecutive errors in COM_Invoke() because of the latter addition, which I suppose would happen more frequently.

There are three possible ways to report the error(s) in this circumstance. Report both, or only the first, or only the second. Reporting both may sound ideal, but in reality it could confuse the users and complicates the code so that it slows down even in case of final success, and was not that more helpful in my tests. Currently COM.ahk reports the second error, but in my tests so far the first one seemed more sensible and comprehensive.

So I uploaded new COM.ahk which will report about the first error.

[tank]

hadnt thougth about the windows explorer option thanks sean
i knew it i just never thoguth about it when i was working on this with cannedcheese
(amazing what we dont think about sometimes)
Yes i can work on an active internet explorer window function probably have it posted next week
thanks again sean for helpin a hapless fool(me) out

[Joy2DWorld]

COM_Release(window), COM_Release(pwb) , COM_Release(Ret ), COM_Release(title)

my tiny head wonders if all that releasing really nessary...

eg.. pwb release not also clear window ?

even... does window not (and honestly did not look into it) release title ?

[tank]

COM_Release(window), COM_Release(pwb) , COM_Release(Ret ), COM_Release(title)

my tiny head wonders if all that releasing really nessary...

eg.. pwb release not also clear window ?

even... does window not (and honestly did not look into it) release title ?

it was in some un fixxed code he copied from me
you are correct tho

COM_Release(pwb)

is the only one of those necesary
and my understanding from lexikos is that strings do not need to be released i just never updated the code he copied

[Joy2DWorld]

indeed, but does release of window (and honestly did not look into it) release title ?

[ahklerner]

i have been under the impression that pointers to com objects should be released in the opposite order they were created

[Lexikos]

If a script retrieves a pointer to an object, it should always be released at some point. Usually it is not necessary if you are exiting the script, but it is still good practice.

If window, pwb, Ret and title are pointers to objects, they should be released. If Ret is actually a comma-delimited list of values, each value should be released, but only those values that are pointers to objects. COM_Release(Ret) will not work unless there is only one pointer (and no comma.)

However, since Ret is returned to the caller, it is the caller's responsibility to release any object pointers it may contain. If the function were to release these before returning them to the caller, it would be unsafe for the caller to access them. In any case, only the caller (who supplied VarNames_to_Return) knows which values are pointers and which are not. *

If title is text (not an object pointer), COM_Release(title) is invalid - COM.ahk has already converted the value to an AutoHotkey string, so the memory used by title will be freed when the function returns or you do title:="".

Releasing pwb will only release that object pointer, not any other objects retrieved through pwb. (This may not apply to some flawed implementations.)

Also note that lines such as the following are not recommended:

COM_Invoke(psw := COM_Invoke([color=red]COM_CreateObject("Shell.Application")[/color], "Windows"), "Count")

window:= COM_Invoke([color=red]COM_Invoke(pwb, "Document")[/color], "parentWindow")

The red code retrieves object pointers which are lost, with no way to release them. This is why functions like COM_InvokeDeep and ez_Invoke were invented.

Btw, I must question the usefulness of this:

If (InStr([color=red]title[/color][color=darkred]:=COM_Invoke([/color][color=indigo]pwb := COM_Invoke(psw, "Item", A_Index-1)[/color][color=darkred], "LocationName")[/color], [color=red]title[/color], 0)) && ...

Since Haystack and Needle are the same, it will always evaluate to true. (This also depends on the order in which AutoHotkey evaluates parameters, which I believe is undocumented.)

One final tip: Refer to the documentation for the object you are using if you are unsure whether a returned value should be released. Objects should be released; strings, integers, etc. should not. For instance, compare the following properties:

Gets the automation object of the active document, if any.

Syntax

[ oAutomation = ] object.Document

Possible Values

oAutomation - Object that receives the automation object.

Retrieves the path or title of the resource that is currently displayed.

Syntax

[ sLocationName = ] object.LocationName

Possible Values

sLocationName - String that receives the location name. The caller frees this buffer with SysFreeString.

(COM_Invoke calls SysFreeString when it converts string values from unicode to ansi, so you do not need to.)

* It would be possible to extend COM_Invoke to return type information, but I guess that's not relevant.

[Sean]

If needed the return type, may simply add

Global vt

before Return in COM_Invoke().

Although there is no guarantee that the return type is constant, multiple-return-type is indeed very rare. The only case I can recall atm is with some functions of IAccessible, which are already handled in ACC.ahk fortunately.

And, the order of release will not matter mostly, although I suppose the reverse order is the safest bet in case.

[Sean]

So I uploaded new COM.ahk which will report about the first error.

I'd like to finally release new COM.ahk. There are two additions.

1) May omit the suffix = from the PropertyPut function name.
The actual success of it might depend on the implementation of each object, so, in case if not work better fall back to the = suffix.

2) COM_Error() function.
It'll control the notice of error(s) happened inside COM_Invoke(), which is default to On. COM_Error()/COM_Error(False) to turn it off, and COM_Error(True) to turn it on again.
It filters out severe failure which result in the empty returned value as I felt it could be too intrusive, however, if there is a need of including it please let me know.

There can be actually two consecutive errors inside COM_Invoke() due to the first addition, then, COM.ahk will report both errors, but excluding exception information about the second error. If feel the information is not quite sufficient, I'd like to suggest to try again after appending the suffix = to the function name.

[tank]

Also note that lines such as the following are not recommended:

COM_Invoke(psw := COM_Invoke([color=red]COM_CreateObject("Shell.Application"), "Windows")[/color], "Count") 

window:= COM_Invoke([color=red]COM_Invoke(pwb, "Document")[/color], "parentWindow") 

The red code retrieves object pointers which are lost, with no way to release them. This is why functions like COM_InvokeDeep and ez_Invoke were invented.

I didnt think it was an issue however i yeild to the proven expert over me
somehow i guess i was under the impression that if i never created an ahk variable i dont need to release it and it wont hurt anything i think your saying there is a potential prablem here
I will update my scripts today

If (InStr(title:=COM_Invoke(pwb := COM_Invoke(psw, "Item", A_Index-1), "LocationName"), title, 0)) && ...

that was in ahklerners re write to make shorter strange i did it correctly in the navigate but not the IE7_InjectJS im a bone head for not re examining this
thanks for pointing it out

IE7_Get("")

worked because it just grabbed the very first window

@lexikos in the event you havent seen my accolades for you
I want to thank you for all the handholding and getting me started you have done in the past months.
@sean thanks for the awesome library

[Sean]

Actually it's my favorite way to do the job:

COM_Invoke(psw := COM_Invoke(psh := COM_CreateObject("Shell.Application"), "Windows"), "Count") 
pwin := COM_Invoke(pdoc := COM_Invoke(pwb, "Document"), "parentWindow") 

The cons of . syntax, like COM_InvokeDeep() and ez_invoke(), is that it has to re-create/release middle objects even when that's unnecessary. The pros of it is of course that it's easier to the eye.

PS. To avoid unnecessary dispute as I heard someone saying that I didn't like ez_invoke(), which is not true, the above is not critic, just the fact to be aware of when using it.

[Joy2DWorld]

Actually it's my favorite way to do the job:

COM_Invoke(psw := COM_Invoke(psh := COM_CreateObject("Shell.Application"), "Windows"), "Count") 
pwin := COM_Invoke(pdoc := COM_Invoke(pwb, "Document"), "parentWindow") 

The cons of . syntax, like COM_InvokeDeep() and ez_invoke(), is that it has to re-create/release middle objects even when that's unnecessary. The pros of it is of course that it's easier to the eye.

PS. To avoid unnecessary dispute as I heard someone saying that I didn't like ez_invoke(), which is not true, the above is not critic, just the fact to be aware of when using it.

hey, 1. Com_InvokeDeep is not in same animal group as ez_invoke().

2. actually, whole idea of ez_invoke was to cache the middle objects so would be *fast* and avoid unnecessary recreation.

3. an unintended side effect of that was needing to release objects from cache when recreation IS necessary. originally just had a "reinvoke()" that reinvoked w/out release (faster faster), added later an ez_reinvoker() to release & reinvoke, and finally got smart and added a ez_reinvoke@(x,obj..) function which releases everything past the X object in obj string.. [with couple global vars, to skip even that to be faster but in theory 'less safe' ]... it seems working pretty cool.

ps 1. have played with trying release in new thread. ie. for speed.

ps for those not clear: the ez_invoke // ez_reinvoke@ is just a wrapper for Sean's totally genius, revolutionary Invoke....