C / C++ / MFC

Aaron Schaefer14-Aug-02 10:22

14-Aug-02 10:22

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

Confused | :confused:

Thanks,

Aaron

Bill Wilson14-Aug-02 10:45

14-Aug-02 10:45

"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.

Aaron Schaefer14-Aug-02 10:48

14-Aug-02 10:48

How do I create an .exe server in MFC? Something with a GUI?

Bill Wilson14-Aug-02 13:25

Use the ROT for debugging

14-Aug-02 13:25

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.

Vi214-Aug-02 20:34

Vi2

14-Aug-02 20:34

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

Re: Use the ROT for debugging

Aaron Schaefer15-Aug-02 3:09

Re: Use the ROT for debugging

15-Aug-02 3:09

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

Vi215-Aug-02 3:31

Vi2

15-Aug-02 3:31

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

Re: Get COM interface from other process

Michael Dunn14-Aug-02 15:00

Michael Dunn

14-Aug-02 15:00

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

Re: Get COM interface from other process

Aaron Schaefer15-Aug-02 3:05

Re: Get COM interface from other process

15-Aug-02 3:05

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

Stuart Dootson14-Aug-02 20:49

Stuart Dootson

14-Aug-02 20:49

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'

Calling methods in child classes from base class?

clintsinger14-Aug-02 9:30

clintsinger

14-Aug-02 9:30

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

Re: Calling methods in child classes from base class?

C^hris L^osinger14-Aug-02 9:36

C^hris L^osinger

14-Aug-02 9:36

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.

image effects!

Re: Calling methods in child classes from base class?

clintsinger14-Aug-02 10:08

clintsinger

14-Aug-02 10:08

Thanks

Re: Calling methods in child classes from base class?

moredip14-Aug-02 9:48

moredip

14-Aug-02 9:48

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();
}

Re: Calling methods in child classes from base class?

clintsinger14-Aug-02 10:09

clintsinger

14-Aug-02 10:09

Thanks

Stupid Question

John Pepper14-Aug-02 8:47

John Pepper

14-Aug-02 8:47

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?

Ranjan Banerji14-Aug-02 8:57

Ranjan Banerji

14-Aug-02 8:57

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.

C^hris L^osinger14-Aug-02 9:00

C^hris L^osinger

14-Aug-02 9:00

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.

image effects!

Anonymous14-Aug-02 9:36

Anonymous

14-Aug-02 9:36

Thanks!!

Embedded C++ 3.0 Member Variables

Christian Graus14-Aug-02 12:53

Christian Graus

14-Aug-02 12:53

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

Philsophical Question

C^hris L^osinger14-Aug-02 13:27

C^hris L^osinger

14-Aug-02 13:27

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.

image effects!

Like2Byte14-Aug-02 8:28

Like2Byte

14-Aug-02 8:28

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.)

Re: Embedded C++ 3.0 Member Variables

Bill Wilson14-Aug-02 8:50

Re: Embedded C++ 3.0 Member Variables

14-Aug-02 8:50

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.

Like2Byte14-Aug-02 9:22

Like2Byte

14-Aug-02 9:22

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

Re: Embedded C++ 3.0 Member Variables

Bill Wilson14-Aug-02 9:50