It seems like Windows MUST have something defined on LPT1 before it will grant access to LPT1. (I reinstalled the phantom printer afterward). I then removed the local non-existent printer, and I was back to getting the error on the second launch. I simply went into devices and printers, and installed a non-existent printer as a local lpt1 printer. Therefore, I have not installed any local printers. This is because it is a new computer and has not been put in service yet. But this made me look in the spooler folder and see that there are NO printers defined. I was unable to locate lpt1.prn, and am not sure if it is a literal file/folder on the computer. I thought hard about the “access denied” and also did a search for the “lpt1.prn” I mentioned in my earlier message. Problem solved… Although I am not sure I understand why. 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. The error being generated is an Operating system error: 5 - which if I am correct, is an "access denied" error. 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. USB is not really an option in this environment. The problem occurs, however, when we attempt to define "print" as being "lpt1".Ģ. So, throughout the program, we say "Set device to Print", then, after printing, we say "Set device to screen". In the setup.prg file, the line that generates the error states: "set print to LPT1". On further reflection, however, that is basically what we are doing. The process of doing the "set device to lpt1", and then "set device to" every time we switch would be a major undertaking. The program bounces back and forth between set device to print, and set device to screen. The manufacturing side has a lot of reporting, ticket generation, throughout the programs. prg's that do everything from manufacturing/inventory control through customer service and accounting. These are old converted clipper programs.
#Clipper summer 87 software how to
We are at a total loss on what is causing this and how to fix it.īy the way, the other computers having this problem are Windows 7 64-bit, and Windows XP 32-bit.Īny solutions would be greatly appreciated.ġ. One computer can run multiple xBase programs, and the other cannot.
The parallel cards are reported to be the same manufacturer, running the same drivers. These are identical computers, ordered at the same time on the same order. We recently ordered two new computers from Dell - OptiPlex 5050 - Windows 7 64bit - with parallel ports. 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. 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. 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. We have this so that, throughout the programs we can "set device to print" and "set device to screen". There is a command, at line 39 in setup.prg that states "set print to lpt1". It is the print environment that is hanging us. Within setup.prg, we set the common settings, such as screen color, variables, and the print environment. The issue revolves around a procedure common to ALL our programs called "setup.prg". On a very few computers, we are unable to run more than one xBase program at any one time. We are running these programs all over the company. Converted Summer 87 Clipper to xBase++ 2.0.
0 kommentar(er)
