Interop: C++ Console & C# GUI

[Sheikko]

Sincerly is a little bit complicated to explain to you what I have in
my
mind, but I will try:

Above all the problem is the type of data that I want to passe between
these two applications. The complete application that I want to create
consiste of two applications:
- the console developped with VS C++, that use some libraries
developped with Borland C++
- the GUI of application that interact with the console.

The GUI must access some methods included in libraries and exposed by
the console, and the internal libraries throught the core application
must interact with some methods of GUI, for example to refresh some
controls.

I have thinked to to link GUI with WebService "A" that communicate
with Console, and to link Console with WebService "B" that communicate
with GUI. In this way it's possible to make a bidirectional
communication.... But. But this is not very simple to do. And sincerly
I don't know how I can do it, above all because I don't know how I can
use the GUI/Console from the WebService.

Every suggestion/solution is welcome... and thanks in advance to all
those they want ot help me.

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

"Sheikko" wrote:

Sincerly is a little bit complicated to explain to you what I have in
my
mind, but I will try:

Above all the problem is the type of data that I want to passe between
these two applications. The complete application that I want to create
consiste of two applications:
- the console developped with VS C++, that use some libraries
developped with Borland C++
- the GUI of application that interact with the console.

The GUI must access some methods included in libraries and exposed by
the console, and the internal libraries throught the core application
must interact with some methods of GUI, for example to refresh some
controls.

I have thinked to to link GUI with WebService "A" that communicate
with Console, and to link Console with WebService "B" that communicate
with GUI. In this way it's possible to make a bidirectional
communication.... But. But this is not very simple to do. And sincerly
I don't know how I can do it, above all because I don't know how I can
use the GUI/Console from the WebService.

Every suggestion/solution is welcome... and thanks in advance to all
those they want ot help me.

For starters, I would have two executable projects (the console and the GUI
app) and a dll project (for the common code).

In this way, the GUI can make calls to the console logic by linking to a
reference to the common dll and calling object methods.

It's not clear if the GUI is talking to your console app in any way. Going
the other way is desired it appears. There are many options. Probably the
simplest to code is for the console app to put some message in a file that
the GUI code is monitoring. When the contents of that file have changed, the
GUI code makes some decision on updating controls.

Its not clear from your post why the console app is needed. It would seem
that if the GUI is a display of the state of the running console application,
that the two could exist in one executable. Are you sure you couldn't change
the console application to a callable method from the GUI?

Lastly, you posted this separately to many groups. You should post to all
groups in one post so that the replies go to all groups.

[Khalid]

On 17 Dic, 13:13, Family Tree Mike
<[e-mail]:

"Sheikko" wrote:

Sincerly is a little bit complicated to explain to you what I have in
my
mind, but I will try:

Above all the problem is the type of data that I want to passe between
these two applications. The complete application that I want to create
consiste of two applications:
- the console developped with VS C++, that use some libraries
developped with Borland C++
- the GUI of application that interact with the console.

The GUI must access some methods included in libraries and exposed by
the console, and the internal libraries throught the core application
must interact with some methods of GUI, for example to refresh some
controls.

I have thinked to to link GUI with WebService "A" that communicate
with Console, and to link Console with WebService "B" that communicate
with GUI. In this way it's possible to make a bidirectional
communication.... But. But this is not very simple to do. And sincerly
I don't know how I can do it, above all because I don't know how I can
use the GUI/Console from the WebService.

Every suggestion/solution is welcome... and thanks in advance to all
those they want ot help me.

For starters, I would have two executable projects (the console and the GUI
app) and a dll project (for the common code).

In this way, the GUI can make calls to the console logic by linking to a
reference to the common dll and calling object methods.

It's not clear if the GUI is talking to your console app in any way. Going
the other way is desired it appears. There are many options. Probably the
simplest to code is for the console app to put some message in a file that
the GUI code is monitoring. When the contents of that file have changed, the
GUI code makes some decision on updating controls.

Its not clear from your post why the console app is needed. It would seem
that if the GUI is a display of the state of the running console application,
that the two could exist in one executable. Are you sure you couldn't change
the console application to a callable method from the GUI?

Lastly, you posted this separately to many groups. You should post to all
groups in one post so that the replies go to all groups.

Beacause I want to run the console on a Pc and the GUI on a second Pc.
So I need to make communication between them

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

Its not clear from your post why the console app is needed. It would seem
that if the GUI is a display of the state of the running console application,
that the two could exist in one executable. Are you sure you couldn't change
the console application to a callable method from the GUI?

Beacause I want to run the console on a Pc and the GUI on a second Pc.
So I need to make communication between them

OK, I think that is missing from your original post. You should look at the
many examples of .Net Remoting available on the web.