Mike, To echo / expand upon Sami's comments, view this as an *opportunity* and think long-term rather than just accept the status quo. Suppose RBTI does accommodate your request - is this the best long-term solution for the customer? Show them the options and they just might agree to dump the status quo and go for the future.
When we converted our old DOS app, I was in a BIG rush to do away with pin-fed inventory load tags, multiple-part pre-printed bills of lading and five-part NCR invoices. We did the bills of lading to laser (multiple copies) and load tags to Datamax label printers in 6.5, and invoices to PDF (in color) in 7.0. There's been no looking back. Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] (203) 643-8022 -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aaron Sent: Tuesday, January 15, 2008 9:43 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Enhancement request for Printer Control Codes in Rbase 7.6 Mike - Requests like yours pertaining to old printer control codes come up on this list as people convert from legacy R:BASE versions to the current Windows versions. And if RBTI can implement the requested feature, they typically do - just comparing the number of PRINT options from version 7.0 to the current versions shows how many of these control features that have already been implemented. With clients who have invested in their own pre-printed forms designs and/or specialized printer configurations and/or graphic publication needs, any options R:BASE developers can have to take full control is really crucial. So if RBTI can implement it within their development parameters, they will, and in the meantime, keep working with some of the other great suggestions you've received here and let us know how it works out. Sometimes you just have to step back from the project and determine what the ultimate goal is and how to meet that need vs. keeping the status quo with the new software and the client's old equipment... JMHO - Sami ____________________________ Sami Aaron Software Management Specialists 913-915-1971 [EMAIL PROTECTED] -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Sinclair Sent: Monday, January 14, 2008 5:16 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Enhancement request for Printer Control Codes in Rbase 7.6 Hi all! I am still working on getting Printer Control Codes to work. I have confirmed that they are not supported in Ver 7.6. I have submitted a request for an enhancement to the knock your socks off team! The reason for the request is because of the need to print on tractor feed forms. There are times when the end user is required to fill out original forms where laser forms are not available. An example would be a doctor's office where the doctor wants to have Rbase print perscriptions. The perscriptions are usually not 8.5" x 11", instead they are more like 4" wide x 5" in height. Finding a laser printer that would handle such an odd size piece of paper one at a time would be difficult. Printing the perscriptions on 8.5" x 11" paper would be awkward and possibly subject to abuse (duplication via a copy machine). Also, the original tractor feed forms frequently require filling in data at the top edge of the form, which is above the area where the print head sits at rest. In order to avoid wasting the first form, the user would need back up the form to line up the top of the form with the top of the print head which would be pretty inconvenient. The other choice would be to roll up the forms on the printer and waste the the first form by leaving it blank (wastes paper and is not good for the environment or trees!). Likewise, some tractor feed forms are not designed very well. They have fields that are not horizontally lined up. In those cases, you need to be able to move the form up and down by fractions of a line to get the data to print in exactly the correct location. Failure to do so would not only look sloppy, but it might cause the recipient of a from using an OCR program to fail to get the data properly. I am actively trying some of the suggestions that came from this awesome support group. I really appreciate your help. I will report back if I come up with something that works. Mike >
