Where to put EXTERNAL ARRAY?

[Mike Lewis]

Just came up against this interesting problem.

I have a form that creates an array and fills it with six lines of data. The form then calls a report, which references the array. To ensure that the array stays in scope while the report is running, I have declared it as PRIVATE.

This works fine when running in the DE. But when I build the app, I see compilation errors saying that the array cannot be found.

No problem ... just add an EXTERNAL ARRAY to tell the project not to try to resolve the reference.

My question is: Where do I put the EXTERNAL ARRAY? It needs to be placed in the file that references the array, which in this case is the report. But how can you place a compile-time command in a report? Whereabout would you place it?

In fact, the report runs OK, despite the compilation errors, so it's not a big problem. It's just that I'd prefer not to see any compilation errors if possible. I know I can get round the problem by using separate variables in place of an array, but it would be nice to avoid having to do that.

Any ideas would be appriciated.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olaf Doschke]

Why not? You can use local variables defined before REPORT FORM command, you can also use thisform inside the report.

As you see it does not work always. It's also not my understanding of how it should be, a report is like a new form, it should run out of the local scope. _screen.activeform might be a solution, as it is for a toolbar or in ON KEY LABEL.

I prefer to prepare a (global) parameter object (eg _screen.oParam) or put something into the cursor I report from.

Bye, Olaf.

 

[Mike Lewis]

I've now created a simple reproducible case where I can get the report to recognise THISFORM. I don't know why it didn't work before. It might be something unusual about either the form or the report.

I can also get the report to see _Screen.ActiveForm. In practice, I wouldn't do that, as I have a custom Form Manager which gives me a more reliable object reference to the active form, but the principle is sound.

No doubt I could also use _screen.oParam (as per Olaf).

However, I'm a bit uncomfortable with all these solutions. It introduces dependencies within the report that I'd rather not have. Of course, you could argue that using private variables (as per my original post) does that as well.

Another approach might be to add the required data to the cursor that drives the report. That's not very efficient, because you might only need one value for a heading, but you would have to add it to every record. But it would work.

For now, I'll stick to private variables and arrays, although I might re-think this for the future.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olaf Doschke]

Hello Mike,

good thoughts indeed. Yes, a form handler can give you a more reliable reference. Then there is the concern about dependency.

Private vars or arrays are easiest to implement, especially if you use the report in a totally different application with another application framework.

And if you also want to start a report from a menu instead of a form, thisform and _screen.activeform are no good idea.

You can prepare more than the one report driving cursor and you can reference fields of the parameter cursor by curParams.field.

Bye, Olaf.

 

[NasibKalsi]

Reports are dependent on the caller, and caller sets up the environment what data to exibit. It can be a form, menu, etc. Considering all suggestions, I think it is better to use 'thisform' than the 'dummy function' or others. May be one day we will have init, load, methods available for reports.

Nasib Kalsi

 

[Mike Lewis]

Nasib,

May be one day we will have init, load, methods available for reports.

Well, in a sense, we do. We have the Init of the Data Environment, and we can write expressions to run on entry to the title band.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[NasibKalsi]

Thanks Mike. I mean As init() of the Form. And all data and vars local to the form. It looks like it is true for Reports as well, except the Arrays. So that all the data requirement be put in the init() and can be called from any where and report will be produced as required. It may be capable now, as you have expressed. But I am not there yet.

I am still learning, but in the near future I will exploit the capabilities of Data Environment, etc. and will be able to comment then.


Nasib Kalsi