Re: Power Objects: Ye gods it's slow!

> Some additional input by myself. One of our forms is a bit like the
> contacts sample application. Along the top of our form the user may enter
> search criteria which will be used to query the database. In the middle of
> the screen is a listbox in which appears all matches to the query - but
> just some of the fields. Along the bottom of the screen are the remaining
> fields for the record. Clicking on a record in the listbox makes the
> remaining fields at the bottom of the screen become populated with that
> record's data.
>
> Some problems - the code that updates the field on the bottom of the screen
> based on which record is highlighted in the listbox was borrowed from one
> of the sample apps. It's actually quite horribly slow - most of it is in
> the PostUpdate() method of the listbox. Even with only 40 matches, the
> further down on the list you go, the longer it takes the program to update
> the field fields along the bottom of the screen. I improved that by
> rewriting some of that code. Changing MaxMemSize() on the form property
> box didn'thelp even though this is supposed to cache records in memory.
> The most disturbing problem, however, is that if the query returns more
> than about 600 records, power objects causes a general protection fault and
> dies. It doesn't matter if I'm running the application from within the
> designer, compiled with the runtime , or compiled into a separate EXE
> file. I've had to program in checks so that if the user's query returns
> >600 recs, a dialog box informs the user to narrow his search, and try
> again. With 16 megs of RAM THIS SHOULD NOT be happening. My records are
> less than 1K total in length. 600 records is only 600K of memory.
>
> Does anyone have any ideas on this?
>
> Jeff McWilliams cd827_at_cleveland.freenet.edu

On the mac version, I have also noticed (and commented on) the difference in speed when processing a postupdate of a "long" list. The further down the list you go, the more time it takes to process the action (from 2 seconds in the "A"s, to 15 seconds in the "M"s to 30+ seconds in the "Z"s on a list with about 1700 records). But as far as I can recall, others have said they don't experience this delay, so I am wondering if it is some kind of higher level settings affecting the operation.

An obvious guess is that OPO is doing "something" for each record before the selected record. As I mentioned before, considering the demo code, I wondered if it is stepping through each record turning off the selected attribute in order to make sure the item you just clicked is the only highlighted item (what else is it/could it be doing?!?)!

In terms of "crashes", the mac versions doesn't crash, but for >2300 records, the data becomes garbled (but somebody else said this doesn't happen to them).

The only thing I found which seemed to help a bit in the beginning was to make the list "unbound" from the form. But then I had to add the code in the update section to specifically set the QueryWhere for the form.

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/