Report not receiving data properly

[BlueSharpe]

Hello, i am new to visual fox pro and i am currently learning how to make reports...

i have a really weird bug after 4 hours of searching and trying i have exhausted all my ideas and routes..

i have created a report that seems to work perfectly fine when im previewing it from the GUI. but the moment i am trying to generate it during runtime,, it keeps telling me that the Alias does not exist... or that a certain variable(which is a table field) does not exist...

ive checked the aliases multiple times... i've tried adding and removing it.. i've tried closing all the databases before generating the review hoping that it would just grab all the data from the generated files instead...i tried to check the field names of databases when the report is generated but all the functions that i though were related to seem to not be called (BeforeOpenTables and Init) instead it jumps directly to the destory function..

nothing seemed to work and i am out of ideas.

 

[Steve Yu]

It would help people understand your problem if you include your coding examples.

 

[Chriss Miller]

Since you're completely new, there are two standard ways to feed a report with data.
1. The report has a private data session and you add the table or tables you want to print in the reports data environment
2. The has no private data session and you feed it from whatever is the current datasession in the code starting the report.

You mention using the BeforeOpenTables and Init events/methods of the report. I wonder whether you simply have a completely wrong uinderstanding of how a report should work.

The more popular and also recommended version to use is the second. The encapsulation principle of OOP programming speaks against it, but it follows the general principle of working on the currently selected workarea when it comes to data. Any Foxpro commands that work on data by default work in the current workarea, a concept you should know or get familiar with.

For example REPLACE replaces in the current workarea, BROWSE browses the current workarea. etc. Generally, any command that has a FOR clause to filter records works in the current workarea by default. And REPORT FORM has a FOR clause to filter records to print.

It's even more to the point to prioritize this principle for reports than OOP principles, as a report is always driven by on workarea. You can imagine a report as a scan...endscan loop printing the detail band for each record of the workare (filterd by FOR) besides printing other bands like page header/footer, etc., Besides concepts of groups and their header/footer bands, etc. So usually you give up the idea of a report to be standalone and encapsulate report driving code that prepares data before the REPORT FORM call with the report.

If you just touch the topic of reports for sake of getting an overview of VFP, the help should give you enough tips about how reports work. If reports are a major part of what you will use VFP for, I can recommend books from Cathy Pountney published by Hentzenwerke, like "The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond".

 

[igorsandler]

Since you're completely new, there are two standard ways to feed a report with data.
1. The report has a private data session and you add the table or tables you want to print in the reports data environment
2. The has no private data session and you feed it from whatever is the current datasession in the code starting the report.

You mention using the BeforeOpenTables and Init events/methods of the report. I wonder whether you simply have a completely wrong uinderstanding of how a report should work.

The more popular and also recommended version to use is the second. The encapsulation principle of OOP programming speaks against it, but it follows the general principle of working on the currently selected workarea when it comes to data. Any Foxpro commands that work on data by default work in the current workarea, a concept you should know or get familiar with.

For example REPLACE replaces in the current workarea, BROWSE browses the current workarea. etc. Generally, any command that has a FOR clause to filter records works in the current workarea by default. And REPORT FORM has a FOR clause to filter records to print.

It's even more to the point to prioritize this principle for reports than OOP principles, as a report is always driven by on workarea. You can imagine a report as a scan...endscan loop printing the detail band for each record of the workare (filterd by FOR) besides printing other bands like page header/footer, etc., Besides concepts of groups and their header/footer bands, etc. So usually you give up the idea of a report to be standalone and encapsulate report driving code that prepares data before the REPORT FORM call with the report.

If you just touch the topic of reports for sake of getting an overview of VFP, the help should give you enough tips about how reports work. If reports are a major part of what you will use VFP for, I can recommend books from Cathy Pountney published by Hentzenwerke, like "The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond".

Most likely, the form creates the alias but report set to private data session, like you said. Even though I don't understand how what did he mean by able to preview it but running the form it doesn't work. Seems preview in design mode, not GUI

 

[Chriss Miller]

I don't understand how what did he mean by able to preview it but running the form it doesn't work. Seems preview in design mode, not GUI

I wouldn't wonder in detail about what goes on there, it's up on BlueSharpe to provide more details. I would imagine you open up some tables to design the report, as that allows to make use of the Expression Builder dialog, for example. Then the rerpot runs fine from the report designer preview, but not finally.

 

[igorsandler]

Agreed

 

[Joe Crescenzi]

I agree, it sounds like it works in the preview in the Report Designer because the tables or a cursor were open and selected, but when when it's run from within his code the table(s) or cursors are probably not open and/or in the selected area.

If that's the case, the fix is to either add a couple of lines to make sure the tables/cursors/views are open and selected, or as you pointed out, add them to a DataSession (which I'm not a fan of).

 

[Chriss Miller]

Perhaps I should add, BlueSharpe, what I explained was a basic concept not only of reports.

If you take that concept of the current workarea into consideration you automatically arrive at a solution that differs from what I assume you're doing. But I don't exactly know what your doing, until you post more about that.

Anyway, if you start from scratch with that concept of both the current workarea and the report driving workarea in mind, you could start from scratch and get something going to build up from there. I can tell you that I also already did use a reports code sectin to process data into the data printed. Events like "BeforeOpenTables" actually run before the report starts printing and you can create print data there, but that's not the basic operation of a report, that's advanced stuff and as a newbie you shouldn't start there. Notice one thing that already is different from what you assume:

When we started testing this stuff, we got a real shock. BeforeOpenTables does not fire before the OpenTables method. That’s because BeforeOpenTables is misnamed. A better (though terribly unwieldy) name would be BeforeAutoOpenTables because this event fires right before tables are opened automatically. If there’s custom code in OpenTables, that code executes, then BeforeOpenTables fires, then the tables are automatically opened. (Of course, this behavior means there’s not much use for BeforeOpenTables. Almost anything you’d want to put there could just as soon go in the OpenTables method.)

That's taken from https://hackfox.github.io/section4/s4g329.html

It's one of the many quirks you have with VFP that assumptions are never a good recipe to understand something intuitively. It's not that bad that anything is unintuitive in VFP, but it's good to have a read of the help and other sources to understand how something is supposed to be used and works simpler.

 

[BlueSharpe]

hey guys sorry for the late reply... to be short the problem was eventually solved... me and a colleague, which has more experience, have been scratching our heads over one this one for a while... everything should have worked but it just didn't... after trying a couple of things we decided to just redo the report... and after it was remade with a different name... now everything works just as intended..

both the BeforeOpenTables and Init functions are now triggering properly in the correct order and the report is being filled correctly... we no longer have the original broken version but i think the only possible reason was that the report was not accessed properly ... it was probably a broken link or path somewhere...

but looking in retrospective... it would be nice to know of better way to track and diagnose these issues in the future.

alos many thanks for the hints Chriss... i will bookmark these for later use.

 

[Steve Meyerson]

...the general principle of working on the currently selected workarea when it comes to data....

 

[Steve Meyerson]

BlueSharp,

One more thing. Chris is not only correct, but points out, in my opinion, the most important principle to develop reports for a specific task. You might want a report containing data from multiple files, but you know it scans only a single table. Many many times in my experience I have had to create a table (usually a cursor) containing data from multiple tables. That can be a programming challenge but once done, the report design is simpler since you will usually design it from a single table only. I say "usually" because you can easily draw data in the report from any other table which is open and on a specific record.

Steve

 

[Chriss Miller]

it would be nice to know of better way to track and diagnose these issues in the future.

The usual stuff, which may still be unknown to you at least the VFP way.
1. Error handling with ON ERROR, the Error event and TRY..CATCH...ENDTRY
2. Break points, especially in reports with code
3. Ensuring the current workarea has data, otherwise the report will not be empty, it just won't show at all. In reports with a private datasession that has to be the initialselectedworkarea according to the data environment, or whatever code selects but as said it's usually not a good idea to use a private datasession in a report.