OPO: simple setup?...

From: Peter Yamamoto <pjyamamo_at_daisy.uwaterloo.ca>
Date: 1996/02/13
Message-ID: <DMqBqG.3EK_at_watdragon.uwaterloo.ca>#1/1


hello,

maybe I need to buy a book (or a clue!-) but I've been trying to figure what OPO is doing for a while now and thought I'd put it to the net.

What I want is:

Visually: A list box with a list of names ("surname, given names" format) on a "person form" which the user can edit a person's personal data.
The user should be able to scroll the list, and click on a name in order to get that person's data into the form. The "current record" displayed on the form should stay highlighted in the list box.

[other bells and whistles include tabs for restricting the list of name according to surname, and also a "status" [defined in another table; but that part is fine].

Visually, I have done this. But there are subtle problems. In particular keeping the current record in the listbox highlighted; something keeps making the list value NUL. And I can't figure out what/why (well maybe I have an idea, see below but I don't understand why).

The first way (a la Demo Applications Address Book) requires querying twice (once for the list's translation and once for the form's querywhere). When the list is rather long, then the commit/rollback time is ridiculous. But this seemed to work well, albeit slow.

Since I don't really need any navigation controls on the form, I removed the identical query on the form and simply did the alpha/status query on the list. This (not surprisingly) cut the commit/rollback time in about half. But somewhere along the way, the subtle behaviour (maintaining the current record highlighted) was lost.

Preferably, and it seems, sensibly, I want to use a shared recordset for both the form and the list, or perhaps bind the list to the form. I have been totally unsuccessful in this regard.

First of all, although list boxes are mentioned in almost all the shared recordset documentation, I don't understand how you set this up since a shared recordset seems defined by specifying a RecordSource; but the list object doesn't have a RecordSource property.

To summarize, I have two questions...

has anybody "synchronized" a list and a form (where the list is on the form and is based on the same table [although its display is based on querying with another table]) by using a shared recordset?

or

has anyone any idea what triggers a lists PostChange (and forces it to set its value to null)? I have a call to a debugging routine in my usercode and as far as I can tell, when I click on a list item, it executes the PostChange, which updates the form via a querywhere, which apparently triggers a PostChange on the list setting its value to NUL (but the list is unbound, so why trigger a change and why NUL?). A workaround, obviously, is to save the list value in a static var, and if I come into PostChange with a NUL value then set value to the saved value (but obviously don't start the cycle again by requerying the form). But I'd rather understand what's going on!

Phew, hope that's understandable!-) Thanks for any insights or pointers.

Peter

--

Peter Yamamoto                     CS   Phone: +1 519-888-4567 x3299
University of Waterloo             MFCF Phone: +1 519-888-4567 x6488
Waterloo, Ontario, Canada N2L 3G1  Home Phone: +1 519-747-5318
Email: PJYamamoto_at_UWaterloo.CA     URL: http://daisy.uwaterloo.ca/~pjyamamo/

--
Peter Yamamoto CS Phone: +1 519-888-4567 x3299 University of Waterloo MFCF Phone: +1 519-888-4567 x6488 Waterloo, Ontario, Canada N2L 3G1 Home Phone: +1 519-747-5318 Email: PJYamamoto_at_UWaterloo.CA URL: http://daisy.uwaterloo.ca/~pjyamamo/
Received on Tue Feb 13 1996 - 00:00:00 CET

Original text of this message