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

I've found it very useful to use the debugger to step through the code when things start getting slow in OPO. You might be surprised at what methods get called when. PostUpdate() and FocusLeaving() are two that have caused problems for me. The TopContainer's PostUpdate, for example, gets called very frequently.

As far as crashes, I get them quite a bit on my Mac. Some are attributable to dumb programming on my part, some to wierd bugs in OPO, and some are of unknown origin. Also, I've found that some things may run OK in the development environment, but crash in the Runtime environment. Turning the debugger on in the development environment usually causes the crashes to occur there as well. (As an example, be careful dealing with the default toolbar -- they're not the same in the different environments!) I've also seen examples copied right out of the the Power Objects Handbook that crash!

On the good side, the environment is very flexible, and if something doesn't work the way you think it should, there is usually another way to do it. It can be time consuming to figure it out though.

I haven't gone 'live' yet, so haven't dealt with performance issues of large queries. My real concern is whether it's worth sticking it out with OPO and assume that things will get better with Version 2 this summer, or moving on to something else.

--Mark Morgan
--Connectix Corp.
--morgan_at_connectix.com

Peter Yamamoto (pjyamamo_at_daisy.uwaterloo.ca) wrote:
: > 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/
Received on Sat Mar 23 1996 - 00:00:00 CET