Last July, Steve Botes posted an issue related to a problem of printing a custom sized form using the OIPI32. To my knowledge this has never been fully resolved although Steve may have found a workaround.

We are encountering a different problem but it is still related to the lack of support for custom sized forms in the OIPI32. This problem has come up during a conversion of a client's application from OI16 to OI32. Here are the specifics:

We are printing to a 8.5" by 7" fanfold form on an Epson LQ-2550 printer. This works flawlessly with Win98 workstations and OI16 with OIPI v3.83. However, if we change the OS to Win2000/XP and/or change OpenInsight to OI32 we get an "Invalid Page Size" error message from the INIT Set_Printer call.

Therefore, we cannot upgrade to OI32 nor can we suggest they upgrade their workstations (even if they kept OI16). Either situation causes this to fail.

Can someone please advise us on what our options are?

Thanks,

[email protected]

SRP Computer Solutions, Inc.

Don,

We are looking at the custom paper size feature of OIPI at the moment.

Thanks in advance for your patience.

Sean

Sean,

Thanks for the response. If you want any of my testing results or feedback then please let me know.

[email protected]

SRP Computer Solutions, Inc.

I have been able to use Custom Form sizes, if the printer itself allows custom sizes.

PageInfo was set to USER (from the OIPRINT_EQUATES). I was unable to set the width and height (the 5th and 6th subparameters of the PageInfo parameter). If the width and height were set then an error was received (the -14 error you received). This error was because my printer does not allow custom sizes to be set from outside the printer.

OIPI32 cannot set a custom size but can only use a custom size that is predefined on a printer.

Sean

Sean,

I have been able to use Custom Form sizes, if the printer itself allows custom sizes.

Can you name for me a print driver that allows custom sizes in Win2000/XP?

PageInfo was set to USER (from the OIPRINT_EQUATES). I was unable to set the width and height (the 5th and 6th subparameters of the PageInfo parameter). If the width and height were set then an error was received (the -14 error you received). This error was because my printer does not allow custom sizes to be set from outside the printer.[/i] -14 was the error I kept receiving. I realize that the print driver needs to support custom sizes. Unfortunately many of the drivers written for Win2000/XP have eliminated user defined sizes. Epson, in my case, doesn't even have any drivers to download for their older dot-matrix printers. They just say to use the MS supplied ones with the OS. Regardless, I tried to test the OIPI32 on a Win98 machines without success (as I originally posted). In this environment the user defined sizes are supported by the driver but OIPI32 still returns -14. OIPI v3.83 returns a 1. So, OIPI32 must be using a different method for determining valid page sizes than the 16-bit version. Based on previous posts and my conversations with Tony Splaver he believes that this is a change made to vsprint7.ocx. OIPI32 cannot set a custom size but can only use a custom size that is predefined on a printer.[/i] Now this statement confuses me. It seems as if you are saying that OIPI32 cannot use a custom size regardless of whether the print driver permits it or not. Is this correct? It sounded like you had some success above. Was there any time that you successfully used a custom size with the OIPI32? If so, what parameters (OS type, printer type, etc.) were you using? Thanks, [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 26 OCT 2002 05:05PM Donald Bakke wrote: === <QUOTE>Sean, et al., I believe I have found the problem with user defined forms. These three Microsoft articles discuss this very problem: Windows NT Print Manager and Custom Form Limitations How to Create Custom Forms in Windows NT 4.0 and Windows 2000 HOWTO: Print Using Custom Page Sizes on Windows NT and Windows 2000 Apparently the lack of (or change in) support for user defined forms in WinNT/2000/XP is by design. The first article discusses how to work around limitations based on margin settings. The second article discusses how to add a custom sized form to your print driver (which is what has been resolving my problem so far.) The third article is oriented towards VB programmers and how they can support user defined forms in their code. This may be helpful to Revelation so they can build in this support within the OIPI. In the meantime, however, article #2 is giving me a workaround. Note: I still get a -14 return value, but the output looks correct. [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 28 OCT 2002 01:14PM Donald Bakke wrote: === <QUOTE>Revelation, I'm not trying to be a nuisance with this but I thought it would be helpful if I offered some additional results of my testing with user defined forms. In some cases I could get away with creating a custom form as described by the Microsoft article and then specify the dimensions in my INIT message. Even though I got a -14 return value, it would still appear to print fine. However, other custom sized forms would return a -999, OIPI32 would shut down, and OIPI (16-bit) would get loaded in memory. The only way to avoid this problem would be to pass the form ID number that Windows assigns to my custom form to the INIT message. This would return a 1 and the output would print fine. The problem here is that there is no way to predict what the form ID will be in advance and it can be different for each workstation. Consequently, the only real solution is to allow the OIPI a way to create user defined forms on-the-fly and then return that form ID for the current print job. Then the OIPI would need to remove this form when the printing is completed. This is essentially what the one Microsoft article I posted explains how to do. I assume this is how Word and other programs give me the ability to print custom sized forms as well. Any possibility of getting this to happen? [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 29 OCT 2002 05:13PM John Bouley wrote: === <QUOTE>Donald, We also had issues with custom forms but was able to find a workaround (at least in OIPI 16). Converted a "Check" printing form from AREV to OIPI. Arev just used print statements and kept a line count. Pretty simple! No fancy formatting etc. OpenInsight (OIPI) uses the Windows Printer driver. When the printed output came close to the "Standard 8 1/2" boundery it added or subtracted data. Therefore, the first two checks were ok but after that everything was off! I then created a custom form and a special printer. Used the Generic Text printer driver. Then changed the OI code to scan the currently loaded form of the default printer. If the default printer did not have the form with the correct dimensions a message was displayed that indicated the current printer could not be used. I gave them an option of selecting the printer and off we went. Also, the code needed to include form feeds at the bottom of each page for this technique to work. HTH, John </QUOTE> —- === At 29 OCT 2002 06:03PM Donald Bakke wrote: === <QUOTE>Hi John, Thanks. What workstation OS are you using? I ask because 16-bit OIPI has never given us any problems with custom sized forms. However, I think this has more to do with the architecture of Win98 than the OIPI. Your solution sounds pretty much like what I discovered. The problem is that this isn't a suitable long term solution. We shouldn't have to create custom forms on every workstation that will use our application. It's possibly okay for a small proprietary app but for our systems that get deployed this is not very practical. [email protected] SRP Computer Solutions, Inc. </QUOTE> —- === At 30 OCT 2002 09:37AM John Bouley wrote: === <QUOTE>Donald, The customer was using NT 4.0. I agree with you in principal that we should not have to create custom forms but I think we are at the mercy of how Windows is designed. Things changed when we go to NT and above and not all printer drivers even support custom forms. At this point the best I could do was identify that the currently selected printer did not have a valid form. Then it is up to the customer/user to correctly setup their workstation. This can be worked out through a written procedure. This seemes to work well with checks or statements. Thankfully, we have not run into too many custom size forms in our apps. John </QUOTE> —- === At 30 OCT 2002 12:23PM Donald Bakke wrote: === <QUOTE>John, I agree with you in principal that we should not have to create custom forms but I think we are at the mercy of how Windows is designed. That is correct, but there is a way for the OIPI to work around this as mentioned in the MS article I linked to. So, at this point we are more at the mercy of Revelation than Windows. [email protected] SRP Computer Solutions, Inc. </QUOTE> View this thread on the Works forum...