In trying to upgrade from PDFX 3 to 9, we're seeing an issue with Window's A-Shell. I've attached a screenshot with a "windows cannot find "file to be created by PDFX error. I click OK on the error dialog, and PDFX 9 creates the file as expected.
I've tested with the same results from 6.5.1721.3 and 6.5.1721.7.
I can't go back further because our code is compiled with the new DYNFUNC named parameter header flag.
P.S.
ATE works as expected.
Last edited by Stephen Funkhouser; 18 Nov 2204:46 PM.
It's not clear to me what event is triggering the error here. Is it the automatic launch of the PDF viewer? Did the pdf file not get created?
Seems like it should be easy to isolate and reproduce the problem, assuming it is within the perimeter of PDFX, with a single-line program consisting of the XCALL SPOOL with the print file.
I take it that the same process worked with PDFX3. But despite efforts to try to bridge the gaps between PDFX3 and the later versions, there were a lot of niggling little differences in the names of the directives, etc.that have to be translated. So being able to see the exact print file (or at least the //PDFX directives) may be critical to sorting this out.
Sorry, had to reboot my laptop before I could find the code.
It happens regardless of whether or not the PDF viewer is launched. The pdf file does get generated, but only after clicking clicking "OK" on the dialog.
Yes, this works with PDFX 3.
Code
prefix'filename$ = fn'fileunique_get_filename$(mode=FILEUNQ_FN_JOBNAM ,path$="PRINT:" ,amos'spec=1)
ch'prefix = Fn'NextCh(CH_BASE)
OPEN #ch'prefix,prefix'filename$,OUTPUT
!Save created PDF file
PRINT #ch'prefix,"//PDFX,Save.Type,2"
!Turn off save dialog
PRINT #ch'prefix,"//PDFX,Save.ShowSaveDialog,0"
!Specify file output
PRINT #ch'prefix,"//PDFX,Save.FullFileName," + pdf'filename$
IF (pdfx'options.open'pc'file = 1) THEN
PRINT #ch'prefix,"//PDFX,Save.App.Run,1"
ELSE
PRINT #ch'prefix,"//PDFX,Save.App.Run,0"
ENDIF
!Overwrite existing files
PRINT #ch'prefix,"//PDFX,Save.WhenExists,Overwrite"
!Add some generic info fields
PRINT #ch'prefix,"//PDFX,Info.Use,1"
![106]
IF (font.size <> 0) AND (font.name <> "") AND (font.weight <> "") AND (printer = "PDFL") THEN
PRINT #ch'prefix,"//SETMAPMODE,LOENGLISH"
PRINT #ch'prefix,"//SETFONT,";STR(font.size);",";font.name;",0,0,";font.weight;",0,0"
ENDIF
CLOSE #ch'prefix
XCALL SPOOL &
, file$=filename$ &
, printer$=printer &
, switches=SPL_NODELETE+APEX_OFF &
, prefix$=prefix'filename$
Hey Frank - I didn't notice you tiptoeing into this chat room! Tempting to say something about great minds... but maybe it should be "wrong answers..." instead.
So Stephen, you put a trace right before the prefix file is opened? closed? Seems to suggest a timing issue. Was the filespec that it was trying to create the one from the fn'fileunique_get_filename$() function, or was it just the pdf version of the original filename? Does a very short sleep in place of the trace do the trick?
Here's an improved version of the simple test program, but it continues to work ok here without any delays or traces. Could be run as is except for the output filespec.
Code
defxcall SPOOL, file${,printer$,switches=0,copies=1,form$="",lpp=56,width=80,prefix$="",suffix$="",overlay$="",totpages=0}
open #1, "prefix.prt", output
? #1, "//PDFX,Save.Type,2"
? #1, "//PDFX,Save.ShowSaveDialog,0"
? #1, "//PDFX,Save.FullFileName,""c:\users\joaqu\documents\APEX\in04q.pdf"""
? #1, "//PDFX,Save.App.Run,1"
? #1, "//PDFX,Save.WhenExists,Overwrite"
? #1, "//PDFX,Info.Use,1"
close #1
open #2, "test.prt", output
? #2, "Hello world"
close #2
xcall SPOOL, file$="test.prt", prefix$="prefix.prt", &
printer$="pdfx9"
end
Red herring with the trace.print fixing it. I can't reliably figure out how to reproduce. It's happens seemingly randomly and then doesn't just as randomly.
Sure sounds like some kind of timing issue. I did experiment with what happens if the prefix file isn't found, but in that case it simply proceeds as if there wasn't any prefix (creating a pdf with the default name, location and behavior). I take it adding a SLEEP 2 doesn't resolve it?
Sorry, pretty busy trying to resolve an email delivery problem. What black-hole, voodoo magic practice this is.
I think I've found the issue, and it's in our code. We prompt the "would they like to open the folder the pdf is being generated in". This uses MX_SHELLEX, it's supposed to be striping the filename via Fn'To'Host$() with flag=1 on local windows. Somehow the filename is still in the folder$ variable, and this is where the error message is prompting.
No idea when this started happening. I'm going to fix this on our side. Very confusing; since this did appear to start happening until I updated to PDFX 9.
He's a snippet of the client folder launching function.
Code
folder$ = fn'directory_exp'env$(folder$,DIRGENV_ATE)
XCALL AUI,AUI_ENVIRONMENT,MXOP_GET,guiflags
IF (guiflags AND AGF_LOCWIN) THEN
folder$ = Fn'To'Host$(folder$, 1) ! return just the directory part of the native path
ELSE
folder$ = fn'directory_get'dir$(org'spec$=folder$, mode=DIRGENV_ATE)
ENDIF
IF (guiflags AND AGF_LOCWIN) THEN ! if environemnt is any local windows
XCALL MIAMEX,MX_SHELLEX,fn'client_launch'folder,folder$,action,params
ELSEIF ((guiflags AND AGF_ATE) # 0) THEN ! if environment is ATE
XCALL MIAMEX,MX_SHELLEX,fn'client_launch'folder,folder$,action,params
