Two VB applications working together advice ?

1st application controls the XRF analyzer and deconvolution data processor, data recorder, web interface, graphics, and user interface.

I have a hardware device that runs the flow system, but it fires events (Actually its driver fires events) into VB that I have to service ASAP or lose the data. Servicing this event INSTANTLY is very disruptive, and makes the main program run erratically. I want to write a small application that will service this flow control device, deal with the instant event service issue, accumulate all the data and save it to files. To give you an idea of timing, this flow control device needs to open/close valves, start/stop motors, and write data files once every 15 minutes. It does monitor the flow volume accumulation at higher speeds, like 5 or 8 times a second. And it has a ton of other capability we don't use, which is why its interface driver is designed to be so demanding.

So now my question, how can I make the small application communicate with the 1st application ? The communication could be very casual, like once every 15 minutes it signals the main (1st) application " Hey, flow system worked fine for 15 minutes, data files are written " Or " Hey, I've got an error with Valve 2 " Or " Hey, I'm ready to start running the flow now...."

How do VB application talk to each other like this ? Perhaps the 1st application could launch the 2nd one ? And I'd probably like the 2nd small application to run in the background, maybe with an icon in systray. BTW I'm using Win 7 Pro. I'm not sure which is the best approach since this is not high speed data exchange with reams of data arrays and such...All of the data files are ASCII text files.

One app writes to a local log file and second reads from it...

I would probably code the 2nd app as a COM-server (activex-dll or activex-exe). In that case you just have to set a reference to the 2nd app in your 1st app, and the 2nd becomes an object you can use like any other object including its events the 1st app would be able to receive

Quote:

---

Originally Posted by Zvoni

I would probably code the 2nd app as a COM-server (activex-dll or activex-exe). In that case you just have to set a reference to the 2nd app in your 1st app, and the 2nd becomes an object you can use like any other object including its events the 1st app would be able to receive

---

" So no matter how busy the 2nd tiny app gets with all the events fired by the driver, it won't impact the 1st larger app ? I was thinking .exe also, since there are times you might
want to run the 2nd tiny app for troubleshooting purposes...."
Someone here also mentioned DDE ( Dynamic Data Exchange ). Would that be over kill ? I only need to read the flow data file, I don't need real time data.

Quote:

---

Originally Posted by Zvoni

I would probably code the 2nd app as a COM-server (activex-dll or activex-exe). In that case you just have to set a reference to the 2nd app in your 1st app, and the 2nd becomes an object you can use like any other object including its events the 1st app would be able to receive

---

Can you post a simple example of this? I too am looking for a two-app cross communication set up. My first thought was to have both apps communicate with each other by using SenMessage API but I like your idea of using ActiveX.

You can either incorporate something like a timer in your 2nd app to prevent it firing realtime events, or you could do it the way RB told you, again with a timer in your 1st app.

DDE is officialy a dying branch of exchanging data.... :-)

Quote:

---

Originally Posted by prginocx

" So no matter how busy the 2nd tiny app gets with all the events fired by the driver, it won't impact the 1st larger app ? I was thinking .exe also, since there are times you might
want to run the 2nd tiny app for troubleshooting purposes...."
Someone here also mentioned DDE ( Dynamic Data Exchange ). Would that be over kill ? I only need to read the flow data file, I don't need real time data.

---

DDE could work but it is very outdated technology. I used it once and was very pleased with the results.

Quote:

---

Originally Posted by jmsrickland

Can you post a simple example of this? I too am looking for a two-app cross communication set up. My first thought was to have both apps communicate with each other by using SenMessage API but I like your idea of using ActiveX.

---

Sorry, JM, but i have to leave that for someone else, since i'm out of office as of now (on my ipad right now), and i'm preparing for a 4-day trip to an Open-Air-festival (Iron Maiden headliner), so the first i would be able to do something would be next tuesday, but i'm pretty sure that some of the guru's here can give you some pointers :-)

Quote:

---

Originally Posted by Zvoni

Sorry, JM, but i have to leave that for someone else, since i'm out of office as of now (on my ipad right now), and i'm preparing for a 4-day trip to an Open-Air-festival (Iron Maiden headliner), so the first i would be able to do something would be next tuesday, but i'm pretty sure that some of the guru's here can give you some pointers :-)

---

"l'll post here when I get the ActiveX ocx control working, but I wouldn't hold your breath..."

Quote:

---

Originally Posted by prginocx

"l'll post here when I get the ActiveX ocx control working, but I wouldn't hold your breath..."

---

LOL no, nothing like that. I really am in my prolonged weekend now.
as for starters: COM-servers need public classes with public events, methods and properties, which you can then access from your calling app once you've set the reference

oh, and it has nothing to do with OCX. I've never coded an OCX in my life, but i do have some experience with activex-dll/exe

EDIT: one of the most famous ActiveX-exe COM-servers is actually Excel. If you go to your references and check the "Excel object library" you will see that it actually refers to "excel.exe"

One great option often overlooked is MSMQ.

MSMQ private machine queues are easy to create, use, and destroy. All you need to do to prepare is to be sure you have this optional Windows component installed, since in most non-server versions of Windows it is left out when you install Windows. But you can add it via the "Add/Remove Windows Components" or "Turn Windows features on and off" dialogs that are options within "Add/Remove programs" in most recent versions of Windows client OSs.

The basic idea is that a queue can be created and then programs can insert messages into this queue, and they pile up there until processed. Such queues can be temporary or persistent (data retained across reboots). Another program can remove messages from the queue and process them. While running the program can also get notifications that new messages have been queued.

As long as the queue exists, the program inserting messages can even be running while the "reader" is not. Once the reader is started it can start processing the messages queued in its absence.


Here's a demo with two programs called Monitor and Worker.

When Monitor starts it creates a queue if it doesn't exist. Then it starts listening for insertion events and starts up the Worker program.

Worker uses a Timer control to simulate some sort of external events to be monitored. It creates "events" as Long values from 0 to 19. A 0 is treated as an "event of the first kind" and anything >0 is an "event of the second kind."

The first kind means "close the file and send a message to the Monitor." The second kind means a data event and this value gets written to the current disk file, opening a new file with a unique file name if not open.

Both programs "log" what's going on so you can watch them.

There is a "Delete on Exit" item you can "check" under the Queue menu of Monitor.exe, and when checked this tells Monitor to delete the queue on exit for cleanup reasons.

Attachment 100865

To run the demo, compile both Projects. Then run Monitor which starts up Worker. When done, close Worker, then check "Delete on Exit" if done playing with this demo and close Monitor.

Pretty simple. But you can do tons more with MSMQ. A message sender can wait for replies from the consumer, you can have queues going both ways, etc.


Note:

If you want to test the Worker running while the Monitor is not, you need to add some code so that the Monitor does not start a second copy of Worker when one is already running.

Or... Run Monitor which starts Worker, close Monitor and let Worker run. Then close Worker and start Monitor again, which restarts Worker but also picks of the work left lying in the queue first before processing new msgs and files from Worker.

And of course you need to run Monitor the 1st time to create the queue.

Quote:

---

Originally Posted by jmsrickland

DDE could work but it is very outdated technology

---

The same could be said about VB6 :)
I personally don't get hung up about whether anything is 'outdated' if it still works and is appropriate for the solution to a problem then I'll give it a try. (Especially if whatever I'm doing is for internal comsumption rather than for distribution to anyone else)

EDIT: I remember seeing an article somewhere about using the .Net BackgroundWorker from VB6. Poo-pooed by both the VB6 and .Net community as being the worst of both worlds, it provided a very simple 2 thread solution with bi-directional communications. Of course, you have to have a VB.Net IDE installed to create the Com Wrapper, but once it's done it can be included into the VB project just like anything else. (Naturally, you also need the couple or three trillion bytes of the .Net Framework(s) installed as well but I believe they're included with the base operating system these days)

EDIT1: At the risk of being nuked here's the link to the article: http://msdn.microsoft.com/en-us/library/aa719109.aspx

(@JM: It may help with your current 'problems' re audio sync.)