I have been tasked with maintaining a program designed to read data from a set of barcode scanners and store it in a database. A few years back, we began the process of swapping from Top Gun scanners to Unitech HT630 scanners.

Top Gun scanners used a program called ptfer.exe to handle moving the data from the scanner to a file on the system. The Unitech scanners use a program called Multicom.exe.

The Top Gun scanners required a serial port; the Unitech scanners have both serial cables and USB cables that generate a virtual COM port.

Because I cannot know which type of scanner a given computer might be working with, I set the program up so that if one of COM ports 1-4 is selected, I assume it's attempting to read from a Top Gun unit. If this fails, the program is supposed to swap to reading from a Unitech unit on the same port number.

The problem I'm running into is that once ptfer.exe has run against a port and errored out, the Multicom process cannot open that port any more without either unplugging the cable, resetting the COM # in the device manager, or disabling/enabling the port in the device manager. Without doing one of these, Multicom.exe gets a constant open error across all of the baud rates it attempts. This appears to be a constant even if the two third-party programs are not called together - a copy of the program with the option to select for only one of the two will still error out in this way when the Unitech Port option is invoked after running the same port's Top Gun option. This behavior persists even when the Delphi program is closed and reopened, and the Task Manager reveals that ptfer.exe is closing when it errors out, so it's apparently dying without closing off the COM port it was using.

Does anyone here know of a way to programatically force the port closed, or a way to disable/enable it from within the Delphi code?