Foxypreviewer - Vartype(_Screen.oFoxyPreviewer) 1

[Bryan - Gendev]

I have read the previous posts re Foxypreviewer but I can't solve my problem.

I use Foxy 3 times in my app - 2 work 1 does not.
It all depends on the result of Vartype(_Screen.oFoxyPreviewer)
This requires a value of NOT O - in my case I see the 2 working reports have a value of U whereas the failing one is O
At the moment I have the same code routine in a separate prg for each report the only variable being the report and table name. I have Set REPORTBEHAVIOR 90 prior to the REPORT FORM command.
What causes the O situation please?

GenDev

 

[Chris Miller]

Bryan, why should "U" be the good type and "O" bad?

"O" means it's an object, you created the foxypreviewer object and it can be used. You only need to start/create the foxypreviwer object once and then can use it as many times as you need and like.

If your reports require "U", that means undefined, FoxyPreviewer is not yet created or was destroyed after a previous report run and your code then likely creates it and destroys it after this report run, which fails sometimes.

Just don't do it that way. Start Foypreviwer once in main.prg and then use it throughout your application session. There's no reason to create/destroy it for each report again and again.

Chriss

 

[Chris Miller]

To make a few things clear:

It can work to create and destroy foxypreviewer for each report run but now you see the downside of that. You recognize with your verification code that at some other point in all your project you forgot to release/destroy Foxypreviwer and now it still exists where you expect it to be undefined.

There's the simple healing of the symptom to destry foxypreviewer when you detect it is "O" at a point where you want it to be "U". Well, that doesn't tell you where in all your project code the destruction/release of foxypreviewer is missing. Maybe it is not even missing in the code itself, it just is not executed. One problem with that is that you can't destroy the ruinning foxypreviewer object when a report is running (in preview or printing mode, doesn't matter), so that tidy up destruction has to wait after the report finishes. There is no general finishing event for reports, though, the simplest case is after a REPORT FORM command, as the report preview is a modal thing, so you only get to the line after REPORT FORM after that's trough and the report has printed at least up to the printer spooler. That differs a bit when using sepcialties like a reportlistener.

I don't know how you generally act, as you post no code, but all that again speaks for using one foxypreviewer object to not create/detroy it for each report run.

If you don't change to that your problem is finding the place where a relase/destroy is missing. So your problem unfortunately isn't concentrated and can be fixced in the place where you detect the foxypreviewer is still up. You could ignore and then simply use the foxypreviewer, you may depend on the create/destroy way of using foxypreviewer because you want to reset everything to defaults by always creating a new foxypreviewer instance. Anyway, there's no easy fix for this, you either rearrange a lot of reporting you do or find the one place where releasing foxypreviewer is not done.

Chriss

 

[Bryan - Gendev]

Chriss,

Many thanks - domestic issues needed my attention.
I have modified my code with one prg doing the foxy work. It is called in just 3 areas in my app.
till 2 places it works and once not. I now understand the 'meaning' of the U and O instances and will further chase they instances.
110-15 years ago I gave the users a choice of using native vfp reports or foxy. Thus I do open and close foxy in my foxy prg.
Over the last month or two ( since getting back to dev work on my app) I have had random happenings of foxy not working as I run through the various phases of my app.
As it happens at an end point of my operations I haven't chased it until today.
So I will hunt it down tomorrow.

Cheers

GenDev

 

[Chris Miller]

I gave the users a choice of using native vfp reports or foxy.

For what reason?

Well, it explains why you choose to do so, then good luck in hunting down where and why it happens that foxypreviewer sometimes exists, when you don't want to use it. As you say you have your foxy.prg to run reports through foxypreviewer, it's the same for all reports, is it? The actual report printed, is it a parameter to that foxy.prg? If that's the case, you're lucky on one side, that you have your only prg code everything goes through. Then the question of course becomes whether under some circumstances your foxy.prg does not get to the point to release the foxypreviewer.

The other reason, of course is, you overlooked one place where you do things different than foxy.prg and don't call it, so one place - maybe more places - where you didn't change code to call foxy.prg

Chriss

 

[Chris Miller]

It could help to give recommendations fopr finding out what to look for, if you post your foxy.prg

One way to start foxypreviewer is by just calling

DO FoxyPreviewer.APP

or in short

DO FoxyPreviewer

So if you find that in other places athan foxy.prg you have your source of the offending _screen.oFoxypreviewer object.

But there are other ways to star foxypreviewer and there are also multiple ways to release it. Given that you collect a lot of code, your code might mix all the ways, so it becomes quite hard to find offending places. Whyt you cuold do is start your pap within the IDE with a breakpoint on the condition that Vartype(_Screen.oFoxyPreviewer)="O", then you will get the program suspended whenever foxypreviwer is started. The likely is generated somewhere within foxypreviewer.app without source code available, but you then would just need to step one level up in the callstack - that's a window in the debugger, too, to see what causes foxypreviewer.app to become active. In the long run you then find all places you could find by code references search - or GoFish, if you use that.

Chriss

 

[Bryan - Gendev]

Hi Chriss,
I have now got my 'opening' of foxy in one prg. Today I got a 'Too Many Variables' error for some reason so I upped my MV= setting in config.fpw
So now I have all three areas where foxy reports are generated working. I have removed the option to use standard vfp reports so all users will get to use foxy all the time.
One 'happening' was putting the foxy.app opening in main.prg . This did not work so I am staying with my opening and closing of foxy after each use in a reporting session.
All occasions work in the compiled and installed exe.
I am feeling good now...on to the last section of my app to test for 'bugs'.

Regards
GenDev

 

[Chris Miller]

putting the foxy.app opening in main.prg . This did not work

Well, if you then still have the foxy.prg starting it again, you of course get errors.

Doesn't matter, if all is well, then all is well.

Too many variables? What are you doing?

Chriss