ObjGet failing?

[Valik]

Hmm... thought I found a trick, but can't make it work yet...

Any hints on how to iterate the ROT in AutoIt? The examples all seem to be VB or VB.Net, not VBScript.

P.S. NVM, looks like everybody got there before me.

Hmm. Your quoted text seems to blow my theory apart. I didn't read the code close enough, apparently, and thought it was doing application-level registration and not document-level registration.

I guess I'll have to think of something else to overcome the limitation.

[Valik]

Interesting. It turns out my theory was right and the text posted by PsaltyDS is wrong. That's why it pays to test things and not rely on what others say.

I'm looking at the Running-Object-Table on my system right now and I see 3 instances of Excel. All of them have the same display name but they all obviously represent different objects. It makes perfect sense. Each object registers itself when it starts. They don't do any complicated checks for other running instances or monitor for another instance to close so it can register itself. They all just register and let the table manage itself. That's why you can close one instance of Excel and the next instance will be returned by ObjGet("", "Excel.Application"). I observe this with Office 2007 but I bet it applies to all versions. At any rate, I'll test with Office 2003 to confirm. However, now that I see multiple objects with the same moniker can be registered, I guess I do have to implement #488 after all.

Edit: Worked with Office 2003 as well. Probably pretty standard for objects to have multiple instances registered in this manner. Which means an instance parameter in ObjGet() would be super useful.

Edited August 1, 2008 by Valik

[PsaltyDS]

It turns out my theory was right and the text posted by PsaltyDS is wrong.

Like THAT has never happened before!

That's why it pays to test things and not rely on what others say.

I'm looking at the Running-Object-Table on my system right now and I see 3 instances of Excel. All of them have the same display name but they all obviously represent different objects. It makes perfect sense. Each object registers itself when it starts. They don't do any complicated checks for other running instances or monitor for another instance to close so it can register itself. They all just register and let the table manage itself. That's why you can close one instance of Excel and the next instance will be returned by ObjGet("", "Excel.Application"). I observe this with Office 2007 but I bet it applies to all versions. At any rate, I'll test with Office 2003 to confirm. However, now that I see multiple objects with the same moniker can be registered, I guess I do have to implement #488 after all.

Edit: Worked with Office 2003 as well. Probably pretty standard for objects to have multiple instances registered in this manner. Which means an instance parameter in ObjGet() would be super useful.

How about ObjGetCollection()? Does it make sense (and is it possible) to get the ROT as a collection object, similar to Dale's _IEFormGetCollection(), where you get a collection by default, or you can specify an instance by 0-based index? For example ObjGetCollection("Excel.Application") would return a collection of all Excel instances, but ObjGetCollection("Excel.Application", 0) returns the first instance only.

Edit: Added example.

Edited August 4, 2008 by PsaltyDS

[Valik]

Ehh, technically yes it's possible but AutoIt would have to implement it all. I don't think it's really any better than what I suggested as it ends up being similar code to use it but internally it ends up being a lot more work since AutoIt would have to implement a collection object to server it.

[ptrex]

@Valik

While your mind is set to COM stuff. Maybe you could look at #50 as well.

Thanks.

Regards,

ptrex

[PsaltyDS]

Ehh, technically yes it's possible but AutoIt would have to implement it all. I don't think it's really any better than what I suggested as it ends up being similar code to use it but internally it ends up being a lot more work since AutoIt would have to implement a collection object to server it.

@Valik: I'm thinking about trying an update to some Excel.au3 functions with a few goals that would help in my own usage:

1. Straighten out Application/Workbook references for consistency

2. Implement COM arrays in/out vice cell-by-cell access of data in the functions

3. Update functions and docs to clear up the confusing world of application/document instances

It looks like implementation of Trac #488 would help with at least some of this. Any chance of it getting some attention soon?