Hi. We have an embedded box connected to a VB application on a PC. The embedded box communicates using TCP. I am thinking of using an ActiveX object to be an interface between the box and the application. This way, the ActiveX takes care of all the application protocol (and socket etc.) stuff and exposes a neat interface to the host application (events, methods etc.).
Do you think this is a good approach and is ActiveX a good choice?
Thanks
Hello !
Write a C/C++ DLL that takes care of the communication. ActiveX objects register and publish themselves on a system-wide basis, and I don't think it's truly necessary to do that in here. Unless, of course, you want multiple applications to be able to access your device simultaneously.
Even if this was the case, I would instead write a well-defined COM object. ActiveX and COM are, in basis, very much alike, with the exception of COM lacking the scripting interfaces. The problem will be that a COM object without a scripting interface is not easily accessible from a Visual Basic program.
So, if the host program is written in Visual Basic, I'm afraid the ActiveX is pretty much your only choice, unless you write a C/C++ DLL and attach it into the VB software. Using ActiveX might expose some security vulnerabilities in your software, but if those are not an issue (the computer is an isolated one) then feel free to use this approach.
- Antti Keskinen
Yes, we had considered a DLL but decided against it for the following reasons:
1) Our host is VB and an ActiveX is easier to use 2) A DLL is not suitable for an event-driven design (it does not have events like a ActiveX does) 3) Suppose I want to control multiple embedded "boxes" and each requires its own ActiveX, it is easy to create copiesWhat do you think?
ActiveX and "embedded" do not belong in the same sentence. You are condemned to platform-dependence if you use ActiveX.
No, you are mixing up two things. "Embedded" is the system ("box"). It talks TCP. TCP can talk to anything. In this implementation, the host is Windows. So in this context we want to use an ActiveX. There is (IMHO) no contradiction here.
How do you deliver that ActiveX control? By embedding it in a page on the device?
BOX PC
where in the PC:
Socket < ---- > ActiveX < ---- > Application
Get it?
So you're reduced to writing another piece of code from scratch when you need to support a different operating system on the host side.
Yes. But the considerations here (for me, now at present time):
You can use a DLL and have an "event-driven" design by providing the dll with an hWnd to post messages to when events occur, and handling those messages in your main program, or by providing the dll with callback functions to call when events occur ( although I don't know easy that would be to implementt in VB). However, I like polling the dll from the main program every 100 msec or so. It's easy to do and that way you can avoid the potential headaches associated with having multiple threads running.
I've used the dll approach similiar to what was described by Antti Keskinen extensively and it has worked well for me. I like to write a dll that does the "real" work, and then write a wrapper if required by the client for his application. If an additional thread is required I put it in the wrapper after the low-level stuff has been debugged by using the polling method.
Note that when I say "dll" I mean a dll that is not an ActiveX control. An ActiveX control (or COM object) may be a dll also.
an applicable story:
a few years ago i was brought into a project that was already underway. the project hardware was a rack full of motors, temp and pressure sensors, and etc. the rack was my deal and i connected the stuff through a national instruments analog and digital board. using the national DLLs i got everything working under visual C++.
the problem was that the database interface application was already started in VB 6 and they required it to stay in VB.
so i rolled everything into an OCX (Active-X) and dropped the OCX into the VB and got it working for the VB guy.
the only problem was that the VB app would occasionally vaporize within a few hours in a random manner. The exact same functionality worked fine when the OCX was dropped into a Visual C++ server app and run for days!
something deep in VB would cause a GP fault eventually.
That experience permanently soured me on the OCX/VB paradigm.
beware..
Chris
I used this very same approach for a recent project and it worked very well. I used NI's Measurement Studio to make a nice looking front end interface in VB.
Of course, there are the platform dependence and quirks of ActiveX, but this was not an issue for my applicati> Hi. We have an embedded box connected to a VB application on a PC. The
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.