thomas_m@wums2.wustl.edu (07/27/90)
This may have been asked before and I just was not around to read the answer, but does anyone know a way to get around the following problem or what makes hypercard do this? When I type: find "XXX" it will find a field (if there is one) which contains the characters "XXX" in a very short time (this is in a stack of about 10,000 cards). When I try to find something like "XX.XX.XX" it takes about 5 minutes or more to search through all the cards and find something. I have tried searching for <3 character strings and the same thing happens. So, as I figure, Hypercard is taking the .'s and disregarding them as characters to search for and replacing them as delimiters between multiple text string (or something to that effect). My question basically is (are), 1) Why is hypercard doing this, and 2) what can be done to get around this problem so that hypercard searchs as fast as it does with >2 character strings? The reason that we use "."s in the fields is because we are naming cell lines and that is the standard way of terming them. Any help would be greatly appreciated. - Matt Smith (Wash U. Med. School, St. Louis, MO)
stadler@Apple.COM (Andy Stadler) (07/27/90)
In article <3747.26af01bd@wums2.wustl.edu> thomas_m@wums2.wustl.edu writes: > > [..VERY astute observation that searching for 1 or 2 char strings is > substantially slower than searching for 3 or more char strings..] > > My question basically is (are), 1) Why is hypercard doing this, and 2) >what can be done to get around this problem so that hypercard searchs as fast >as it does with >2 character strings? Basically, this behavior was "designed in" to HyperCard from the very earliest days of its design. There is a special encoding of the text on all cards, called the "hint bits". The "hint bits" are all stored in one place, so in a search, HyperCard can just load and search a single object instead of skipping and reading all over the disk, checking every single ascii character. As with any "hashed" search data, you must make a tradeoff and discard some percentage of the discrete data. During the early design phase, Bill & co. observed that people rarely if ever searched for single or double characters. So the hint bits encode letters in groups of threes (called trigrams). Any word with less than three letters is simply discarded from the hints. Enough of the internal technical details. The fact is, HyperCard contains many tradeoffs and unfortunately you've hit one. Really, the only solution is to make sure you search targets are 3 or more characters. > The reason that we use "."s in the fields is because we are naming cell >lines and that is the standard way of terming them. Any help would be greatly >appreciated. Perhaps you could re-encode the data in threes? Like XXX.XXX.XXX ? --Andy stadler@apple.com
howie@intermec.com (Howard Kaplan x6596) (04/02/91)
Anyone out there experiencing problems with "find" of Hypercard 2.0? I have a couple of Shareware stacks that have "find" buttons. My problem is hitting the button with the browse tool brings up the arrow cursor and then I have to click again to bring up the dialog that asks for the find string. I would suspect the stack, but the same behavior is exhibited in both stacks. I think it possibly related to the "ask" or "answer" command since these are what is use to actually bring up the dialog box. I have also noticed similar behavior when trying to look at the script of a stack. Seems like I have to click the mouse an extra time to actually get the stack window to show after hitting the "script" button from the stack info window. Howard Kaplan
Peter.Carlson@f444.n161.z1.FIDONET.ORG (Peter Carlson) (04/27/91)
Hi, well I believe that in everything I've done with HC2.0, I've never had a
problem with the find feature. It sounds like the two stacks did the same
kind of thing, perhaps made a handler to deal with people aways double
clicking in HC2.0, something I still do at times. maybe if you can open up
the stack and look at the scripting you could see the problem.
Peter (good luck) carlson
--
Peter Carlson - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!161!444!Peter.Carlson
INTERNET: Peter.Carlson@f444.n161.z1.FIDONET.ORG