mrx@dhw68k.cts.com (Mark Murphy) (12/16/90)
Another slow thing I have found in HC 2.0 is text selection in Fields. Currently I have a front end to an Oracle database that has 28 bg flds and 11 bg btns. To tab from field to field or select text from script takes 60 ticks! At first I thought I might have some sort of overhead with my openField messages but this does not seem to be the case. I created a new stack and duplicated the amount of flds and btns I have in my original stack. Tabbing was very slow (about 60 ticks). Now, 28 flds in not a lot of flds for a card to have... it is not uncommon. Is there something I am doing wrong here? Or am I doomed to have this very slow text selection and tabbing? I hope there is something I can do about this.... I convinced management that HC 2.0 would be just the right tool as a front end to our Oracle system... that it would have more than enough power to do the simple data entry we do. The more flds and btns I add... the slower it gets.... -- mark mrx@dhw68k.cts.com
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (12/16/90)
In article <1990Dec15.174332.416@dhw68k.cts.com> mrx@dhw68k.cts.com (Mark Murphy) writes: > Another slow thing I have found in HC 2.0 is text selection in Fields. >Currently I have a front end to an Oracle database that has 28 bg flds and >11 bg btns. To tab from field to field or select text from script takes >60 ticks! At first I thought I might have some sort of overhead with my >openField messages but this does not seem to be the case. I created a new >stack and duplicated the amount of flds and btns I have in my original stack. >Tabbing was very slow (about 60 ticks). Now, 28 flds in not a lot of flds >for a card to have... it is not uncommon. Actually, 28 fields is quite a few. For HyperCard 1.x, I used the rule-of- thumb of an upper limit of ten to fifteen fields. I haven't done any testing on this with 2.0, but it wouldn't surprise me if the magic number were still in that range (or even lower, what with the slowdown caused by the use of styled TextEdit). The number of buttons, on the other hand, doesn't seem to be critical. A card with 28 fields *will* display slow response when moving from field to field. I'd recommend you take a serious look at your stack design; it's usually fairly simple to reduce the number of fields by combining several fields into one and using chunk expressions to address the combined components. -- ========= jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.sf.ca.us | compilation copyright without my permission. ______________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. |
a347@mindlink.UUCP (John Miller) (12/18/90)
In article <47417@apple.Apple.COM> jdevoto@apple.com (Jeanne A. E. DeVoto) writes > A card with 28 fields *will* display slow response when moving > from field to field. I'd recommend you take a serious look at > your stack design; it's usually fairly simple to reduce the number > of fields by combining several fields into one and using chunk > expressions to address the combined components. Tabbing certainly will be slow. Considering that lots of people are using HyperCard to build database front ends, this would be a good area to check when tuning the performance of the next HyperCard upgrade. HyperCard 2.0 does a *lot* of unnecessary processing each time the user presses the Tab key. ---------------------------------------------------------------------- John Miller (604) 433-1795 Symplex Systems AppleLink (rarely) CDA0461 Burnaby, British Columbia Fax: (604) 430-8516 Canada usenet: john_miller@mindlink.uucp ----------------------------------------------------------------------