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.
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.
I have developed a window based application based on Native calls. In this application I am handling lots of mouse events, keyboard hooking, painting etc.
My question is that how can I use that win32 application (Unmanaged) in C# .Net?
I have read about the managed wrapper to wrap up win32 application, if you think this is the best option then please suggest me any book or reference of tutorial which can help me to move forward. Otherwise suggest any other option which you think is best in this situation.
Thanks in advance.
at least you can use your .dll through COM Interop.
You have several options if you want to 'control' one application from the other, where one is Native and the other is Managed.
Have you cosidered using named-pipes to 'control' your application?
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 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.
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