I have a fresh copy of AREV64 that behaves as expected on my local machine when I run the following commands from TCL:

PDISK C:\TEMP\TEST.TXT

LIST 10 VOC (P

PDISK PRN

However, when I run this on the client's machine I get the same UI feedback (even prompting me if the target file already exists) but I never get any file output. When I do the same thing from AREV32 (OI 9.4.6) on the same machine, it behaves as expected.

I've installed the OI 10 client setup. I've confirmed there is a default printer. I have been able to print using OIPI and Direct_Print from within OI. Running SETPRINTER gives me valid options.

I've also compared an OEPROFILE log to a REVPROFILE log. For the essential stuff they look pretty much the same.

What else might cause PDISK to appear to work but actually fail?

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don. On the customer system, are they using an engine server? What is the CFG_CTO record on both your local system and on the client's system?

If your client is using an engine server, then the drive and folder referenced (c:\temp) might be on the machine where the engine server is running, rather than on the local workstation as you'd expect. So you might be looking for the output in the wrong place…?

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Hi Bryan - Thanks for the response. Actually, that is an excellent suggestion I had not considered but alas it does not apply in this circumstance. The version of OI that I had locally was copied without changes to the customer's system. I only have the default CFG_CTO setting:

< 1 > : .

< 2 > : 18088 vm vm vm

I forgot to mention that I am using OI 10.2.1 Beta 4. I did not post this in the Beta forum as I did not think this was a beta specific issue. If you think it is worth testing a copy of 10.2.0 let me know.

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don.

The PDISK functionality relies on DIRECT_PRINT, which is implemented in the REVPRINT.DLL.

Are you running the same version of Windows on both your local system and the client system?

Do calls to DIRECT_PRINT directly (not using PDISK) work correctly on the client system? You can test that from OpenInsight in addition to AREV64, I believe.

I don't believe we've changed anything in the most recent version that would cause the problem you're seeing (but I am always open to being proven wrong…)

- Bryan Shumsky

Revelation Software, Inc.

Hi Bryan - Well, I had posted that I was able to print using Direct_Print successfully. However, I decided to double-check this and now it is reporting that it is unable to initialize the printer. I created a hook for Direct_Print and re-tested in AREV64 and I'm getting the same response. This would explain why it is failing although I know it worked before and OIPI is also working.

I'll chase down the printer intialization issue and see if this resolves the problem. Thanks again for your timely advice.

Don Bakke

SRP Computer Solutions, Inc.

I'll chase down the printer intialization issue and see if this resolves the problem. Thanks again for your timely advice.

Don Bakke

SRP Computer Solutions, Inc.

I have not identified the issue as of yet. I'm running the same code in both OI 9.4.6 and OI 10.2.1 Beta 4:

rv = Direct_Print( 'START', '', 'C:\TEMP\DMB.TXT', True$ )

rv = Direct_Print( 'PRINT', 'Hello World!' )

rv = Direct_Print( 'STOP' )

OI 9.4.6 produces the file. OI 10.2.1 Beta 4 returns this error:

< 1 > : -2

< 2 > : Unable to initialize printer.  The printer name may be incorrect of the printer is not available.

Even if I put in the name of an actual printer ( rather than rely on "default" ) it still fails.

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don.

Do you have a default printer specified on your test system? Does your client have a default printer specified on THEIR system? I think if no printer name is passed in to the DLL, then we get the default printer name - and if none is specified, you might see the message you've reported.

Also, if they and you both DO have default printers specified - are they the same type of printer? A relatively recent change in the last few releases of OI 10.x was to allow you to specify some additional info to DIRECT_PRINT via the CFG_DIRECTPRINT SYSENV record. In particular, you may now need to specify the type of the printer's driver - RAW, or XPS_PASS, for example.

To address one of the other points you mention, the OI 9.x version - which is a 32-bit dll - may well behave differently than the OI 10, 64-bit version. Microsoft made changes in the GDI print system (which we needed to accommodate in the 64-bit DLL), which might explain why the 32bit version still works whereas the 64bit one doesn't. The 32bit DLL is "legacy" print behavior, and thus might not be experiencing whatever issue is causing your problem.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Do you have a default printer specified on your test system? Does your client have a default printer specified on THEIR system?

Yes to both questions.

I think if no printer name is passed in to the DLL, then we get the default printer name - and if none is specified, you might see the message you've reported.

Correct, that is in the documentation and it is what I've seeng from testing. I have tried leaving it empty and passing in an actual printer. The same error is returned in OI 10 either way.

Also, if they and you both DO have default printers specified - are they the same type of printer? A relatively recent change in the last few releases of OI 10.x was to allow you to specify some additional info to DIRECT_PRINT via the CFG_DIRECTPRINT SYSENV record. In particular, you may now need to specify the type of the printer's driver - RAW, or XPS_PASS, for example.

Both machines have default printers that are HP LaserJets (not the same model). I don't think I was familiar with this CFG_DIRECTPRINT record. I see one in my OI but I'm not sure how to extend it. Is there documentation?

To address one of the other points you mention, the OI 9.x version - which is a 32-bit dll - may well behave differently than the OI 10, 64-bit version. Microsoft made changes in the GDI print system (which we needed to accommodate in the 64-bit DLL), which might explain why the 32bit version still works whereas the 64bit one doesn't. The 32bit DLL is "legacy" print behavior, and thus might not be experiencing whatever issue is causing your problem.

That is good to know. Are these changes related to the implementation of the CFG_DIRECTPRINT record?

Don Bakke

SRP Computer Solutions, Inc.

Do you have a default printer specified on your test system? Does your client have a default printer specified on THEIR system?

Yes to both questions.

I think if no printer name is passed in to the DLL, then we get the default printer name - and if none is specified, you might see the message you've reported.

Correct, that is in the documentation and it is what I've seeng from testing. I have tried leaving it empty and passing in an actual printer. The same error is returned in OI 10 either way.

Also, if they and you both DO have default printers specified - are they the same type of printer? A relatively recent change in the last few releases of OI 10.x was to allow you to specify some additional info to DIRECT_PRINT via the CFG_DIRECTPRINT SYSENV record. In particular, you may now need to specify the type of the printer's driver - RAW, or XPS_PASS, for example.

Both machines have default printers that are HP LaserJets (not the same model). I don't think I was familiar with this CFG_DIRECTPRINT record. I see one in my OI but I'm not sure how to extend it. Is there documentation?

To address one of the other points you mention, the OI 9.x version - which is a 32-bit dll - may well behave differently than the OI 10, 64-bit version. Microsoft made changes in the GDI print system (which we needed to accommodate in the 64-bit DLL), which might explain why the 32bit version still works whereas the 64bit one doesn't. The 32bit DLL is "legacy" print behavior, and thus might not be experiencing whatever issue is causing your problem.

That is good to know. Are these changes related to the implementation of the CFG_DIRECTPRINT record?

Don Bakke

SRP Computer Solutions, Inc.

@DonBakke

if you do:

Consoles→Management Console→System Configuration→Configuration records:

Select DIRECTPRINT it is all there

if you do:

Consoles→Management Console→System Configuration→Configuration records:

Select DIRECTPRINT it is all there

While I appreciate your response that isn't helping me. This crashes one of my environments hard. The other environment requires me to log on to the Console, which I don't have configured and don't see the need for it.

Don Bakke

SRP Computer Solutions, Inc.

I got this working so I can see what you are referring to. Yes, this was helpful since I was able to add another printer and then inspect the raw config record to see how it works.

There appears to be an OI window version of this called RTI_IDE_CONFIG_RECORDS. However, it is not fully functional.

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don.

Yes, there is an OI window version "in the works" for configuration record maintenance, but it won't be fully working until 10.3 at least. For now, the O4W Console should be considered the "management tool" to use.

You mentioned that you had a CFG_DIRECTPRINT on your system, but not on the client's? What did yours contain? Or did I misunderstand you?

- Bryan Shumsky

Revelation Software, Inc.

Hi, Don. Looking at the REVPRINT dll, I see there is a function to return more information when there's been an error (it returns the result of a call to GetLastError in the DLL). You can add this code to your test routine:

Declare Function DirectErrorCode

errCode = DirectErrorCode()

(Note that the value returned is ONLY valid after an error result has been returned by the DIRECT_PRINT call)

Perhaps the error value returned on your client system (but not on your test system) will help point us in the proper direction…

- Bryan Shumsky

Revelation Software, Inc.

Perhaps the error value returned on your client system (but not on your test system) will help point us in the proper direction…

Hi Bryan - Thanks for this tip. Yes, this did produce an error code: 1801.

Don Bakke

SRP Computer Solutions, Inc.

You mentioned that you had a CFG_DIRECTPRINT on your system, but not on the client's? What did yours contain? Or did I misunderstand you?

Perhaps in haste I didn't write something very clearly. All systems have a CFG_DIRECTPRINT record.

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don. OK, if we google GetLastError codes, we see on this page that 1801 is:

The printer name is invalid. (ERROR_INVALID_PRINTER_NAME)

I can get this error, for example, if I use the name of a printer that doesn't exist on my network.

- Bryan Shumsky

Revelation Software, Inc.

Hi, Don. OK, if we google GetLastError codes, we see on this page that 1801 is:

The printer name is invalid. (ERROR_INVALID_PRINTER_NAME)

I can get this error, for example, if I use the name of a printer that doesn't exist on my network.

- Bryan Shumsky

Revelation Software, Inc.

Hi Bryan - Yes, I had started to do my own google searching and came across this explanation along with a few others (such as firewall blocks). The problem is that the printers are valid. As you may recall, this all works in OI 9 on the exact same machine. Also, if we leave the printer name argument empty to use the default, this also fails in OI 10.

We stumbled across a combination of R/Basic commands such as SETPRINTER and extraneous PDISK PRNs and are finally getting a file to be produced. We are doing some deeper diving to understand what the underlying calls to Direct_Print look like. This might give us a workaround but does not necessarily explain the source of the issue.

Don Bakke

SRP Computer Solutions, Inc.

To all who might be monitoring this thread..

Bryan kindly offered to help me troubleshoot this directly. It was discovered that when attempting to write to a file using Direct_Print in OI 10, Direct_Print will attempt to create a printer handle to the Microsoft XP Document Writer printer if a valid printer had not already been initialized. If this printer is absent (as it was with our client's system), then this will cause the START message to fail and prevent the remaining Direct_Print calls to fail as a result.

Note, this is mostly a problem when using PDISK in AREV64 since it more likely that no printer has yet been initialized. When called Direct_Print directly in code and a valid printer has been initialized then printing to a file is expected to work.

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don. Just a bit of clarification - when using DIRECT_PRINT to generate output to a file (so, param3 is "1" ), in OI 10 the printer name is ALWAYS set to the Microsoft XPS Document Writer - param1 (normally the printer name) is always ignored, and only param2 (the output file name) is used. So if anyone is using DIRECT_PRINT to generate file output in OI 10, they must make sure the Microsoft XPS Document Writer is installed on their workstation(s).

- Bryan Shumsky

Revelation Software, Inc.

Hi, Don. Just a bit of clarification - when using DIRECT_PRINT to generate output to a file (so, param3 is "1" ), in OI 10 the printer name is ALWAYS set to the Microsoft XPS Document Writer - param1 (normally the printer name) is always ignored, and only param2 (the output file name) is used. So if anyone is using DIRECT_PRINT to generate file output in OI 10, they must make sure the Microsoft XPS Document Writer is installed on their workstation(s).

- Bryan Shumsky

Revelation Software, Inc.

Bryan - I think in principle you are correct but you might recall that we found a workaround…albeit not an ordinary one. This required us to do a SetPrinter x to a valid printer and then call Printer On in our code. Granted, this doesn't work with strict TCL (because of the Printer On statement), but it was an R/Basic based workaround.

Suffice to say, assuming that Microsoft XPS Document Writer must be installed is definitely the safer and sure fire solution.

Don Bakke

SRP Computer Solutions, Inc.

View this thread on the Works forum...