Usage Instructions for FoxyPreview 3

[Bryan - Gendev]

I have added FoxyPreviewer to my app and am well pleased with the results on my development PC.

Now when I try it in a compiled executable of my app I get error messages. Before I try to decipher these am wondering if there is a howto type doco.

I have looked at the web pages , FAQs etc but can't get a clear indication of what is required in addition to the FoxyPreviewer.app file placed in a R/W folder. The sample distributable app in the D/L info doesn't seem to have anything additional.

Thanks for any clues.

GenDev

 

[Olaf Doschke]

see

http://foxypreviewer.codeplex.com/documentation

USAGE

DO FOXYPREVIEWER.APP 
REPORT FORM YourReport PREVIEW

And it also says:

That means that all you need to do is to "DO FoxyPreviewer.App" at the beginning of your executable, and ALL your reports that use the "PREVIEW" clause will be shown using the simplified but super powerful interface of FoxyPreviewer!

Bye, Olaf.

 

[Bryan - Gendev]

Olaf,

That's what I have done so I have to investigate further.

Thanks

GenDev

 

[Olaf Doschke]

There's (of course, but perhaps not naturally to you) one more thing essential for the app to work as the report preview, which is REPORTBEHAVIOR 90, if you SET REPORTBEHAVIOR 80 the preview of a report is always the internal preview of the VFP runtime, only in the new rerpoting behavior another previewer, like FoxyPreviwer can work.

I'm unsure whether doing the APP itself doesn't set the reportbehavior to 90 itself, so no further code is needed, but of course if you have a line of SET REPORTBEHAVIOR 80 anywhere, you turn off foxypreviewer, also it does not work, if you don't have the PREVIEW clause in your REPORT FORM calls, it can't hurtto explicitly SET REPORTBEHAVIOR 90 before each REPORT FORM ... PREVIEW, which should use the foxypreviewer.

Bye, Olaf.

 

[Dan Freeman]

You say you get error messages but you don't say what they are.

Are they complaining, perchance, that reportoutput.app isn't available? Is the error "out of disk space"? There are a LOT of possible errors and each leads to its own solution. Which one is yours?

if you SET REPORTBEHAVIOR 80

It's worth noting this is the default. You don't have to actually do anything to get it.

 

[Olaf Doschke]

It's worth noting this is the default (ReportBehavior 80).

Yes, it is notable. But you must assume if DO FOXYPREVIEWER.APP is the only prerequisite you need to do per documentation of the foxy previewer developers, that includes setting REPORTBEHAVIOR. It should also set the _REPORTPREVIEW system variable.

Actually, why make assumptions?

FoxyPreviewer comes with full source code of the project precompiled to foxypreviewer.app and among many more intialisation code it has these three lines:

		* _REPORTPREVIEW identifies the preview container factory application.
		* This program is called by Visual FoxPro when:
		* • the report engine is assisted by a ReportListener object, and
		* • the ReportListener has a ListenerType of 1, and
		* • the ReportListener does not already have an object reference assigned to its .PreviewContainer property.
		_ReportPreview = m.tcSys16
		SET REPORTBEHAVIOR 90

So both things are done by DO FOXYPREVIEWER.APP, this is all you need. And of course you need to deploy FOXYPREVIEWER.APP with your exe and you need VFP9 runtimes, this will perhaps not error, but not work with VFP8 runtimes.

The only other way this does not run is you don't PREVIEW or you explicitly SET REPORTBEHAVIOR 80 anywhere after DO FOXYPREVIEWER.APP. You could also set _REPORTPREVIEW and override what foxy previewer sets. Eg the help topics of VFP for application distrubtion tell you to deploy the REPORT*.APPs coming with VFP9, this of course get's wrong, as you now use FoxyPreviewer, the REPORT*.APPs of VFP are not needed, all of them, foxypreviewer also handles the _REPORTOUTPUT setting, only _REPORTBUILDER stays the default, but that would only be needed, if you allow users to edit reports vie MODIFY REPORT, surely neither ofr previewing nor the final print output.

Bye, Olaf.

 

[Dan Freeman]

Actually, why make assumptions?

That's why I asked what error message the OP is getting. We don't actually know. It could be "too many memory variables" for all we know, and then all the guessing about SET REPORTBEHAVIOR and everything else about reporting are sort of moot.

 

[Bryan - Gendev]

Thanks Guys for all of the advice.

Yes - initially it did complain that the app file was in an RO folder ( my apps program folder ). I am about to change that in my code and will see if that cures the errors.

Incidentally - one error I got on my dev PC was that C:\temp\cover.log is too large.

I found I had set coverage in my main form some time ago and forgot to turn it off. I have now.

I am currently testing whether the error will remain as my coverage file was coverage.log not cover.log. ( Maybe this comes from ProxyPreviewer ?)

Time will tell.

GenDev

 

[Bryan - Gendev]

I can't find cover.log when searching through the FoxyPreviewer source files.

The cover.log file remains and foxypreview gives a dialogue saying C:\temp\cover.log is too large with ignore as an option - I pressed this countless times but it must be in the report scan loop which has 15000 records.

Reading the cover.log I find the first entry to be from my main.prg and the line is Clear Memory.

From previous advice here (?) I have these lines at the top of my main.prg

Clear Memory
Close Data
Clear All
Close All
_Screen.Visible=.F.
_Screen.Themes = .F.

Is this good practice?
Does Clear Memory start the c:\temp\cover.log in memory and then writes to disk later, as I don't see it when I have Explorer open on that folder as I run my app? It seems to write only when the error dialogue is shown.

I'm still on my dev pc.

Thanks

GenDev

 

[Bryan - Gendev]

I removed

Clear Memory
Close Data
Clear All
Close All

From my main.prg and the cover.log file is no longer written.

I have now created the distribution file and FoxyPreview runs on my test PC.

So maybe I'll leave it that way unless anyone has any better ideas.

GenDev

 

[Olaf Doschke]

VFP doesn't write any logs on it's own. So there's gotta be a SET COVERAGE line in your code anywhere. In foxypreviewr sourcecode the only two places the word 'cover' appears in the code (alone or as part) are a comment "* Class does not cover General fields, if they were in report expressions" and another comment "&& on possible discovery of an image control mid-way", so Foxy Previewer does no coverage logging whatsoever.

"cover.log" sounds like a name choosen for a coverage log. It doesn't mean anything, though, that this message about the cover.log exceeding the 2GB limit comes from foxypreviewer code. The nature of coverage logging is, it logs every single line of code executing, every single line, no matter what code, your own or others. So an exceeding of the file limitation can happen anywhere. The fault obviously is to always reuse the same coverage log and never start with a new one, this has to break at some time. And it doesn't reset to 0 then, it chokes again and again.

Not mentioning that error and telling reports don't run the preview is a bit like telling your car doesn't accelerate when you give more gas, after the motor choked. Very essential information.

Even if you designed your error handling to ignore repeating errors, the next line executing again writes to the cover.log and again the log will rise above 2GB, revert to somewhere short before 2GB and choke and choke again and again. Coverage is not meant to be run additionally all the time, you should limit your logging to parts of your application known to have a problem. In some cases it might be useful to log all code running, but not for an application rnning indefinately. If you really want to slow down your app and want to do this every time and all the way, the log get's as useful as the whole code of the application is, to finding where an error is. Well, the last line of the log is telling you about the error location, but ON ERROR could do that, too. A few lines before that can help see where you came to the failing line and what pre running code has set the way to the error. That's fine, and that's how coverage logging can help, the intention is actually to do coverage tests, seeing if your testing calls of functions, precedures, methods do cover every case, every line and this if you test calls with text parameter values make the code branch into each case or each if and else branch of any code that does only execute conditionally. If you do too less tests of eg a function having two IF statements, your test may only test the if and else branch of the first IF and the else branch of the second IF, but your end user might cause the if branch of the second IF to run and there might be an error your tests haven't covered. That's where the name coverage log comes from, and the default mode of the coverage profiler will show you which branches of code have executed and therefore been tested and which not.

2GB log of code having executed are just a wast of disc space and user time, as coverage logging really slows down the application. Did I say it's logging each single line of code executing? In a loop it's not logging each line of the loop once, it's logging each line of the loop as many times as the loop repeats the execution of it's loop body. You don't need that, you don't want that.

What you should do at least, is to restart with a new log file at every program start. 2GB are very little space for such extensive logging of every single line of code executing and it's only needed for debugging purposes, not as a standard way of logging everything that runs to be able to spot where errors happen. This is also missing essential info: Variable values and states. So it's a huge log not even giving you all the answers you'd need in all cases to debug errors.

To clear things at startup with CLEAR and CLOSE command is not needed for an EXE, but can't hurt and will help you to reset whatever you did in development, if you test starting the main.prg within the IDE, therefore I could have been the one recommending these lines, but they are not needed for an EXE, and they don't stop coverage logging, as far as I know, have to test that.

The thing "officially" stopping coverage log is SET COVERAGE TO (without a file name, just the pure SET COVERAGE TO, like SET ORDER TO set's no order, this sets no coverage log file and therefore ends logging). But coverage logging also doesn't start without a SET COVERAGE line.

Bye, Olaf.

 

[Olaf Doschke]

if you test calls with text parameter values -> if your test calls with test parameter values

 

[Bryan - Gendev]

Olaf,

Thanks for that.

You say 'there's gotta be a SET COVERAGE line in your code '

I have searched for SET COVERAGE in the Code References tool and get a blank response so it isn't there. How else can I check?

I got the error message again just now.

I have added SET COVERAGE TO to my main.prg environment variables.

I'll run it again soon.

GenDev

 

[coppensg]

The documentation regarding distribution of the application says:

The usage is simple:

1 - Simplified mode:
Just store the FoxyPreviewer.App file somewhere at the LOCAL disk, in a place that can be found by your executable. Make sure to make "SET PATH" include that folder.
DON'T embed this file in your project. If you want make sure to mark this file as "Excluded"

Perhaps you forgot the setting of the path to the foxypreviewer.app.

 

[Olaf Doschke]

You dno't need to set path to a directory of foxypreviewer.app, if you put it just right where the EXE is you can DO FoxyPreviewer.App. If you put it elsewhere , of course you'll need to DO d:\elsewhere\FoxyPreviewer.App instead or add the Path to SET PATH, sure.

DO does not look anywhere to find a file and execute it, like USE also doesn't look all places for your tables. You can choose to specify a full or relative path or add a path to SET PATH, both for APPs and DBFs.

In reagad to adding the app into the project manager: Well, this mereley gives the build process the info it might find prgs, functions, classes inside the APP file and doesn't need to warn about not found files etc. You can't compile an APP into your EXE, it will always need to remain seperate. And the project manager therefore doesn't allow to include an APP into compilation. So "DON'T embed this file in your project" is an unneded warning, you can't anyway. If you add an APP, it will be listed in the code code page, beneath the API libraries node, and it will be listed as excluded from compilation and you can't add it to comilation by the context menu.

Bye, Olaf.

 

[Bryan - Gendev]

Thanks Guys,

The path to foxypreview is the current path when it is called and reports are generated.

So still no clue as to where the c:\temp\cover.log message comes from? It can't be from the SET COVERAGE as I have SET COVERAGE TO in my main prg.


GenDEv

 

[Olaf Doschke]

If you SET COVERAGE TO in your main.prg doesn't mean there is no other code in your whole project that sets this on again.

Use "Code References" from the Tools menu and search your whole project for the word cover. I did so with the foxypreviewer project and it is not in there, despite in the two comments I found. It has to come from your code or any other third party component.

Bye, Olaf.

 

[Bryan - Gendev]

Olaf,

I said before (above)

You say 'there's gotta be a SET COVERAGE line in your code '

I have searched for SET COVERAGE in the Code References tool and get a blank response so it isn't there. How else can I check?

Gendev

 

[Olaf Doschke]

Do you use any DLLs, other APPs? Other EXEs? Then you would need their source code to also search in there?

Have you done as I said and searched for "cover", not SET COVERAGE TO? That's already too specific. Cover would also find places where code specifies cover.log

Is cover.log actually a coverage log? Can you post a sample line? If it is a coverage log and it fail when your EXE is running, there is no other way than a SET COVERAGE in some code you use, to set that kind of logging on.

Bye, Olaf.

 

[Dan Freeman]

There are many things that could create a file called cover.log. The naming makes it sound conveniently like it came from SET COVERAGE but it could be coming from textmerge, low level file functions, or even SET ALTERNATE.

Something in your app is opening cover.log for output and writing to it without limits. You need to find it.