0

I run an assembly line at work that I'm trying to automate. The current software is two stand alone excitable. One is an editor that adds the variables to an sql database and the second reads that database and controls the cnc. Both are on the same pc, running at the same time and both are written in vb6. When you hit the 'add' button in the first .exe (editor) it somehow tells the second .exe to reload the sql database and load any updates.

My problem is I've written a software that takes the barcode and inserts the variables into the database automatically which will bypass the first software but the second software doesn't know when to revisit the database for updates.

Are there any common ways for one .exe to talk to a second .exe and how do I listen so I can duplicate it? Thanks Sam

EDIT : sorry what i meant by 'bypass' is make the first .exe redundant. My software inserts in to the sql rather then their editor software.

sam
  • 25
  • 3

3 Answers3

0

You can look at something called named pipes. This is how it is commonly done.

You can read about it here at msdn, there is a good example. https://msdn.microsoft.com/en-us/library/bb546085(v=vs.110).aspx

Dai Bok
  • 3,451
  • 2
  • 53
  • 70
  • 1
    You guys are great. Thank you so much. Ill do some research and let you know how it goes. – sam Mar 07 '17 at 13:58
0

Pipes, mentioned in another response, are one common mechanism. My preference when small amounts of data are exchanged are UDP sockets.

Using the Winsock control you can set up peer-peer or 'talker-listener' communication in just a few lines of code. Your second program can listen for either a simple signal or a more complete packet of data from the first program and act accordingly.

A side benefit is that if this PC is on a local network, it's trivial to move the two programs to separate PCs if that becomes desirable at a later date.

Jim Mack
  • 1,070
  • 1
  • 7
  • 16
  • Yes, that is a advantage over named pipes. In larger applications we have used WCF for services. I prefer using restful API services but there are many ways to skin a cat. – Dai Bok Mar 07 '17 at 13:29
  • Of course UDP between machines is far less reliable than within one machine. That's part of why we have Pipes, TCP, etc. – Bob77 Mar 08 '17 at 06:06
  • 1
    @Bob77 - UDP is not inherently unreliable, and can easily be made as robust as you like by adding ACK/NAK etc. Agreed that TCP is better in many situations, but for simple, short messages on a local network UDP is easy and straightforward. I've used it in dozens of apps with no issues. The main benefit for me has been that many times one program is running on Linux, or Arduino etc. No pipes there. – Jim Mack Mar 08 '17 at 12:46
  • Sure, you can try to layer amateur techniques on top of UDP to try to make up for its inherent unreliability but that doesn't change the facts. If you need reliability, in-order arrival, etc. just use proven TCP. Trying to reinvent the wheel usually isn't worth the high development and testing costs. You may well be fooling yourself and losing tons of data. – Bob77 Mar 09 '17 at 02:31
  • @Bob77 - I guess we'll have to agree to disagree. UDP exists for a reason, and I employ it with success, as do many internet applications including games, media etc. Your snide comments aside, surely we can't all be amateurs? I keep a variety of tools in my kit including UDP, TCP, pipes and queues, and use them where in my professional opinion they fit best. The OP can only benefit from exploring more options. – Jim Mack Mar 09 '17 at 11:04
  • Next you'll be telling us all about your superior hand-rolled encyption I suppose? – Bob77 Mar 09 '17 at 16:57
  • @Bob77 - Cheap shot, and irrelevant to the discussion. BTW, deleting comments just so you have the last word makes it look as if you need to 'win' at any cost. – Jim Mack Mar 10 '17 at 18:50
  • People need to be aware when somebody tries to feed them bad advice. – Bob77 Mar 11 '17 at 09:19
  • And 'bad advice' means anything you didn't supply? You're incorrect in your assessment of UDP in the OP's case. It's a tested and proven method of IPC, and a valuable option in addition to the other good methods listed. There's a system in place here to evaluate advice: people assess and vote. They don't sneer or try to shout each other down and use their accumulation of brownie points to intimidate. Please, express your opinion. Just don't assume it's the only valid one. – Jim Mack Mar 11 '17 at 14:47
0

MSMQ private machine queues are easy to set up and use in VB6. They almost sound ideal for the sort of thing you are doing, and you may be able to ditch the database entirely.

Bob77
  • 13,167
  • 1
  • 29
  • 37