If we print to PDFX from APEX, the file is generated with the four stamps on each corner. Those stamps are supposed to display when using PDFX outside A-Shell but, printing from APEX shouldn't be considered "inside A-Shell" ? This came up when a user print the XTREE content using CTRL+P in a server, where the windows "print to PDF" does not exist by default, and tried to get a PDF using PDFX.
Hmmmm...., it does look like there's a gap in the logic there. I think how it should work is that PDFX would recognized A-Shell's license regardless of whether printing directly from A-Shell to PDFX, or indirectly via XTREE -> APEX -> PDFX. The problem, I think, is that the preview mechanism you see when using the XTREE print feature, isn't really APEX. It's based on the same underlying control, but in this case, the XTREE control and the preview control have gone off into a corner for a private conversation, and A-Shell isn't quite able to supervise it. I'm not sure there's even a possibility of hooking the operation.
There is a kind of workaround for the problem, but it's not exactly user-friendly. PDFX5 (as opposed to PDFX3), when instantiated (by printing) creates a new virtual driver associated with your job, shown below as PDFX/A-Shell TSKAAA. That driver knows about the A-Shell license and could be therefore used from the XTREE preview. The original/base driver (PDF-XChange Printer 2012) is missing the license.
Apologize for the silence on this, just to say that, it works, case solved! And, no problem about using PDFX/A-Shell, besides not perfect only because of the variable part with the jobname TSK???, I consider it more elegant than using an old printer from 2012
Hi Jack, This problem seems to have reappeared with the new PDFX driver. From inside an XTREE, choose Print from the contexr menu, the preview opens and, printing to PDF-X Standard or PDFX/A-Shell generates the PDF with the BUY stamps on each corner. Is this fixable?
In theory it should be fixable. The tricky thing is that the license is passed at runtime to the driver by the app that is printing. (There's no way to just store it, because the license is specific to the A-Shell -- PDFX pair, rather than to PDFX itself. To get a universal PDFX license you have to individually buy the retail versions.) And it isn't easy for A-Shell to get in between the XTREE preview window and the PDFX call, since those two controls have a "special relationship".
Excellent, it does solve the problem using the PDFX/A-Shell. If sent to the PDF-X Standard it keeps the four stamps, but that's the expected and prior behavior, correct?
The other good news is that, I can execute this ashw32.exe w/o automatic exit, has reported previously so, now I also can install the fix for the email/attachment problem.
Yes, that was the expected and prior behavior ( a consequence of the fact that the only way to pass the license to the driver is to create a new instance of it, which you don't normally see because A-Shell handles it silently, but in this case, A-Shell isn't able to get in the middle between the XTREE preview control and its own printing logic.)
As for the other problem, interestingly I just reproduced it myself about an hour ago, only in certain programs calling XTREE. (Your app may start out that way which is why you got it immediately.) After a full recompilation the problem seemed to go away, so it may have been that the compiler optimization (to avoid recompiling modules unnecessarily) had gotten out of sync.
Indeed, my startup program calls an XTREE to display the menu so, it's consistent with your diagnostic. It's great when an issue don't go away w/o an explanation. Thanks
