>>>I need to create a report and based on MetaData the field needs to be changed. Is it possible to place one control on the report and set it dynamically or the only way this can be accomplished is by placing a text field for each possible field I would need and manipulating them via *Print When* expressions? I have tried macro expansion but I can not make it work.
>>
>>
You can set it dynamically w/o "print when". A report "field" could simply call a UDF().
>>Cetin
>
>Cetin,
>
>Thanks for responding and thanks for all prior advice/help/code (which I have used), that you have contributed to UT.
>
>Let me elaborate a little on my current problem and hopefully you can advise on the preferred method of handling it. I have written an application for the company I work for and which they use. Now they sold the app for an other company, but (of course) that company needs modifications to the app by omitting certain fields, adding other fields and using different captions for shared fields etc. My company does not want to maintain two (or more) EXEs or more than one table structure and there comes in the complications. I was hoping there is a way of doing it with variables populated via MetaData that will handle all the changes to the Reports based on the company using it. I have no problems with Forms because the controls are objects.
>
>What if the above problem has 15 or more columns that I need to manipulate, will the running of the UDF for each column, for each record, slow down the process considerably? Are there other ways?
Ernest,
Fox runs simple UDF() really fast so it would still be faster than printing. A simple UDF just returning field value would be fast enough (even for just viewing). OTOH you could have all your report fields as "constants" say f1,f2,f3.... This would "move" udf() portion to an SQL. A select SQL would select the fields for reporting as "f1", "f2".."fn". For headers, titles and alike you could just use memory variables. If report field sizes are constant then both methods work fast (done in fox2x too and always waited for the printer to catch up - even preview is instant for UDF()s are really simple and do no extra calc:). UDF() has advantage that they could be managed independently while developing. Instead of a UDF() it could even be an array holding reference to field name :
Report field = eval(aMyArray[x,y])
aMyArray[x,y] = "myFieldName"
I did the same for field headers too. Instead of "labels" field headers were also UDF() or array elements. It's especially usefull when you report a crosstab with the same frx and don't know fieldnames, fieldcount beforehand.
Another thing that could be done is to provide frx as files and give an option to modify. They could size, move, delete, add fields as they like then.
I say UDF() would work fast because in fox2x dos days I didn't like default report previewing and I reported to a text file, lowlevel processed it to eliminate extra printing chars, position line chars etc and then showed in a "modify command" window :) Of course depends on the size of data and now few would want a DOS style report. Still I think with a very rough calculation a simple UDF() would only overhead a 10000 recs report under 5 secs (call it a guess instead of calculation:)
Beforehand you could estimetate it by writing a simple prototype of the most complex UDF() that would return what you want from metadata and time it looping 10000 times. This UDF() approach assumes that not only fieldname changes but type of data returned per record as well. If only fieldname is changing the constant report field names + SQL approach is the one I prefer. In that case you could code a routine that would write the SQL for you from metadata :)
Cetin
