Bob,
An approach we use is to:
1. populate a table field on a card on a hidden stack with the data
from the DB (data object)
2. render a list (or more often, a scrolling group-of-groups with each
group representing a single row) for the user to see and interact with
(display object)
This way, we don't have to worry about hiding columns, since they're
all in the data object, and any updates the user makes to the display
object are automatically mirrored to the data object.
This may sound kludgy at first glance but it gives the developer such
a wonderful degree of flexibility when designing the display object,
yet handles all data needed in the hidden data object.
For example, just like Filemaker, one record (one group in the group-
of-groups) could contain option menus, text fields, buttons, label
fields, popup calendars, whatever, for the user to interact with.
On Mar 4, 2009, at 9:32 AM, Bob Sneidar wrote:
Hi Len.
It would be easier to hard code a query if I was coding for a
specific application that only did one thing, but I am making
generic functions to query the database based upon fields that I
have dropped into a form using a Field Dropper utility I made. The
idea is to be able to query a database table for it's structure,
allow the user to pick a field and what kind of field he wants it to
be, select some options (like List Visible for example) and then
"drop" that field into the form with a set of custom properties that
will determine how the field behaves on the form and in lists. The
fields have the same name as the table columns with an "f" prepended
to them, so if I know the field name I know the column name.
The functions to do all this are generic so that they can work with
any form built from columns in any database. I am building more than
a specific application to do a specific thing, I am building a
framework of functions and utilities that will work much like
Filemaker when I am done, so I avoid any application specific
coding. My functions don't know (and don't care) what the actual
columns are. Their visibility in any list is determined by whether
or not the column has a corresponding field in the form, and if it
does, whether or not the ListVisible property is true. I set this
property in the Field Dropper utility.
Some fields are ALWAYS invisible (such as the deleted flag, the
unique id, and the signature lock). But they have to be part of the
data returned from the query so I can check those values against any
new values before I write anything back to the tables. It's just
sooooo much simpler to script a query on the fly using "SELECT *
FROM" and then rearrange the columns for the list view as needed.
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
On Mar 3, 2009, at 1:51 PM, [email protected] wrote:
Wouldn't be MUCH easier to just ask for the data you want in the
order you
want in your query and not have to worry about diddling with
arrays? For
example:
SELECT f1, f2, f3, ... fx FROM myTable -- Gives you the same as
SELECT *
SELECT fx, fy, f3, f1, f2 FROM myTable -- Gives you back the fields
in the
specified order
Just my two cents' worth
len morgan
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
