I am looking for some information on how to achieve something with libraries in C++ and c#.
What I would like to know is how to approach the following problem:
C# application: -has a window
C++ library: -has a function called create_button(x,y), when
invoked, it will create a button on
the c# application's window. (if the
C# application is not running,
nothing will happen)
C++ application: -dynamicaly links to the C++ library and calls the create_button()
function.
How would I approach this problem, I would be glad to hear some of your ideas.
The platform is windows. My question is, how would I let the C++ library communicate to the c# application to create a new button? Is it linked, sockets, ... I'm particulary thinking of GTK+ in linux, you link to the gtk+ library, but how does the library interface with GNOME to create a new window etc, something like that. I'm not interested in writing dlls and linking those to a c# application, I'm interested in creating an in-between library.
I can't think of any sane way to do what you want to do. What I believe you should be doing is creating functions to do the drawing in the C# app and then exposing some messaging interface, such as a socket, that allows external apps to send messages that command the C# app to do what you tell it. When the C# app receives messages of with message type DRAW_BUTTON, it draws the button, with whatever parameters were specified in the message it received.
You're going to run into problems here since C# is managed and C++ is native. As far as I know, the only way of calling native code from managed in the CLI is by using the P/Invoke layer, in which case you would need to import a DLL, write a prototype, etc.
In addition, I believe that the P/Invoke calls are to C functions, and not C++, although you can get past this by adding a C library to call into which in turn calls your C++ library.
If you can create a small but proper HWND in C# (don't know the widget), you can use that and create a c++ window using the C#'s window as parent.
We did exactly this a few years ago for a java/c++ process pair. However, the Java app could report the HWND value to the c++ app over RPC, so it wasn't that hard to setup.
Given that you control the code of the C# application and you control the code of the C++ application and, presumably, the 'in between library'. I find myself asking "why are you doing it like this?"
If you want the C++ app to be able to cause the addition of a given button on the C# app and for the press of that button to be able to communicate with the C++ app then, personally, I'd use standard IPC and have a communications channel between the C++ app and the C# app and simply have the C++ app ask the C# app, via IPC, to display the button and then have the C# app send whatever detail (most probably the fact that the button was pressed) to the C++ app via the same IPC channel.
If this route wont work then I think you need to clarify the problem that you're trying to solve as at present I think your current 'solution' is on the wrong track and so an answer telling you how to achieve your current 'solution' would be misguided.
Related
I have a task to do: I have to write a graphical (window) application in .Net which is going to read temperature from the three sensors (namely MCP9808, SI7051 and STS31-DIS) connected via MCP2221 I2C/USB converter and display it on the screen.
There are some requirements: The app has to be graphically estetic, it has to have the some buttons (eg for the periodic read of the temperature) and it has to display a chart showing the temperature variations.
I know that .Net usually comes with C# but I've never used it before and also the libraries for the MCP2221 are for C++ as I believe.
Could anyone help me how to get down to this problem?
If you really need to use .NET for your GUI (WPF or WinForms), you should consider .NET interoperability, which allows you to call C++ compiled code from your .NET code.
Here is another StackOverflow post that should help you:
How to call C++ DLL in C#
If you want to use C++ syntax only, there is also C++/CLI.
We would like to open some Delphi (win32) forms from .NET and embed the Delphi Form in a .NET MDI-form.
If we just call the exported method in our Delphi DLL it is no problem to embed the form, however then we have problems with shortcuts and keyboard events in general. We believe that it’s because of incompatible messageloops.
We’ve then tried to execute an Application.Run in the exported procedures in our Delphi DLL’s on a separate .NET-thread and it works the first time, but fails when we try to open the form more than once.
Does anyone know how to interop the way we would like to do it: embed a win32 Delphi Form in a .NET Winform?
#All: First of all, thanks for your responses
We found a solution to our problem: We moved the Delphi Application.Run into the exported procedure that starts the windows.
If you have the source, you could try porting it to Delphi Prism, which generates .NET code. Although, if you're using the VCL, you're fighting an uphill battle. Whereas Delphi 2006 had a .NET implementation of the VCL, Prism is just Object Pascal for .NET with no VCL adapter.
Another tool that is available is Hydra I haven't used it personally, but they claim to provide interop between .NET and "legacy" Delphi. If it works as they claim it does, it might be your best bet for transitioning your old Delphi code to a .NET application.
I would probably run the Delphi application in a separate process, set the parent window for the Delphi windows to your MDI container (instead of the default: the desktop, referenced by HWND 0), and marshal any necessary data between processes using typical inter-process messaging.
Then again, this is essentially the same as exposing your form as an ActiveX object. I just like to take Google Chrome's approach and isolate windows/tabs into separate processes.
I have a 3rd party application, which creates several windows of which each has a textbox with text I want. I then want to use that information within my application, so I just need to obtain that information (possible trigger some commands back to it later on by pressing buttons)
The 3rd party application is un-managed C++.
My application is C# (.NET 4.0).
I have seen that you can do 'hooks' into other application but I'll be honest I am completely lost of which route to take and how to go about it.
Some advice would be great.
I wonder if all this talk of managed code and unmanaged code and Interop isn't a red herring. Are you able to interface with this other app at all or are you just going to have to use FindWindow to find that other app and then enumerate it's child windows till you find the text boxes you're after, then just call GetWindowText ?
You will need to use COM interop. More here
http://msdn.microsoft.com/en-us/library/aa645736%28v=vs.71%29.aspx
http://www.liensberger.it/web/blog/?p=323
The easiest interop with an unmanaged C++ is via C++/CLI. If there's already a simple C wrapper then P/Invoke will be sufficient.
Using ExternalInterface in AS3 is it possible to call OS (C#?) functions within XP?
Example: Set the desktop background to a image supplied by a flash app?
If it is possible would it be different calls when applied to different OS. And what about cross over the Mac?
Any information would be great
Thanks
If you're launching the swf from within a C# app, external interface will do just fine. Nothing will change on the flash side, but you'll need to go through a couple hoops to get it to work in C#. It's not as simple as AMF or External Interface to JS.
All the communications to C# get converted to XML describing the data, and you've gotta write XML to send back to flash. Other than that though, its relativly simple.
Here's some info on how to do it. The AS portion is Flash 8/AS2, but the C# portion should say the same.
When working with Flash from a webpage or as a desktop app, you are limited to a small security sandbox and you will not be able to make any relevant OS call. I thought that switching to AIR would give the developper more flexibility but it doesn't seem correct either. From "The Pros and Cons of Adobe Air":
AIR apps have
file access, clipboard access, support
multiple windows, support drag and
drop, and can trigger notifications
(toast in Windows). If you app needs
to interact with the desktop in other
ways, the chances are that AIR is not
suitable. For example, there is no
access to COM automation, and no way
to execute external applications. The
reason is to maintain cross-platform
compatibility. That's a worthy goal,
but it would be good to have a way out
of the sandbox. Unlike Java or .NET,
you cannot extend AIR with custom
native code libraries. Nor can you
call operating system APIs.
As Alex Jillard commented, if your swf is called inside a C# desktop application, you should be able to access more OS funcionalities although I'm not sure how.
You could use as already mentioned AIR. Another idea would be to use HippoHX (I haven't written this, the similarity with my username is just coincidence). It runs on top of the NekoVM and gives you unrestricted (so no limitations like in AIR ) access to the system.
I got a quick question about running a directX application (C++) in a managed environment. I'm attempting to write a MDI tool (in C#) where the background of the parent window would be an embedded render window of directX (C++).
I've read ways that involved writing the C++ into a native dll, however it would be prefered to be able to have the C++ projects included within the solution (I dont even know if that's possible though). Eitherway, if you know of some helpful steps, hints, or if this is a bad idea in general, please let me know. Thanks!
The easiest way to do this would be to add a C++/CLI project to your solution. This would then enable you to use the DirectX COM interfaces directly and create a managed wrapper that's easy to call from your C# code. I've taken this approach a few times and it's by far the easiest way of mixing DirectX and .Net that I've ever tried. Managed DirectX used to be an option, but it's no longer supported and it was a fairly small subset of the full COM API anyway.
First of all writing the C++ part in a different dll file doesn't mean that it couldn't be at the same solution as the C# project.
In order to use native DX to render on a managed window you need to pass the HWND window id (use form.WindowId.ToInt32) to the C++ D3Ddevice c'tor. after that each time you'll render using that device it would render on the .NET window.
To do this you probably need two saparate projects - a C++ dll & .NET project. use COM wrapper or p-invoke to pass the HWND to the C++ dll.
If you don't want to spend too much time on writing C++ code for DirectX, you can consider using
SlimDX, since Managed DirectX 1.0 is out of the question, where as 2.0 never leaves the beta and later replace with XNA which has quite different from DirectX itself, and require you to install XNA Game Studio
SlimDX is the opensource version of managed directx with slightly different API and internal structure, but it's easy to use. The recently released version is very stable. I'm currently using it to write a production application.
SlimDX
Managed DirectX