|
That's a known error. Don't forget that depending on what libraries you link with, the DLL when loaded for registration may be automatically trying to load sister dlls, and in this case may not find one of them.
For instance, if you link with winwin.lib with at least one method implementation taken from it (_dllimport), and winwin.dll does not exist, then registration fails.
The error message tells you that's about the main dll, while it's not !
|
|
|
|
|
Hi All,
Anybody know of a way to get the interface of an existing in-proc ATL COM object that has been cocreated in a separate process? I know the name of the .exe that has an instance of the object, and I would like to grab the interface pointer to the existing object to register for events.
Thanks in advance,
Aaron
|
|
|
|
|
Option 1 : writing code properly
Looks like you should use COM aggregation. In other words, the .exe must republish the interface published by the ATL COM object.
ATL provides good classes for this purpose (CInnerUnknown, InternalQueryInterface(), ...).
Of course it assumes that you are able to recompile the .exe
|
|
|
|
|
Option 2 : use dirty windowing
Nothing prevents you to add windows messaging between your client .exe and the other .exe.
For this purpose, all you have to do is, inside the ATL code, create and attach a unique window when the ATL COM object is created and attached to the .exe
And then, from your client .exe, just find this window (::FindWindow(...)) and start doing ::SendMessage() to it.
That's dirty coding, but that's how a lot of software work on Windows.
PS : windows messaging is fine for event subscription.
|
|
|
|
|
Well, basically, the object that I need information from has a bunch of containers. These are just STL containers wrapper in COM interfaces, but they are sort of invisible now. I need to be able to display the state of these containers. This is just for debugging.
Maybe some scenario like this, sort of:
The .exe creates an instance of my object. In the final construct, I would like to be able to fire up a window with a grid in it, that is updated by my in-proc ATL object, to display the internal state of this object as it is operated on by its host .exe. The events indicated contained data has changed. So the view of the object needs an interface to query the contents of the internal containers to the object each tim they are changed. That make sense? Since this is only for debugging the object itself, I don;t want to change any code in the host .exe itself.
Maybe I should just create another COMO object, this one an .exe server, and keep the interface to that one in my in proc object? Also, I need to make use of some MFC dependent stuff in the "view" object, and have been having some trouble donig this in ATL code. They don't seem to mix. Basically, I just need a big window/dialog box that I can communicate with via an interface
Thanks,
Aaron
|
|
|
|
|
"Maybe I should just create another COMO object, this one an .exe server"
Actually, what you want to do is to convert your in-proc object to a local server. Then you can have multiple processes accessing the same process space. Each will have a seperate instance of the object. So info that is to be shared, must be global between the instances.
This is the architecturally sound way of doing what you want. ATL vs MFC makes no difference in the basic architecture. You can do this with either framework.
|
|
|
|
|
How do I create an .exe server in MFC? Something with a GUI?
|
|
|
|
|
Using the app wizard:
Create a new MFC exe project.
On the 3rd page select the Automation checkbox.
Complete the wizard.
Use the class wizard, automation tab to add a new COM interface to the project. You can base the new class on COleServerDoc or COleServerItem. From there it gets a little complicated.
1. My recommendation is to build the .exe as an ATL app.
2. d MFC support to the project.
3. Add a COM interface using the Insert New object menu item.
4. Port your existing code into the new object.
If you are clever enough, you can skip step 3 and simply add your existing COM object classes to the ATL project.
|
|
|
|
|
You can register your objects, which you need to debug, in ROT and can have the access from any client.
RegisterActiveObject and RevokeActiveObject in server.
GetActiveObject in C-client or GetObject in VB-client.
With best wishes,
Vita
|
|
|
|
|
OK, once the object is registered in the table, how would I get its interface from the other (client) .exe? The CLSID in the call is just the CLSID of the object in the atl .dl, and the same CLSID used in the call to RegisterActiveObject?
Thanks,
Aaron
|
|
|
|
|
In server:
RegisterActiveObject(pYourObj, CLSID_YourObj, ACTIVEOBJECT_STRONG /*or TWEAK*/, & dwYourObjCookie); in your object's constructor or FinalConstruct().
RevokeActiveObject(dwYourObjCookie, NULL); in your object's destructor or FinalRelease().
In client:
GetActiveObject(CLSID_YourObj, NULL, & pYourObj );
Advise and etc.
With best wishes,
Vita
|
|
|
|
|
You can't do that. An in-proc server runs in the process space of its client. An EXE in another process can get a raw interface pointer through black magic (or the two EXEs communicating if you write them both), but the pointer from EXE 1's process space is useless in EXE 2's process space.
You'll need to make the COM server a local server (its own EXE) which is the correct way to do what you want.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Well, I was afraid of that. There's no way to marshall the interface from the in-proc object to the second .exe?
I assume though, that there is no reason not to use the automation interface from inside the in-proc .dll. This seems to work fine. I'm afraid if I were to make the original object a local server, I would add to much overhead to it, since the method calls would have to be marshalled between processes, and I can't afford to make it any slower.
Thanks,
Aaron
|
|
|
|
|
One way that's almost legal COM that you could try (if you can modify the exe containng the CoCreated object) would be to add the object to the Running Object Table (ROT, to it's friends) & get it from there. However, make sure the process containing the object doesn't die while it's in use & also make sure that only one instance of the EXE runs, unless you have some mechanism for naming the objects differently in the ROT.
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
To start off I will show the code then explain the problem.
<br />
class A<br />
{<br />
public:<br />
void MethodOne() { MethodTwo(); }<br />
void MethodTwo() { TRACE("Hello from A\n"); }<br />
};<br />
<br />
class B : public A<br />
{<br />
public:<br />
void MethodTwo() { TRACE("Hello from B\n"); }<br />
};<br />
<br />
<br />
void UsesClass()<br />
{<br />
B* b = new B;<br />
b->MethodOne();<br />
}<br />
What I want is for MethodOne() from A to call the MethodTwo() from B. What it does is call the MethodTwo() from A instead. How do I get the MethodTwo of B to be called?
Cheers,
Clint
|
|
|
|
|
make MethodTwo "virtual"
-c
Faith is the quality that enables you to eat blackberry jam
on a picnic without looking to see whether the seeds move.
|
|
|
|
|
|
change the code to this (note the 'virtual' modifier):
class A
{
public:
void MethodOne() { MethodTwo(); }
virtual void MethodTwo() { TRACE("Hello from A\n"); }
};
class B : public A
{
public:
virtual void MethodTwo() { TRACE("Hello from B\n"); }
};
void UsesClass()
{
B* b = new B;
b->MethodOne();
}
|
|
|
|
|
|
How do get the application path in mfc? I used fopen and CFile to try and open "out.txt" how ever it shows up in the system 32 directory instead of in the .exe running directory, any thoughts?
|
|
|
|
|
Lookup info on GetCurrentDirectory. I think that should get you what you want. There maybe some other SDK functions which are better suited. See if this helps.
|
|
|
|
|
char buf[MAX_PATH+1];
DWORD res = GetModuleFileName(AfxGetInstanceHandle(),
buf,
MAX_PATH);
}
-c
Conservative:
Faith is the quality that enables you to eat blackberry jam
on a picnic without looking to see whether the seeds move.
|
|
|
|
|
|
burn fopen and CFile and use C++ file reading, specifically ifstream.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Christian Graus wrote:
use C++ file reading
what does this offer that C-stream I/O (fopen and pals) doesn't? (besides being shiny and new)
-c
Faith is the quality that enables you to eat blackberry jam
on a picnic without looking to see whether the seeds move.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
