|
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.
|
|
|
|
|
How can I get a member variable associated with a control on a dialog?
I've used the Class Wizard in an attempt to add a member variable associated with the control to no avail. The only way I can transfer the data from the form to the variable is via 'GetDlgItemText' and 'GetDlgItemText' doesn't work with Radio (AKA: Option) Controls.
All the controls I've placed on the form will not accept member variables with its associated class functions (ie: text box = edit1.text, edit1.GetLength, etc.)
I have to create member variables through the 'Class View' pane and they're not associated with any particular control.
Can anyone help?
(I can do it VC++ 6.0 but not EVC++ 3.0.)
|
|
|
|
|
open the dialog in the resource editor. Select the control. hold the contrl key down and double click. A wizard will appear asking for the name of the variable you want to associate with the control.
|
|
|
|
|
Full of glee I used an edit control to test it out. It didn't work.
I totally believe you; however, all I get is a messagebox saying "There are no data types for this kind of control." MB_OK.
I'm using a dialog interface, if that helps. It's also doing the same thing on my laptop and desktop PC. Does the installation of VC++ 6.0 and EVC++ 3.0 installed on the same machine hinder 3.0 for some reason? I would think not but one never truely knows.
Carl
|
|
|
|
|
Hmmmm. Maybe that's not it...
I tried it on my machine to verify. Hold control key. Double click control in dialog editor. Up comes small dialog asking for member variable name and type.
I don't know about EVC++ 3.0. What is it? Did the dialog editor build a class for the dialog? Can you see it in the Class Wizard?
Maybe the .clw file is hosed. You can try deleting it. Then run the Class Wizare. It will prompt and then rebuild it for you.
Good luck.
|
|
|
|
|
CTRL - click^2 works in VC++ 6.0.
I'm using Embedded Visual C++ 3.0 for WinCE.
I'll try deleting the .clw file and see what happens. ALthough I doubt that will fix it - this behaviour happens on all the PCs I try this with.
Added:
Oh, and thanks for your help. 
|
|
|
|
|
Yeh, I expect that won't help either, just a desperate attempt to sound smart on my part. I did find this on Win CE development, however.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcguide/htm/appwzrd_5.asp
It may help. I notice they do NOT refer to the class wizard.
|
|
|
|
|
The CComVariant class in ATL has the following functions
CComVariant(LPCSTR lpszSrc)
{
vt = VT_EMPTY;
*this = lpszSrc;
}
CComVariant& operator=(LPCSTR lpszSrc)
{
USES_CONVERSION;
InternalClear();
vt = VT_BSTR;
bstrVal = ::SysAllocString(A2COLE(lpszSrc));
if (bstrVal == NULL && lpszSrc != NULL)
{
vt = VT_ERROR;
scode = E_OUTOFMEMORY;
}
return *this;
}
Which means the only way to get it to allocate memory for a new object is to use the assignment operator. The following code produces different results
char buf[256] = "test";
CComVariant result = buf;
char buf[256] = "test";
CComVariant result;
result = buf;
discuss!
Todd Smith
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
