QRP templates
QRP templates
Hello
I'm wondering if it's possible to somehow just get 'debug information' on what's being sent to a report template. Just a list of input variables/items that are being sent and the corresponding data, unformatted.
This would be extremely useful when dealing with reports/templates.
Regards,
MH
I'm wondering if it's possible to somehow just get 'debug information' on what's being sent to a report template. Just a list of input variables/items that are being sent and the corresponding data, unformatted.
This would be extremely useful when dealing with reports/templates.
Regards,
MH
Re: QRP templates
If you are looking for a SPY++ - like utility, I don't know of one, MH.
Naturally, all the data being sent are available in your application's SAM_Report msgs--FetchNext, Nofity, etc. And the data that are sent appear in the report. And if you want a 'before sent' list, you could code in writing to a debug file of those data.
Feels like I'm missing something...
Do you perhaps not have the TD source and only have an EXE and QRP files??
Naturally, all the data being sent are available in your application's SAM_Report msgs--FetchNext, Nofity, etc. And the data that are sent appear in the report. And if you want a 'before sent' list, you could code in writing to a debug file of those data.
Feels like I'm missing something...

Re: QRP templates
I do, but the problem comes from the fact that some printing procedures are HUGE, thousands of criss-crossed classes and functions with the occasional state machine thrown in for good measure and every now and then feeding two or three QRPs at once. I guess the best way is to just search&replace through the source files and make a dummy function that also stores what's being sent and saves that into a list.Jeff Luther wrote:Feels like I'm missing something...Do you perhaps not have the TD source and only have an EXE and QRP files??
Hmm, actually that doesn't sound too bad. Score one for unit testing.
Re: QRP templates
Sure, though if it's specific QRPs you are interested in, your search is really narrowed, since there will only be one hWnd object for any one QRP that is receiving the SAM_Report msgs. for that report.I guess the best way is to just search&replace through the source files
Re: QRP templates
Sure, but that is, again, for specific targetsJeff Luther wrote:Sure, though if it's specific QRPs you are interested in, your search is really narrowed, since there will only be one hWnd object for any one QRP that is receiving the SAM_Report msgs. for that report.I guess the best way is to just search&replace through the source files

Ahh... I think I see where I might have been confusing. I meant I need what data is going into the QRP at runtime. If I could just read the object (which can't be done, apparently), it'd be a hitch but a simple override should do the trick. Just need to figure out optimal storage... maybe just dump everything in a .txt file or a .xls file, not like I want to store all of that until execution stops.
Re: QRP templates
Yes, that's what I assumed. That's why I suggested that the SAM_Report msgs. were the places to put some debug code to catch what's been fetched and/or assigned and is about to get transmitted to the report.I meant I need what data is going into the QRP at runtime
"not like I want to store all ' -- likely not, but as you say you could have a switch/boolean to turn this off/on.
Re: QRP templates
Ahh... but it's quite hard to get generic information out of the window handle as you have to know exact variable names to get their stored data out, which is often not reasonable (with, say, 300+ variables). That was one thing I wanted to know -- is it somehow possible to extract a list of variable names stored in the report/window handle? I couldn't find anything in the .HLP file at least.Jeff Luther wrote:Yes, that's what I assumed. That's why I suggested that the SAM_Report msgs. were the places to put some debug code to catch what's been fetched and/or assigned and is about to get transmitted to the report.I meant I need what data is going into the QRP at runtime
Well, yes.. a .INI setting or similar. But since I'll have to get them out anyway I might as well save myself the trouble of storing them internally and just write the output to a XLS/TXT file when they're stored to the window handle. That'll also give me helpful trace information if the print crashes and besides, if I just store them internally I'll have to either debug the information out -- which means this will only work/be useful in development environments -- and/or also override the actual printing functions since I'll probably have no good generic spot where to spit them all out.Jeff Luther wrote:"not like I want to store all ' -- likely not, but as you say you could have a switch/boolean to turn this off/on.
BTW thanks for all the input. Good criticism really helps with thinking things through

Re: QRP templates
In general, yes. Check out the TD sample ReportFileBrowser.app in the \samples\sqlwindows\report builder folder. It shows how to get vars, input items etc. details for a QRP file, but it's essentially a design-time view so can't show what those items contain.is it somehow possible to extract a list of variable names stored in the report/window handle
-
- Founder/Site Admin
- Posts: 3512
- Joined: 24 Feb 2017, 09:12
- Location: Gouda, The Netherlands
Re: QRP templates
When calling SalReportView you supply it with a strVariables parameter where you define the variable names separated with comma's to fetch the data from.
You can parse this strVariables parameter and extract the variablenames. Using SalCompileAndEvaluate you can get the values from the variables before they are send to the report.
This implementation would be usable for any report, implement once and use it for all reports.
You can parse this strVariables parameter and extract the variablenames. Using SalCompileAndEvaluate you can get the values from the variables before they are send to the report.
This implementation would be usable for any report, implement once and use it for all reports.
Regards,
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Re: QRP templates
It looks like it was made to get details from a QRP file, yes. I want the other side of the equation.Jeff Luther wrote:In general, yes. Check out the TD sample ReportFileBrowser.app in the \samples\sqlwindows\report builder folder. It shows how to get vars, input items etc. details for a QRP file, but it's essentially a design-time view so can't show what those items contain.is it somehow possible to extract a list of variable names stored in the report/window handle
Example:
Code: Select all
Call SalReportSetStringVar ( hWndReport, 'strBonusType', strBonusType )
Call SalReportSetNumberVar ( hWndReport, 'nBonusPoints', nBonusPoints )
Code: Select all
Call <unknown function> ( hWndReport, strSVarList )
Call SalArrayGetUpperBound ( strVarList, 1, nMax )
Set nInd = 0
While nMax > 0 and nInd < nMax
Call SalLogLine ( "c:\\temp.txt", strSVarList [nInd] || ' ' || SalReportGetStringVal ( hWndReport, strSVarList ) )
Set nInd = nInd + 1
Re: QRP templates
Hmm, I didn't notice that, thanks.Dave Rabelink wrote:When calling SalReportView you supply it with a strVariables parameter where you define the variable names separated with comma's to fetch the data from.
You can parse this strVariables parameter and extract the variablenames. Using SalCompileAndEvaluate you can get the values from the variables before they are send to the report.
This implementation would be usable for any report, implement once and use it for all reports.
Still, if I want to check for unused/duplicate variables I'll still want to loop through all the _set_ variables, not just those which are sent. Also, this will ignore any that are set in SAM_Report<>, so it doesn't helpstrVariables String. A comma-separated list of SQLWindows variables from which to fetch data. The data types of these variables must match the data types of the input names in strInputs.
The contents of this string must match the order of the input names declared in the report template.

-
- Founder/Site Admin
- Posts: 3512
- Joined: 24 Feb 2017, 09:12
- Location: Gouda, The Netherlands
Re: QRP templates
So if I understand correctly, you want to have a list of internally stored QRP variables and get their values at runtime ?
Seems the combination of Jeffs suggestion and your sample code (using SalReportGetStringVal) could do it.
A report is started using a report filename which is then connected to a hWnd. You will have to keep a list of report names and their hWnd connections.
When a SAM_Report msg is received, resolve the report filename from the list.
Then using AX (like in the ReportFileBrowser.app) to get the list of all defined internal variables.
Using SalReportGetStringVal you can iterate through their values and store them.
But then again, I could be wrong in actually understanding what you need.
Seems the combination of Jeffs suggestion and your sample code (using SalReportGetStringVal) could do it.
A report is started using a report filename which is then connected to a hWnd. You will have to keep a list of report names and their hWnd connections.
When a SAM_Report msg is received, resolve the report filename from the list.
Then using AX (like in the ReportFileBrowser.app) to get the list of all defined internal variables.
Using SalReportGetStringVal you can iterate through their values and store them.
But then again, I could be wrong in actually understanding what you need.
Regards,
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Re: QRP templates
I think what is meant is that if he has a formula in a qrp - say something like (Formula148)
NumberIFF( nQty , nQty , Num_Null , nQty * NumberIFF( nRate , nRate , Num_Null , nRate + nBkg ))
he would like to know the value of Formula148 at a break point.
NumberIFF( nQty , nQty , Num_Null , nQty * NumberIFF( nRate , nRate , Num_Null , nRate + nBkg ))
he would like to know the value of Formula148 at a break point.
Re: QRP templates
Again, no.F R Bhote wrote:I think what is meant is that if he has a formula in a qrp - say something like (Formula148) *snip*
I'll see if I can make this clearer:
Ignore everything I said about QRP. The QRP is only relevant in that it receives data.
When generating a report, there are two ways of getting data to the report: SalReportSetStringVar (and Number and Object) and through parameters in SalReportPrint (or SalReportView).
I want a list consisting of all variables set with salReportSet<Type>Var() so I can just loop them through. Not those the actual report will print out or care about. Currently this seems to be impossible.
Yes, that's exactly it, BUT...Dave Rabelink wrote:So if I understand correctly, you want to have a list of internally stored QRP variables and get their values at runtime ?
...this won't work. It will give me a list of the values the QRP expects to get, not those that are being sent to it.Dave Rabelink wrote:When a SAM_Report msg is received, resolve the report filename from the list.
Then using AX (like in the ReportFileBrowser.app) to get the list of all defined internal variables.
Using SalReportGetStringVal you can iterate through their values and store them.
-
- Founder/Site Admin
- Posts: 3512
- Joined: 24 Feb 2017, 09:12
- Location: Gouda, The Netherlands
Re: QRP templates
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).
The application calls x times SalReportSet*Val functions to set the QRP variables. So when calling this function, your application
has access to the variable name and it's value. 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).
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).
The application calls x times SalReportSet*Val functions to set the QRP variables. So when calling this function, your application
has access to the variable name and it's value. 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).
Regards,
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Dave Rabelink

Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel
Who is online
Users browsing this forum: [Ccbot] and 5 guests