Click on the body. This is primarily for Listviews in tabless tab panels intended to allow the user to select a single record from a displayed (separate) foundset.
This goes back to the discussion you and I had about a week ago. You suggested you get around this by using OnRecordSelect to show the user additional information about the selected record in a box near the listview, and having a single button in that box that actually selects and loads the record into the detail view.
You indicated you do this for two reasons: (1) its nice to give the user the addtional info about the record they're about to select, and (2) you, also, need a way to get around the automatic triggering of OnRecordSelect in circumstances
other than the user actually clicking to select the record.
While I like and appreciate your solution in some cases, I'm finding many more where I don't
want the extra step of displaying additional info and giving the user a button. I want them to be able to select a record just by cliicking on the record in the tabless tabpanel listview, and to have their manual selection trigger an action. I find this action is virtually always a different action than the one I want triggered when a contextual change, rather than a user click, triggers the OnRecordSelected.
Since you can't use the old Filemaker trick of putting an invisible 'button' over the entire record body (since this results in to put it mildly, aesthetically unappealing behavior) and you can't use OnRecordSelected (easily) to trap a user click because it triggers on lots of events other than the user selecting a record by clicking on the record body, we don't really have an elegant solution to this (IMHO) ubiquitous issue.
What I'd
really like is a boolean property that could be tested within the OnRecordSelected event, something like OnRecordSelectedManually.
- Code: Select all
// This is the OnRecordSelected Method
if (OnRecordSelectedManually)
{
...do stuff...
}
else
{
...do stuff that should only happen on non-manual select...
}
...do stuff that should happen regardless...
// End of Method
This would keep the simplicity of only having one event, but would allow differentiation between the two very different ways that event can be triggered.