bb.donnay-software.com

Short history:
Converted Summer 87 Clipper to xBase++ 2.0. We are running these programs all over the company.

Problem:
On a very few computers, we are unable to run more than one xBase program at any one time. The issue revolves around a procedure common to ALL our programs called "setup.prg". Within setup.prg, we set the common settings, such as screen color, variables, and the print environment. It is the print environment that is hanging us. There is a command, at line 39 in setup.prg that states "set print to lpt1". We have this so that, throughout the programs we can "set device to print" and "set device to screen".

Out problem computers will launch one xBase program, but when attempting to launch a second xBase program (simultaneously), we get an operating system error on line 39 of the setup.prg. This is the same error we receive if we attempt to launch any xBase program in a computer with no parallel port, so we know the symptom, just not the solution.

It appears to me that the xBase program is obtaining an "exclusive lock" on LPT1, so that any subsequent program attempting to access LPT1 gets rejected.

Now for the climax.... We recently ordered two new computers from Dell - OptiPlex 5050 - Windows 7 64bit - with parallel ports. These are identical computers, ordered at the same time on the same order. The parallel cards are reported to be the same manufacturer, running the same drivers.

One computer can run multiple xBase programs, and the other cannot. We are at a total loss on what is causing this and how to fix it.

By the way, the other computers having this problem are Windows 7 64-bit, and Windows XP 32-bit.

Any solutions would be greatly appreciated.

Addendum:

On a problem computer, I can launch one xBase program, perform a "net use" redirecting lpt1 to a network printer, then successfully launch a second xBase program. Again, this makes me think that the local LPT1 is being held open and locked by the first program.

Also,

If I initially perform a "net use" to a network printer, I can open as many xBase programs as I like. This is somehow tied to the local parallel port and how Windows is talking to it.

Hi TC_Campbell,

I don't have enough information about your software but two things I can think of off the top of my head is:

1) Are you setting SET PRINTER TO at the beginning of the program?
If you are, use SET PRINTER TO <device> right before you print then SET PRINTER TO without the device after the printing is done.

2) Can you connect your printer with USB instead of Parallel?
You'll have to rewrite some code but you get some flexibility with that method

Just some ideas

Bobby

Thanks for the suggestions Bobby.

1. These are old converted clipper programs. There are about 2500 .prg's that do everything from manufacturing/inventory control through customer service and accounting. The manufacturing side has a lot of reporting, ticket generation, throughout the programs. The program bounces back and forth between set device to print, and set device to screen. The process of doing the "set device to lpt1", and then "set device to" every time we switch would be a major undertaking. On further reflection, however, that is basically what we are doing. In the setup.prg file, the line that generates the error states: "set print to LPT1". So, throughout the program, we say "Set device to Print", then, after printing, we say "Set device to screen". The problem occurs, however, when we attempt to define "print" as being "lpt1".

2. USB is not really an option in this environment... at least not at this time. The xBase conversion is being seen by management as a Band-Aid until we can find a more permanent solution to the problem of attempting to run 16 bit applications in a world that no longer supports 16-bit apps.

The error being generated is an Operating system error: 5 - which if I am correct, is an "access denied" error. Since "access denied" errors are generally permission errors on shares, I am having a hard time understanding how we can be getting that error when the device is local, unless the program is somehow making the device unavailable to any other process.

Problem solved… Although I am not sure I understand why.

I thought hard about the “access denied” and also did a search for the “lpt1.prn” I mentioned in my earlier message. I was unable to locate lpt1.prn, and am not sure if it is a literal file/folder on the computer. But this made me look in the spooler folder and see that there are NO printers defined. This is because it is a new computer and has not been put in service yet. Therefore, I have not installed any local printers.

I simply went into devices and printers, and installed a non-existent printer as a local lpt1 printer. Now I can open multiple xBase programs. I then removed the local non-existent printer, and I was back to getting the error on the second launch. (I reinstalled the phantom printer afterward).

It seems like Windows MUST have something defined on LPT1 before it will grant access to LPT1. I am guessing that the first program launch actually had a hanging process behind the scenes attempting to resolve LPT1, then the second launch was given an access denied, because the first launch never resolved LPT1.

The other computers having this problem may or may not have parallel printers attached. We have determined that the computers having this problem that DO have parallel printers attached, have label printers. These label printers print production tickets and barcode labels. These printers, before the conversion, printed only from the Clipper programs, so there was no need to install the Windows printer drivers. Therefore, they have no LPT1 defined in the Windows printers.

So, the solution is to install a local parallel printer in Windows, whether or not there is actually a printer attached.