On Wednesday 27 May 2009 06:22:15 am Ricardo Aráoz wrote: > 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.
Sounds good! So can I assume that when a range is required that there are "var from" and "var to" in the list? In our case the idea was to have dynamic controls appear as required. On the left we have a dropdown with "single", "range", or 'all' for each of the required params. If the user selects "single" only one (textbox, datebox, or masktextbox) control appears, if 'range' is selected then two controls appear. There is nothing to do if 'all' is used. The SQL then uses the user input to retrieve data. The problem of validation is of concern. Unlike VFP Dabo (in general) expects bizobj's to handle validation. In this case there is no bizobj. So we haven't got it down pat for the moment. But we are providing the user lookup tools to pick the params. For example if the user wanted to pick a customer they would click on the lookup button and a pick-grid would appear listing the customers. This goes a long ways in preventing bad input. Our biggest issue is the report interface is very dependent on tables, and our home grown classes. The tables (meta data) I don't mind. They don't have to be on a postgres server. We could have used SQLite. But using our home grown classes are of concern. Not that they don't work - they do. Just that when we wrote them we were less than knowledgeable when it came to Dabo and python in general. But we are getting better daily. -- John Fabiani _______________________________________________ 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]
