USEREQUESTFORM - NAV 2009 Classic running on Citrix

Popspelt
Popspelt Member Posts: 4
edited 2015-06-18 in NAV/Navision Classic Client
We had the weirdest issue after a driver update on our printers. It seems that something different happens depending on whether or not USEREQUESTFORM is TRUE or FALSE.

This bit of code went well, and the report printed as it was supposed to:
CLEAR(MyReport);
MyReport.USEREQUESTFORM := TRUE;
MyReport.RUN;

But with this bit of code, the printer just printed gibberish for page after page until we cancelled it:
CLEAR(MyReport);
MyReport.USEREQUESTFORM := FALSE;
//MyReport.USEREQUESTFORM(FALSE); **Same result**
MyReport.RUN;

We tried RUNMODAL as well, but that didn't make a difference.

When we reverted back to the old driver, everything worked again. Does anyone know if there is a difference in the way NAV sends information to the printer queue, based the setting in USEREQUESTFORM, or whatever else could cause this weirdness?

Thanks in advance.

/Pops

Comments

  • evandeveerdonk
    evandeveerdonk Member Posts: 49
    did you check if the report perhaps had some default settings in the properties, like PaperSourceFirstPage or things like that?
    http://www.vssolutions NAV-Outlook synchronisation re-invented.
  • Popspelt
    Popspelt Member Posts: 4
    evandeveerdonk wrote:
    did you check if the report perhaps had some default settings in the properties, like PaperSourceFirstPage or things like that?

    I even made a brand new and very simple report, running through Integers number 1 through 10, with a header and a body and all properties at default. I called it the same ways as above and had the same results.
  • evandeveerdonk
    evandeveerdonk Member Posts: 49
    Well, at least that's consistent then :(

    Is this your default printer?
    http://www.vssolutions NAV-Outlook synchronisation re-invented.
  • Popspelt
    Popspelt Member Posts: 4
    Yes. Default printer. Default settings. Some of these print jobs have been working forever, and worked the day before we updated the driver. And now that we have downgraded the driver back to the-way-it-was-before, it works again. My best guess is that this particular driver is faulty somehow, and needs "something" to happen on the request form, in order to make the print job a valid one. But I'm clutching to straws here.

Categories