ASM Community

Does anyone know off hand what the API is that is equivalent to VB's GetObject? I want to Create and Instance of an OLE Appication, but i dont want to create a new instance if one is already running. Instead i wish to get its interface pointer and work with the open Instance..

Basically im trying to code in MASM the equivalent to:

Set objXL = GetObject(, "Excel.Application")

	

	'	What did we find?..

	If Not TypeName(objXL) = "Empty" Then

		strMessage = "Excel Running."

	Else

		strMessage = "Excel Not Running."

	End If

However, Its not for Excel for my purposes ;)

Thanks in advanced...
:alright:
NaN

NaN , if you'll get the solution - could you share it with me? I tried to solve such problem, but I could'n do it myself.

IRunningObjectTable::GetObject

I remembered this from a white paper and checked MSDN for ROT.

Is this what you are referring to?

Regards, P1

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0797/activex0797.htm&nav=/msj/0797/newnav.htm



http://archive.devx.com/premier/mgznarch/vbpj/1997/08aug97/bbelt.pdf

Thanks for the help.. This was a Nusance of a problem. I had envisioned 10min of work to do this much, but in turn it took all day ( :rolleyes: ).

I have now got it working.. but not with out new turn of events. Im transcribed the MS source entirely and it wasnt working. With some debugging, i found out that "GetActiveObject" was actually reteiving a proper interface pointer if Excel was running, however, when i use this pInterface I ended up with crashes every time.

Then it dawned on me. This is a dispatched handle created "on the fly" and i guess this implies to Excel that this interface handle can not be called by Early Binding ( virtual function calls).

So i tried with late binding, using the Dispatch _Invoke method, and voila! This interface handle does work!

The really interesting bit to this adventure is two things:

[*]The pInterface from a CreateInstance application of Excel does not match the pInterface returned by GetActiveObject, even though they are suppose to be the same interface to the same application. This i can buy rationally (they are objects).
[*]The pInterface returned from CoCreateInstance will allow early bound call to the "Quit" method by "vf() calling". However, the returned Interface from GetActiveObject will crash if i do the same, but works for late binding to the same "Quit" method via "dm() calling". This Im confused on how the segragation is defined by the running OLE process. They appear to be the same on the surface, and as viewed by ITypeInfo, but the definetely are NOT the same. Its as tho there is a hidden flag saying, I MUST BE LATE BOUND ONLY!.


This means to be able to link and run to active applications through OLE, i need to have all the methods declaired for the slower late binding. Japtheths ComView (which i still think is a fanstastic piece of work) only provided dm declairations to a specific set of methods/properties. I think his tool will need to be revamped into another version, that will allow the person to select if the generated includes are for early binding, late binding, or both!! For situations when your linking to running processes, and not just creating new ones....

Japheth?? Wink Wink?? You following this?? ;)
Your probably starting to hate me by now for all this bug snooping :grin:

:alright:
NaN

Hi NaN,

Forgive me for replying so late ;) . Currently other things require most of my attention.

But of course "your wish is a command to me" (literally translated from German).

comview version 1.7.1 has option "generate dispatch helpers for dual interfaces as well" (a silly name, I know, if you find a better one, please tell me). the option is described in more detail in help dialog. possibly this may suffice for your needs.

click here to download

Japheth

Got a Question regarding Windows Stuff:

I wrote an application for work that automated a certain AutoCad task. I designed it at home on my 98SE box, tested and it ran perfectly.

I took it into work and it failed right away on my WIN2000 machine.

I debugged it at work and discovered that the error was from this passage of code (from above):

.data

   align 4

   szStr db "Excel.Application",0

   .code



   ; Get the Class ID dynamically (Not 100% needed)   

   Ascii2Unicode addr Buffer, addr szStr, 128

   invoke CLSIDFromProgID, addr Buffer, addr clsid

Where the MSDN defines it as:

HRESULT CLSIDFromProgID (

[b]LPCOLESTR[/b] lpszProgID, 

LPCLSID pclsid);

I couldnt figure it out at work (with out internet) so i simply hardcoded the key and it took off on the next compile.

Looking at it now my guess is that I need to create a BSTR, by first calling SysAllocString and then converting to WChar.

Is this a correct assumption? Im puzzled why I never got trapped earlier on win98.

:confused:

:NaN:

Thanx Japheth for the clarification.

At work today, i but this to the test, and recompiled it, providing a true BSTR and it worked, where simple a WCHAR string it failed.

This is again on Win2000 tho, so i guess being an NT based system it has its view on this clearly defined.

I should have been... the buffer i used to make the WChar string was 128 bytes long as a LOCAL off the stack. (only other locals were DWORDS).

:NaN: