Hi, In advance, let me say that I'm pretty sure this has has nothing to do with the new driver or any update. I'm just searching for a cleaver tip where to search
Problem: When sending several documents in sequence via email, the attachment in every email is always the first generated PDF.
I've checked all the steps in the process and can't figure out where the attachment is selected. For each document is generated an output file with the filename like 200001.000, 200002.000 (doc number.000) which is sent to XCALL SPOOL The last lines in the document are the PDFX email statements, like method, subject, email address an so on, but none is about the filename. I've stopped the program and opened each file to confirm that are the right ones, exactly before the xcall spool, and they were.
I've done a TRACE for FOPENS and GDIPRT while printing two documents in a row, the image illustrates the two moments when theoutput file is processed by xcall spool.
The first one is for order 201255 and the output file is 201255.000 which is converted in 201255.PDF and attached to the email. I can't see the exact commands responsible for that, but there is an FLOOKUP processing 201255.PDF and a REMOVING for 201255.000
On the second file, the FLOOKUP still is for 201255.PDF but the REMOVING was for 201256.000
I think you've discovered a bug, but haven't yet been able to figure out why it doesn't happen all the time. (It's fairly common for one program to generate a lot of email messages, but perhaps not in combination with Method 5.) The bug is that the variable which is supposed to be holding the expected PDF output file name is being retained from an earlier setting. I'm tracking it down now...
I've been juggling the SDK compatibility settings while investigating the MAPI problems (switching between various editions of Windows 10 and 8), which makes me wonder what OS version you're having this problem on.
I've tried downloading the 6.5.1720.3c version from the link above, and have successfully run it on Windows 10, Windows 11, Windows 7, Server 2012 and Server 2019. So it doesn't seem like a case of an obviously defective version, although there still could be some particular issue with the OS version you're on. Unfortunately the traces don't help very much. You might try launching it with the -trace command line switch which will active several additional traces that might help pinpoint the issue.
