I wrote a device controller (rs232) and it is being used successfully, however users want to view data and control the device (or perhaps communicate through my program) from Excel. I dismissed DDE as an option and found that RTD (IRtdServer) is probably a good start (though no way to send data back to the "server" from the real time data client).
I found these resources for the RTD part:
http://support.microsoft.com/?id=327215
and
http://support.microsoft.com/?id=327215
This is a multi-threaded app and I had already added the ability to have multiple listeners on the com port so that I could update multiple clients. I will add the COM interface to the EXE.
But what I need after that is some way of controlling my app/proxying commands to the device through my app from Excel.
What would be the best way to do that?
Perhaps another COM interface and calling it from VBA or something? I am not familiar with using scripting from Excel, so perhaps someone can provice sample code or links that show both the code for a COM object and the accompanying VB(A?) code?
Keep in mind that this is an unmanaged C++ application and it cannot be converted to managed or C# right now. Alternatives using C# are welcome as well, but that is a long-term rewrite.
Thanks
EDIT
I have an alternative to adding COM support into the existing EXE. I think it is more flexible to add a two-way communications (cross platform - maybe boost or corba or just straight IP based with my own message protocol)
A COM server (or two) can wrap that communications channel - whatever it is. This doesn;t really affect my question at all - I still would like to know the options for controlling an external EXE from Excel.
EDIT
Not having to roll out .NET to customers is also an big plus. many of these devices are on PCs that are pretty old and have perhaps NT or XP on them and I don't relish increasing my setup/install package from 700KB to the ridiculous .NET install size...
Option #1:
Create a small COM server - make sure its interfaces are suitable for scripting with the built Visual Basic engine in Excel. (e.g. use simple types and BSTRS).
Write Excel VB Macros to (1) add your own tool bar to excel and (2) call your COM server.
You can also add buttons and other UI elements to sheets and hook them them up to VB macros.
Option #2:
I realize that you do not want to use C# - but automating office, and talking to COM objects is really, really easy in C# with Visual Studio Tools for Office (VSTO). You shoul really look into this option - If done correctly, it shouldn't mean re-writing any of your existing code. Just use C# and VSTO as a bridge between Excel and your RTD server. As with VB, its straight froward to connect UI elements in Excel to C# and then to your RTD server.
Calling a COM object from VBA is straightforward. This SO Question and my answer give an example of how to create a COM object. Calling exposed methods is as you would expect:
object.ExposedMethod(optional params...);
Related
Is it possible to use a Go API in a Qt C++ project?
I would like to use the following Google API written in Go: https://cloud.google.com/speech-to-text/docs/reference/libraries#client-libraries-install-go
Is it possible to use a Go API in a Qt C++ project?
It could be possible, but it might not be easy and would be very brittle to run Go and Qt code in the same process, since Go and Qt have very different thread (goroutine) and memory models.
However, Go has (in its standard library) many powerful packages to ease the development of server programs, in particular of HTTP or JSONRPC servers.
Perhaps you might consider running two different processes using inter-process communication facilities. Details are operating system specific. I assume you run Linux. Your Qt application could then start the Go program using QProcess and later communicate with it (behaving as a client to your Go specialized "server"-like program).
Then you could use HTTP or JSONRPC to remotely call your Go functions from your Qt application. You need some HTTP client library in Qt (it is there already under Qt Network, and you might also use libcurl) or some JSONRPC client library. Your Go program would be some specialized HTTP or JSONRPC server (and some Google Speech to Text client) and your Qt program would be its only client (and would start it). So your Go program would be some specialized proxy. You could even use pipe(7)-s, unix(7) sockets, or fifo(7)-s to increase the "privacy" of the communication channel.
If the Google Speech to Text API is huge (but it probably is not) you might use Go reflective or introspective abilities to generate some C++ glue code for Qt: go/ast, go/build, go/parser, go/importer, etc
BTW, it seems that Google Speech to Text protocol is using JSON with HTTP (it seems to be some Web API) and has a documented REST API, so you might directly code in C++ the relevant code doing that (of course you need to understand all the details of the protocol: relevant HTTP requests and JSON formats), without any Go code (or process). If you go that route, I recommend making your Qt (or C++) code for Google Speech to Text some separate free software library (to be able to get feedback and help from outside).
I created a C++ QT application on Linux with a simple visual interface with three buttons. This application runs on a machine with a certain IP address in my wifi network. I want to be able to access such visual interface from the browser of a smartphone and click the buttons.
To accomplish this I used a remote desktop connection, but it's just a temporary solution as I want to be able to access my GUI from any smartphone without the need of installing anything, and also without offering other functionalities... the client should be able to press the three buttons and nothing more.
In other words, I would like to be able to do the following:
After I type the IP address of the linux machine in the browser of my smartphone, a html page opens up with my visual interface with three buttons;
When I press one button, my C++ code starts running in the background;
When I press again the buttons, the C++ app receives the commands and acts accordingly.
And so on until I click the button that closes my C++ App.
Now, is there a way to accomplish this? In a few words, is it possible to have a web interface to act as a GUI for my C++ app? I must admit I am really ignorant in web applications :) But maybe you know about a QT widget that solves my problems.
Thanks!
There are a lot of ways to accomplish this.
A simple way is to use QtHttpServer to talk to the objects inside your Qt Application to do the work you asked it to.
You can quickly get started by adapting the example here to your use case.
You may want to check out https://sourceforge.net/projects/conair/ - this lib allows you to communicate with your c++ qt code via javascript. You would, however, have to replicate your existing qt gui with a traditional web front-end technology - some straight forward HTML and javascript would probably suffice.
I am developing an application on Windows 10 that interacts with custom device drivers, the NTFS filesystem and DirectX 12. The app is a Windows Universal App written in C++, WRL, XAML and DirectX. For DirectX I have chosen a SwapChainPanel control and the DirectX portion of the app works great. The app is Sideloaded so I have a bit more freedom than an app that needs to go through the store
Unfortunately the Windows Universal Apps have a number of restrictions with regards to API calls. WinRt APIs are favored.
Here are a list of WinRt APIs to call to replace Win32 APIs:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
In addition Windows Universal Apps can call Win32 APIs that are partitioned to the application (however not the ones partitioned to the desktop) as indicated in the documentation of each function and in the header file. Here is a link:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
In addition the Winsock APIs are now allowed from Windows Universal Apps
However I am still left without my favorite (and necessary APIs)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
In particular I need to read and write files to all locations without user interaction (and not to the locations restrict by the Windows Universal App Sandbox). In addition I need to send IOCTLs to my multiple device drivers.
I could abandon Windows Universal Apps and go with WPF. However I have a touch intensive application and I need touch to work really well. In addition I have to wonder about the lack of fixes and commitment to WPF on the behalf of Microsoft. I have considered other UI frameworks but none have been as promising as a Windows Universal App.
Microsoft has allowed two paths in Windows 10 for Universal Apps that will allow calling all Win32 functions (For side loaded apps).
Brokered Windows Runtime Component
and IPC though TCPIP
I have written a brokered windows runtime component and it works well. However the solution requires a C# app to be in the mix and I do not need/want that as I need fast load times of the app and do not want to pull the CLR in.
The next option is IPC through TCPIP. I would use Fast TCP Loopback as explained in the blog post: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path. I would link to it but I am at my (very generous) two link limit for a first post.
I have a couple of questions:
1) If I go this route should I place the IPC between the XAML controls/buttons and the rest of the App? This would allow the rest of the app to be strictly Win32. Or should I just place the IPC between the app and calls to the specific functions I need that fall outside of the those allowed by Win32.
2) I have looked for a library or paper that has code and/or ideas for implementing IPC with TCPIP. However so far the papers that talk about IPC with TCPIP seem to simply describe winsock programming which is something I already know how to do. I would enjoy coding up IPC but would prefer a solution that has been tested. This needs to work flawlessly and I would rather have code with some time on it. Has anyone used or heard of code and or a design for IPC over TCPIP that is available to share?
I have a legacy Win32 application (WndProcs, etc) that needs to consume a COM object. With the use of a little ATL headers and some smart pointers that was a snap, however what I'm currently struggling with is how best to sink the events coming off that COM object?
My current working plan has been to build a second COM object (as a dll) that handles all the sinking and uses windows messages to communicate with the legacy application. This is "ok" but there's a lot of cruft moving messages back and forth to make the legacy application do what I want.
Is there a readily accessible way to get the Win32 legacy application to sink COM events directly vs running through the second "sinker" com object?
Before I go to far down this process I wanted to see if anyone else ran across this before and had a working solution.
Thanks!
Stumbled across this excellent write up by the always brilliant Raymond Chen.
http://blogs.msdn.com/b/oldnewthing/archive/2013/06/12/10425215.aspx
As WhozCraig indicated above, all I needed was the Interface pointer and to setup the Advise, handle the Invoke.
Nice and clean.
Thanks!
I'm currently working on a cross-platform application (Win/OSX/iOS) which has a C++ (with Boost) back end. On iOS and OSX I'm using the Cocoa Net Service Browser Delegate functions to discover an embedded device via mDNS, then pass the information to the back end to create the objects it needs to communicate with it.
I wanted to take a similar approach with my Windows MFC front end and I found this article which seemed to do exactly what I want. However, it seems that using the Bonjour SDK has some really nasty side effects - forcing you to static link to MFC and in my case the only way I can get it to link properly is to not use debug DLLs at all, which is not ideal.
So, the Bonjour SDK isn't really any good for me because it imposes too many restrictions on my project. With Cocoa I'm actually using very little of the functionality - just didFindService and netServiceDidResolveAddress really. All I want to do is find the devices of a given type and get their IP addresses.
Can anyone suggest another way around this that will work with an MFC front end on Windows?
From what I have been able to gather from researching this topic just goto http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-333.10/ and grab the source. There is a VC project file which will let you build the dll how you want.