Not exactly, those the report wishes to use must be set. There can be extra ones coming from the application. This becomes relevant when your software has to support several versions of the same QRP over many years.Dave Rabelink wrote:I'm not a Report Builder expert (I mainly use Crystal Reports) but correct me if i'm wrong.
The variables you set using SalReportSet*Val are defined in the QRP, right ?
So the list of QRP internal variables is the complete set which could be set (all of them, some ore none).
Yes, that was what I said I was going to do (see the 3rd post of this threadDave Rabelink wrote:When you create wrapperfunctions for all SalReportSet*Val functions (eg PALReportSet*Val), you can defer the
variable name and the value to a log. Then the actual Sal function is called. The complete list can be obtained by the report builder object. When comparing the list of send values and the complete list, you can determine which variables are send and which are not (unused variables).
), with a minor exception -- I really don't need to check the QRP side, also I'm not too familiar with clean-up tasks so I'd probably end up leaving a bunch of useless stuff in memory, not to mention if the application crashes I don't get any data. Indeed strangely enough this all seems to support my earlier statement about the SalReportSet<>Var()s not being listable at runtime. Oh well.