Davidp41,

welcome. It's always good to hear more people thn are activley posting profit from the forum.

Quote (Davidp41)

the problem I am having is changing the name from invoices.frx to SmithJ.

Quote (Davidp41)

When I tried this using a memory variable it failed.

I could only point out what you did wrong, when you post your failing code instead of what works.

If a concrete file name works, then it should also work when first put into a variable. Does it work, though? I assume the actual problem is that foxypreviewr jut generates a file with the name of the FRX, just with the extension changed to PDF.

I think it depends wheter you use the last verson belwo 3, the 2.99something version vs the 3.0 version. But I would also solve this by just renaming the output file after FoxyPreviewer generates it, that'll work anyway.

Chriss

What fails is
cFname = ALLTRIM(playersnames.filename) +ALLTRIM(".pdf")
cfname = "c:\users\userpc\documents\invoices\" + cFname
REPORT FORM invoices FOR ebu_number = ebNum;
OBJECT TYPE 10;
TO FILE cfname
This brings up an error FX_6VP0TZMO0
Error 10
Method unloadreport
Line 18
SET CONSOLE&llConsole
on closing this a message box Variable " is not found

I generate a new pdf and try to rename it using the RENAME in Foxpro
Code
cNewFile = ALLTRIM(playersnames.filename) + ".pdf"
cNewfile = "c:\users\userpc\documents\visual foxpro projects\" + cNewFile
RENAME "c:\users\userpc\documents\visual foxpro projects\invoices.pdf" TO cNewFile
This just comes up with file already exists message and nothing happens.
As there are usually 30-40 to change I really need a program to achieve the name change.

David,

The first thing to do is to examine the contents of the variable, cfname, to check that it contains what you expect. It is easy to go wrong when attempting to build a file and path name by concatenating the various elements in this way.

So, when you see the error message, hit the Suspend button. Then bring up the Debugger (by typing DEBUG in the command window). In the Debugger's Locals window, scroll down and look for the cfname variable. That will tell you exactly what it contains.

If the variable is not present, or you don't see an error message containing a Suspend button, then put SET STEP ON immediately before the REPORT FORM command. Then bring up the Debugger, as above. (And remove the SET STEP command when you have finished.)

(Welcome to the forum, by the way.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

That fails because VFP then will try to rename the incoives.pdf to literally cNewfile, not the value of the variable cNewfile. That maens...Look into c:\users\userpc\documents\visual foxpro projects\. I bet you find a file called cNewfile there, from the very first time you ran this, which worked. Now it warns you it doesn't overwrite existing files.

For that to work the way intended you need
See the term "name expression" in the help.

The brackets make a difference here in what VFP sees in that. And it's a bit annoying because all that would not arise if they would have decided against the ability to write literal file names without quotes in commands like COPY TO or CREATE TABLE or RENAME <file>. It's useless in case the file name has spaces anyway.

Chriss

Thanks Chris that worked

I am using Bullzip to create the pdf using the following code
DO WHILE NOT EOF()
nEbunum = Ebu_number
REPORT FORM invoices.frx FOR EBU_Number = nEbunum noconsole TO PRINTER
cOldFile ="c:\users\userpc\documents\invoices\invoices.pdf"
cNewFile = ALLTRIM(playersnames.filename)+ ".pdf"
cNewfile = "c:\users\userpc\documents\invoices\" + cNewFile
RENAME (cOldFile) TO (cNewFile)
SELECT playersnames
SKIP
ENDDO
Works perfectly when I run under the debugger to a breakpoint and F8 but when I try to run it as a non-stop program it tries to find the old file before Bullzip has created it an comes up with an error.
I tried using Foxypreviewer bt this adds unwanted line to the pdf. Any suggestions would be welcome.

It works with the debugger, but not without? That's probably because the file cOldFile simply isn't quite done yet, the driver needs some more time.

You could simply pause the program for a few hundred milliseconds just before you invoke Bullzip. One way to do that would be like this:


Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Quote:

but this adds unwanted line to the pdf

If you tell what, we might find out where to get rid of that.

The way to cover Bullzip means to be more intelligent about waiting for the invoices.pdf to exist and be able to rename it. First step is waiting for the file to exist, next step is trying to FOPEN it with write permission, as long as that's not working wait for Bullzip to finish.

If you use Bullzip you also have means to configure it via Windows printer driver settings to change the name of the output file to something else that could also work for you.

Chriss

I will try Mike’s suggestion as that fits with Chris’s second remark.
I would like to configure Bullzi to accept the name of the output instead but have no idea how to do this and find the documentation less than helpful.

Just note that waiting for a fixed time will not guarantee the print job finishes, even if most PDFs are generated fast, one day the PDF will take longer.

Therefore actively wait for what you want to see happening and finishing. I bet you could also get more complicated and hook on Windows print job queue and find out when that becomes empty again, but as you know a file will be generated it's best to wait for exactly that to happen, and for the file to be available to your renaming, which only can be done, when Bullzip has closed it.

Well, even if you could rename it earlier, it would make Bullzip fail to write to it, wouldn't it?

Chriss

Instead of using a fixed amount of time to give more time for BullZip to complete; I would suggest using a loop to try to lock the output file. The fixed time might work most of the time, but as Chris indicated above, one might take longer.

I would suggest something like:

Greg

David,

Did you really mean to expose your email address in this way? If not, you might want to hit the Edit button (at the bottom right of your post) to remove the images, then perhaps upload a version with the email addresses blurred or removed.

If you are not worried about this, just ignore it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Attached two images showing the different outputs from Foxypreview and Bullzip. Would be grateful for any advice on how toget rid of the line and correct the logo.

Images in wrong size remind me of the advice we gave a lot of time by now, using


You can do this quite as the first commands in main.prg

Or think about adding https://github.com/atlopes/DPIAwareManager to your project.

But you should also be fine using the latest FoxyPreviewer, because in the later versions, at least since about 2.5 I think, FoyPreviwer has already been mde dpiaware, which version are you using? If your answer is I don't know I downloaded it way back, just a simple refresher on the thought that a problem with a software usually could have become known and fixed in a later version...

Regarding an extra line, you literally meant a line, as you first talked about that I thought it was a line of text, like a comment added by FoxyPreviewer. Well, a Line object doesn't creep into a report on itself alone. I can't see how Bullzip doesn't print it, but there has to be a line object in your report layout that you don't want to print, maybe right at the edge of a band, like the detail band. So, well, find it and remove it. It may help to higher the size of a band where it hides off. So maybe FoxyPreviewer has a bug not respecting objects off view by band height, but then I'd rather delete a line I don't want to print then hide it away off limits.

Regarding the image, you may also alter its properties (right click the image and pick properties) from "Clip contents" to "scale contents, fill the frame", for example. Depends what you want, but if the image looks clipped alreadyy in the report designer, then this time Bullzip disregards the clipping and prints the image as large as it needs to be anyway. I'd say while the result is what you need Bullzip then plays it wrong. Just assumptions, though, but you see you have options in how an image is printed and scaled or clipped.

Chriss

Thanks Greg the code worked perfectly.

You are welcome. Glad you have a solution that is working.

Greg

That's about the idea I had, including a timeout. If it really takes a few seconds to generate a PDF that's okay that way, otherwise make the sleep interval shorter and the max lnLoopCnt higher. You might also let the user exit with a key by checking INKEY(), too.

But I'd also look into where that line comes from in the report designer or, if you don't find it there, USE your.frx as a table and look for a record with OBJTYPE=6.

Chriss

The line was invisible. Clicked on it and deleted it.

Good to hear there really was a line object. Not sure what you mean with "it was invisible".
If a line is out of sight by being moved into the grey title area of a band it may be in "no mans land", but would still be printed, there also is no visible property, reports work totally different from forms, there only is a print when expression you can set to print it conditionally or not. Where it was it seemed like a line someone thought would go away by moving off the white band area, but since bands are repeated also things with negative coordinates appear above the normal band area.

So the FoxyPreviewer actually does it better, even though the outcome with Bullzip is better for you. Nevermind, if it works don't break it now by trying to get it converted with FoxyPreviewer, too. I bet the "scale contents, fill the frame" setting for the image would also solve the last problem. Anyway, you already got it done with Bullzip now.

Chriss