My app seriously stops compiling with that convention and the Report to PDF with the NetTalk extension (I don't know why).
So here is the candy, if you want to use a report with parameters, here is how, if you use the PDF Reporting Tool (the setting to be set as per attachment), that is...
(Before First, obviously define the l: variables in the Data Section of the proc)
First define prototype, something like (long,long,string)
Then parameters, something like (autoprint,autoclientno,autoprintname)
In embed point ABC Objects, Window Manager, Init, just after Restore from ini file, something like:
if autoPrint
progresswindow{prop:hide} = true !Obviously check your window name
l:autoPrint = 1
l:NotAutoPrint = 0
l:pdftoolsname = clip(path())&'\PDF\'&format(autoPrintName,@s8)&'.pdf'
else
l:autoPrint = 0
l:NotAutoPrint = 1
.
if autoclientno <> 0
cli:clientno = autoclientno
.
(yes it looks silly, but you cannot use 'not l:autoprint' as a condition as per attachment.)
So you can use your normal Windows app that normally pause so the user can select stuff and override it by the above method. Something funny in this text field as I cannot see what I am typing...
Maybe Bruce knows a better method, and he can ellaborate, but this works fine for us. I have one procedure called ServeDocument (which I call with a parameter if you can call it that, eg ServeDocument?Report=4) and from there I call all the normal Windows stuff llike this, not messy at all.,
If p_web.Getvalue('Report')=4
PrintTheDamnThing(x,y,z)
.
(x,y,z being parameters passed as part of the ?method or as session values). Sorry, I cannot say more now as I really cannot see what I am typing. I think there is some fault when the message gets too long which was never a problem before.
Cheers
Charl
[attachment deleted by admin]