When a report is sent to a printer, no user interface should be required to run the report. We are trying to sumbit report printing to a remote engine, but the program will not run there. RUN_REPORT and OLIST call SSP GAUGE, so we bypassed GAUGE when IsEventContext()=False$. Still the reports will not run on the remote engine. Can anyone tell us what needs fixing to get remote engines to print?

Thanks

Gerald Lovel

Gerald,

The fundamental issue here is that the OIPI is a form based utility, even if you are not previewing anything. Therefore, if your remote engines are not running within a presentation server context you cannot get reports to work. This was addressed by Andrew McAuley in his Las Vegas presentation. One alternative is to use the new Basic+ functions that allow you to load OLE objects without the presentation server. Andrew nicely demonstrated this for us using the actual code you can find in the latest Programmer's Reference Manual.

Keep in mind, however, that by going this route you are no longer using the OIPI. Rather, you are communicating directly with the underlying VSPrinter OLE control. Therefore, you will not have the nice Basic+ wrapper that the OIPI provides. You will have to talk directly to the OLE control yourself or write your own wrappers.

Given that this is an OLE solution, and I know you are looking for better cross-platform functionality, you may want to see what the PostScript driver can do in this situation.

Another alternative is to launch your remote engine(s) in a prsentation server context. If this is on a remote server then that should not be a problem. If this is for a local machine then you might have to limit your remote engine to only handle queries. You can then send back the name of the save list and have the primary engine handle the printing.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks for the recap on printing capabilities, Don.

"The fundamental issue here is that the OIPI is a form based utility, even if you are not previewing anything."

I take your meaning to be that Run_Report and Olist are OIPI-based routines.

"Given that this is an OLE solution, and I know you are looking for better cross-platform functionality, you may want to see what the PostScript driver can do in this situation."

Someone from Revelation Software can jump in at any time now and explain how to switch from the OIPI OLE/OCX to PostScript while using Olist or Run_Report. As I write this response on my Linux box, the OIPI hurdle is raised higher and higher.

"Another alternative is to launch your remote engine(s) in a presentation server context. If this is on a remote server then that should not be a problem. If this is for a local machine then you might have to limit your remote engine to only handle queries."

I am guessing at the main issue with starting a local out-of-process engine in Presentation Server context. Is this undesirable because it is visible to the user? In which case, I think I understand how to get around that issue. Having remote engines perform selects only is of limited value, since report generation takes much more time than selection in my applications. But starting engines in Presentation Server context still does not address the issues with OLE and OCXes since my target platform will be Linux. I eagerly await Revelation Software's future developments in PostScript.

RevSoft are implementing OIPI in PostScript for the Linux release to go some way towards addressing these issues.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

1) db] Given that this is an OLE solution, and I know you are looking for better cross-platform functionality, you may want to see what the PostScript driver can do in this situation

but this isnt cross platform as we were told at the conference that PS only worked on the Linux platform .. or did i miss something

2) I have to say that this really sucks .. (not your fault i know) as we were just getting ready to start doing reports and planned on the engine. This is NOT useful. This is like the UD driver .. nice idea but when it only works with itself .. 'LOST IN TRANSLATION' comes to mind.

oh well … guess it is back to hard coding everything like the old PICK days

but does this create a 'cross-platform' seamless environment? How does/will it work in windows?

Our understanding is that the PostScript, whilst engineered for Linux, will be made available in OI.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

whilst this was mentioned .. this does mean that you have to have PS printers .. yes?

PostScript is a universal printer addressing language. If your printer does not have a PostScript engine, then load the (I believe free) GhostScript driver, and voila, your printer will print PostScript. Therefore, PostScript is the ONLY printing solution needed for all platforms.

so .. what you are saying is that it is universal as long as you have another piece of SW to make it universal .. something like that .. yes?

Thanks .. will put this with your other suggestion for future consideration

No, I am saying that PostScript truly is a universal display language.

Not every printer "speaks" PostScript, but when printers do not speak PostScript then the translation from PostScript to the printer's raster output is handled by GhostScript.

GhostScript is a PostScript to raster interpreter that sits outside the printer instead of inside it. GhostScript completes the task of translating from the universal display language PostScript to the proprietary raster imaging of printers which are propoietary or "Windows Only." So yes, if you have a proprietary printer, a separate driver is needed to go from a universal language to your proprietary output device.

However, Windows needed a driver to talk to your "Windows Only" printer anyway, so what you are doing is replacing one "extra" component with a different, and more-friendly, "extra" component.

]No, I am saying that PostScript truly is a universal display language.

]Not every printer "speaks" PostScript, but when printers do not speak PostScript then the translation from PostScript to the printer's raster output is handled by GhostScript.

so .. let me see .. truely universal IF you teach it how to talk it ..

Ok .. i get it now

dsig

That's how the universal translator works, but that's Star Trek for you. Now the Tardis, well, that rarely has problems with languages.

What you need is a babelprintdriver.

the BabelPrinterDriver might work though I hate that fish in the ear thing .. or would it be in the eye?

What is really needed is a print process which will work without Presentation Manager seemlessly between the environments ..

yep .. that is what is needed.

Got one of those in your back pocket? (or ear as the case may be:-)

If you use the olecreateinstance commands you can print without a presentation manager using the vsprinter ocx but you will need to use the properties and commands that are related to it and not the set_printer commands. The sample in the help uses this method to print a simple text.

Bob,

DSig said, "What is really needed is a print process which will work without Presentation Manager seemlessly between the environments .."

Here environments should be taken to mean Linux and Windows, I believe. Suggesting a raw OLE control to avoid presentation manager seems to be unresponsive to the need for background printing (preferrably with PostScript) in a Linux environment which does not support OLE.

Gerald

Believe me .. thanks for that .. BUT that then further hardcodes our reports to the window control. how does that then move to Linux?

There in lies the problem. Although this does buy us time until the need to move to linux is driven by our clients .. but then we will have to rewrite those reports to ???? and then maintain seperate code base.

View this thread on the Works forum...