Serial printer to Text

hmm, depends on what happens behind the scenes.

Why did you not use the generic print to file printer?

I need to capture that data and have it converted to a text file and then will have some other software process the data.

how do you "capture" the data - scanning?

Sounds like the serial printer is "hard-coded" in the application.

Could you give a little more detail about why another Windows printer cannot be selected?

ste5an:  I don't have an answer for that...   When you print to file what does the output look like?  (watch it be something like text, lol)

Paul:  It was previously captured via the old software.  If I can convert it to text, I can write something to process the data and put it into a data base.

It sounds like the software you are referencing is receiving and processing output from another software.

If this is correct, what kind of software is generating the output?

I need some clarification on this. Are you saying that you have software that prints to COM1, COM2, COM3, and/or COM4? And that you have other software (the one that won't be updated for W10) that intercepts whatever is sent to COM1, COM2, COM3, and/or COM4 and saves it in a text file? Regards, Joe

Guys, I am sorry that I don't have better details.  I have been presented with this opportunity to put something in place to replace software that the original vendor isn't planning on updating.   If there is already 3rd party software that will mimic a serial printer and make a txt file, that would solve everything.

@Joe & N8iveIT:  There is a device that is connected via serial to a workstation.  The vendor for the device had some software that does reporting for the device.  I believe the output is currently printed.  Once in a text format I can worry about getting the data into a database.

The old software basically acted as a serial printer.

is this what you mean?

I'm struggling to understand your situation. Here's my guess:

(1) You have a device that connects via a serial port ("There is a device that is connected via serial to a workstation.").

(2) You have software that prints to that device.

(3) You have other software that reports what has been printed to that device.

(4) You are going to stop using the device in W10, but you are still going to use the software that prints to it.

(5) This means that you need software that intercepts everything printed to the serial port (probably COM1) and puts it in a text file.

Is that right? If not, please correct it. Regards, Joe

Well, I guess you should look more into the existing documentation and give use more, specific details.

If there is already 3rd party software that will mimic a serial printer and make a txt file, that would solve everything.

Windows has a built-in to file printer.

Update:  

I went on to my clients site to have a look at what has been described to me.   The original author wasn't returning any calls, and we had limited information on exactly how the software worked (hence the request here if there was 3rd party software I could use - less development time no?)

Anyways, wrote an application that is able to communicate with the device through the com ports.  So for the most part I have access to the data.  So now I am in the phase of extracting the data we can read and deciphering the data we do not understand.  This of course renders the need for 3rd party software moot.  Thank you all for your interest in the issue.

Fox

Also, since I wasn't sure which com port the data would be coming on on, so I setup the app to list to all of them,  I found out that the device is communicating on multiple com ports!

> I found out that the device is communicating on multiple com ports!

Yep, that's why I mentioned COM1/COM2/COM3/COM4 in my first post. Anyway, glad you got it sorted.

> Thank you all for your interest in the issue.

You're welcome...happy to help. Regards, Joe