johnf wrote: > On Monday 25 May 2009 05:33:27 pm Roger Lovelock wrote: > >> Hi All, >> A thought I had! The most common enhancement to my dabo application is >> new report formats (changes or additions). Because of the nature of the >> report writer and the way reports are run it means adding code to the main >> app and redistributing an updated version to all users. My thought was that >> if a generalised report runner was included in my app I would only need to >> distribute text and/or xml files to add new reports. To explain - if I had >> an xml or text file per report which included the descriptive name of the >> report, connection name, sql statement and report definition file name then >> a generalised routine (optionally stand-alone or alternatively embedded in >> the application) could do the following :- read all report text files >> display a drop down list of available reports (descriptive >> name) upon selection of a list item >> get the connection >> create a dataset from the sql statement >> run the specified report and display the pdf >> To add a new report would just need the relevant report text file, cdxml >> file and rfxml files loaded in the app directory. >> >> Of course two other thoughts come to mind >> - all the data in the report text file could be included in >> the rfxml file. - A stand-alone user friendly ad-hoc report generator could >> be developed from this base utilising the report designer as a starting >> point. >> >> Has anyone else had thoughts or done anything along these lines? Any >> suggestions? >> >> Roger >> > > Larry and I are doing something very similar. Although, your description > does > not cover all the issues. For example you need more than just a dropdown to > select a report. You need a way to interact with the user. Most reports > will need input from the user - such as date ranges or client names. IOW the > params for the sql. BTW that is not as easy as it may sound. Dynamically, > displaying textboxes, date boxes, spinners, dropdowns can be a pain and > remember that you can have ranges and may need to provide validation along > with lookups for each control. > I've done something similar under VFP. I have a form with a label, a textbox and a list box beneath them with the names and contents of all the pertinent filter variables. As the user scrolls through the list box the label takes the value of the highlighted variable and the textbox the corresponding content, if the user wants to change the value of a filter variable he does so in the textbox, where the data is validated properly (mask is in effect to filter input), pre-processing is done and results converted to proper type are fed to appropriately named property. Once the ok button is pressed the query is executed with values taken from these properties. This schema allows me validation against other defined variables (just validate the corresponding properties). The filter variable names, pre-processing, validation, error message (when validation is not true), type, mask, visibility (so I can use variables not accessible to the user), etc. are stored in a table.
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
