How to bypass using Report Designer to load variables into a Report?

[montypython1]

Greetings,

What options do I have to bypass using Report Designer to load variables into a Report?

I am building a very large report that will need about 500 variables and I am not looking forward to manually entering these variables one at a time in the Report Designer.

Since a VFP report is really just a database, isn't there a way to download my variables into the report?

Thanks,
Dave Higgins

 

[Mike Lewis]

Hi Dave,

Yes, as you say, this should be possible. But it will need a bit of experimenting on your part. Be sure to back up all your report files before you start.

Within the FRX file, report variables are held just like any other object. So you will need to add a record to the file for each variable.

Put the name of the variable in the Name field, and its initial value in the Expr field. Set Vpos, Hpos, Height and Width all to zero. Set the ObjType to 18.

You might also need to set TotalType and ResetTotal to some suitable values, but I don't off-hand know what those are. This is where you need to experiment.

You can probably leave all the other fields alone, except perhaps Platform, which contains "WINDOWS" (without the quotes).

Give it a try, and let us know how it goes.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Mike Lewis]

Dave,

A good source of information about the internal structure of a report file can be found in the Tools/Filespec directory (in the Visual FoxPro directory). Run the report named 90frx.frx to see the information (or see the Help topic, "Table Structures of Table Files (.dbc, .frx, .lbx, .mnx, .pjx, .scx, .vcx)".

Regarding my previous post, I said that Expr contains the initial value of the variable. The above report indicates the that it contains the value that is stored each time the record pointer is moved, that is, the "value to store" value.

Also, the Unique field should be set to .T. to release the variable at the end of the report.

Tag contains the initial value of the variable.

The report also gives more information about TotalType and ResetTotal.

Hope this helps.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Besides hacking the frx, an frx can access any public, private and even local variable in the same scope as the REPORT FORM command is run from.

I'm curious why a report would need 500 variables anyway, so what is your problem you can't solve by data or less variables?

Bye, Olaf.

 

[Koen Piller]

Hi,

500 (!) variables to be used in a Report? I am with Olaf, you will need a review of your codelogic.
Maybe a good option is to load these into a cursor which cursor will feed your report.

Regards,

Jockey(2)

 

[montypython1]

Hi Mike, Olaf and Jockey,

Thanks for your input. I will give your suggestions a try this weekend and let you know how it went.

You are correct ... 500 variables seems like overkill, but I need a report structure that is flexible enough for me to use for a number of different purposes. My idea is to simply pass variables to the report, which means my variables will also be my fields in most cases.

As currently designed, my variables use the following naming conventions (where the "_grp1" or "_grp2" designation refers to the section to be grouped and subtotaled):

FIELDS that will be "summed" and grouped by section:

- Field01sum_grp1
- Field01sum_grp2
- Field01sum_grp3
- Field01sum_grp4
- Field01sum_grpTot

- Field02sum_grp1
- Field02sum_grp2
- Field02sum_grp3
- Field02sum_grp4
- Field02sum_grpTot

- Field03sum_grp1
- Field03sum_grp2
- Field03sum_grp3
- Field03sum_grp4
- Field03sum_grpTot

- Field18.....

FIELDS that will be "averaged by vehicle sold" and grouped by section:

- Field01avg_v_grp1
- Field01avg_v_grp2
- Field01avg_v_grp3
- Field01avg_v_grp4
- Field01avg_v_grpTot

- Field02avg_v_grp1
- Field02avg_v_grp2
- Field02avg_v_grp3
- Field02avg_v_grp4
- Field02avg_v_grpTot

- Field03avg_v_grp1
- Field03avg_v_grp2
- Field03avg_v_grp3
- Field03avg_v_grp4
- Field03avg_v_grpTot

- Field18.....

FIELDS that will be "averaged by contract sold" and grouped by section:

- Field01avg_c_grp1
- Field01avg_c_grp2
- Field01avg_c_grp3
- Field01avg_c_grp4
- Field01avg_c_grpTot

- Field02avg_c_grp1
- Field02avg_c_grp2
- Field02avg_c_grp3
- Field02avg_c_grp4
- Field02avg_c_grpTot

- Field03avg_c_grp1
- Field03avg_c_grp2
- Field03avg_c_grp3
- Field03avg_c_grp4
- Field03avg_c_grpTot

- Field18.....

And so on and so forth.

If there is another way to achieve this flexibility, I would be open to suggestions.

Thank you again,
Dave

 

[JRB-Bldr]

In addition to my being 100% in agreement with those above who think that with 500 variables needing to be sent to a Report, you might want to review your methodology, I would like a little more clarity regarding your question.

I am not clear.

When you say enter variables into a report are you really meaning that you want to create 500 new textbox objects within the Report Form with their Expression, Location, Size, Etc. defined?

If so Mike's suggestion above would be the best.

But if you mean that you want to have the existing Report Form text boxes display 500 variable values, that is a whole different question - and much easier to do.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

I was about to make a similar point to that of JRB-Bldr.

Dave, you say you want to "pass variables to the report". I think what you mean is that there will be variables that are in scope when you launch the report, and the report will use them in one way or another.

That's quite different from report variables. I understand that term to refer to the type of variable that you create within the report properties dialogue, and use for things like running totals or line numbers.

When I talked earlier about hacking the FRX file, I was thinking of that kind of report variable. But that seems to be contradicted by your later comments.

If what you really want is a way of controlling the grouping and aggregations dynamically - to parameterise them, if you will - then I think you shold be looking for some other approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

You can draw amazing graphics in 16 x zoom mode by setting pixel by pixel - or you can use tools like line, fill, brushes, etc.

The natural way to use reports is to fill them with data.
report variables don't need to be created per record, not even per group. You can have one variable calculating a sum or average for a certain field or fields of your report data, being reinitilised per group of records and outputting it's result at a group header or footer or as a running total within the detail band, as you like.

Maybe you could tell more about what kind of flexibility you need and can't do with grouping, multiple detail bands and other stuff vfp9 reports offer.

Bye, Olaf.

 

[montypython1]

Hello Mike, Olaf, Jockey2 and JrbBldr,

My apologies for not responding quickly to your most recent suggestions.

I should have clarified that I DO indeed want to create a report that contains about 500 variables (defined WITHIN the Report Designer, rather than outside of the Report Designer). If my logic is sound (no guarantee of that), I should be able to make one report do the work of multiple reports, simply by re-assigning these variables outside of the report. For many years, I have been using variables extensively for data groupings, but have not yet attempted to use variables for each individual field. It will be a lot of work to set up the report initially, but the payoff should be increased flexibility.

Here are 3 simple examples showing how someone could use this:
- Report#1 needs to analyze the selling price of a vehicle, along with the service contract price, Gap insurance price, Tire and Wheel protection, etc.
- Report#2 needs to analyze the cost of the same categories (rather than the selling price).
- Report#3 needs to analyze the profit of the same categories (rather than the selling price or the cost).

To make each report work properly, all I would need to do is to re-assign variables for "Field01", "Field02", "Field03", etc. before the report runs, as follows:.

Report#1 (Price analysis) would be:
--- "Field01 = VehPrice"
--- "Field02 = SvcContPrice"
--- "Field03 = GapInsurPrice"
--- "Field04 = TireWhlPrice"

Report#2 (Cost analysis) would be:
--- "Field01 = VehCost"
--- "Field02 = SvcContCost"
--- "Field03 = GapInsurCost"
--- "Field04 = TireWhlCost"

Report#3 (Profit analysis) would be:
--- "Field01 = VehProfit"
--- "Field02 = SvcContProfit"
--- "Field03 = GapInsurProfit"
--- "Field04 = TireWhlProfit"

Data Grouping: Let's further assume that I want to sort and subtotal each of the above categories by ModelYear, Make, Model, then Color. I would simply assign the subtotals as follows:
--- "Group1 = ModelYear"
--- "Group2 = Make"
--- "Group3 = Model"
--- "Group4 = Color"
Based on simply assigning a specific variable (ex: "Field01 = VehPrice"), the report will automatically calculate the correct totals, averages, etc. for EACH data grouping. For example, "Field01sum_grp1" is defined within the Report Designer to calculate totals of whatever is defined as "Field01" ("VehPrice" in the case of Report#1) within the first data grouping ("ModelYear" if we are talking about "Group1").

In reality, there would be 18 or 19 fields listed horizontally across the report (not including the fields for data grouping). This is the reason that I would like to find a way to automate the assigning of variables within the Report Designer.

At any rate, I hope this clarifies my earlier posts, and your follow-up questions.

Thank you all for your input. As always, it is appreciated.

Dave

 

[Olaf Doschke]

- Report#1 needs to analyze the selling price of a vehicle, along with the service contract price, Gap insurance price, Tire and Wheel protection, etc.
- Report#2 needs to analyze the cost of the same categories (rather than the selling price).
- Report#3 needs to analyze the profit of the same categories (rather than the selling price or the cost).

Those reports all have the same layout, but different sources of the values.

I don't know why you simply create one report with a cursor having a "nValue" field that you then can fill previous to running the report with either price, cost or profit. You would only need one variable holding the column caption, which differs.

You're not really saving work with such a universal report as you plan. The difficulty to fill it correctly just is shifted towards filling variables from different source fields.

It's really much easier to use cursors, just for the simple fact the detail band will loop through all records, while working with variables only instead of cursor you will need to add more report controls, once you need more lines.

This is not really dynamic or elegant at all.
Even if you stil want to go that route, then what do you profit from predefining the variables in the report? You need to "fill" them from outside and that means you need generate the same variables the report would generate to "pass" them into the report, and then you can also do so without any predefined variables. You can set report control expressions to anything during design time, it just needs to exist at runtime, so you would not need predefined report variables and they only make an extra effort you will nevertheless not profit from, when needing to set the variables previous to running the report.

Bye, Olaf.

 

[montypython1]

Thanks Olaf,

You are probably correct that I may be creating more work than I am saving, but I gotta give it a try. Sometimes when you try new things, it pays off. Sometimes it doesn't.

For the record, my report does indeed use a cursor to populate the fields. I simply use REPLACE ALL on a READWRITE cursor to set the values based on the kind of data I need to see. After the field is defined (ex: "Field01 = VehPrice", then the associated variables get populated (ex: "Field01sum_grp1" sums "Field01" for the first data grouping).

If I can make it work, I will post the report for everyone to review

Thanks to everyone for their input.

Dave

 

[Koen Piller]

montypython1

I dont think you are getting the idea, the idea is not to replace all but to built a cursor with the data exactly as you would like to have them shown in the report, ready-to-print. When your cursor is ready you have to select from that cursor in a new cursor say curReport where the field names tally with the report fields.
3 different report - data wise - same layout making use of one and the same report.frx

Redgards,

Jockey(2)