PCT501@saturn.ukc.ac.uk (05/07/91)
Sorry if this has been covered before... I have only just discovered this newsgroup and my news-site doesn't keep much in the way of back-issues on our overcrowded discs! I have a problem. I need an array of tickboxes; the application is a database of my local Scout Troop. I (want to) have a card for each boy, on which there will be a tickbox (`Auto-hilite Checkbox') for each of around a hundred badgework items completed. What I really *want* is a background checkbox whose high-light is stored on a per card basis, much like the contents of a text-field. Also it would be really good to have an array of boxes instead of defining each individually; clearly this is not available (or is my version out of date? - is there a patch), but a good compromise would at least be to have scripts associated with the background, not with thousands of duplicate card buttons, which I am currently using as an interim solution and which has completely filled the hard disc... Any suggestions? Has anyone already solved this? Thanks, Greg Harewood PCT501%saturn@uk.ac.ukc , gjh@uk.ac.ukc
stadler@Apple.COM (Andy Stadler) (05/08/91)
In article <9105070137.AA07503@cs.utexas.edu> PCT501@saturn.ukc.ac.uk writes: >What I really *want* is a background checkbox whose high-light is stored >on a per card basis, much like the contents of a text-field. Beginning with HyperCard 2.0, there is a new background button property called "shared hilite". The default is "on", which emulates the behavior of bkgnd buttons in HyperCard 1.2.5. But if you create a bkgnd button, and turn shared hilite "off", you will get a unique hilite state for each card. This is -exactly- what you are looking for. Implementation note: If you consider text (the "data" of a field) and hilites (the "data" of a button) as conceptually identical, you can see that the system of shared/unshared hilites is quite similar to the concept of shared/ unshared text, which was also added in 2.0. In fact, many, many people were asking for "shared bkgnd text" but when we implemented it, we discovered that it was just a easy to implement it more generally and thus give new capa- bilities to buttons as well. The only real difference is the defaults, which are set "true" for buttons and "false" for fields - to emulate 1.2.5. [Just for the record, we invented it for HyperCard IIGS and kindly shared our source code with the Mac 2.0 team.... :) ] Andy Stadler Apple Computer, Inc.
jkc@Apple.COM (John Kevin Calhoun) (05/10/91)
In article <52552@apple.Apple.COM> stadler@Apple.COM (Andy Stadler) writes: >Beginning with HyperCard 2.0, there is a new background button property called >"shared hilite". > >[Just for the record, we invented it for HyperCard IIGS and kindly shared our >source code with the Mac 2.0 team.... :) ] Well, the way I heard the story is that Martin Gannholm convinced Bill Atkinson that sharedHilite was possible, and Dan Allen went off and implemented it according to Martin's design. It all happened while I was still blissfully distant from the scene, so I don't really know. But it's true in any case that Macintosh HyperCard 2.0 borrows several ideas and some code from HyperCard IIGS. In particular, the following things were invented or inspired by Andy and the HyperCard IIGS team. - the navigator palette - the dontSearch property - the fixes to message ordering - the extensions to the read and write commands (now in Mac HC 2.1) And a number of things were designed by the two teams in cooperation. - the extensions to the ask and answer commands - the create stack command - the import and export paint commands - the save stack command So far, HyperCard IIGS doesn't borrow much from Mac HyperCard 2.x -- as far as I know, just the incredible expanding dialogs. It looks like HyperCard IIGS has some catching up to do, in order to become as dependent on us as we were on them.... Kevin Calhoun jkc@apple.com
eallen@mercury.sybase.com (Ed Allen) (05/10/91)
One way to get such an array economically is to design a custom font that has one character for the checked box and one for the unchecked box. The array is a field that you fill with one of the two characters and the field has a mouseup script that catches which character you clicked on and sets it to the opposite character. Your database function scripts assess the same character in the background field on each card for each badge. Since as far as HyperCard is concerned, you are only storing characters in one or a few bg fields and not hundreds of card buttons per card, it is much smaller in disk space and will perform much quicker. You have to have the assignment of character array elements designed into your scripts so that you know that char 7 of line 6 of fld "badges" means "FISHING" or whatever. You'll need to use resedit or Fontastic + or something similar to make the dedicated font. A couple of caveats: large pictographic fonts will sometimes default to geneva in low memory conditions at about the same time as you lose the use of paint tools, and while we have been installing custom fonts in stacks for awhile, Apple DTS says this is a no-no and will break in System 7 and could cause potential problems with font number conflicts even without Sys 7. Other maladies have been warned about, but it's usually worked out okay for most scripters to attach thaeir fonts to their stacks so far. To be completely safe from such problems ( but less convenient and portable) install the custom font in your system normally or via Suitcase instead of the stack. I have an incomplete game stack that I did with such a font to represent map spaces and pieces, which has the scripts in it that deal with moving the player's piece around on the map and testing to see what he lands on, never took it any farther. If you need such to help, I can probably dig it out and send it to you as an example. Ed Allen eallen@sybase.com
Ken.Knight@f421.n109.z1.FidoNet.Org (Ken Knight) (05/14/91)
to: jkc@Apple.COM What extension to the read command have been implemented in HC 2.1? One thing I've been involved with is a stack that I helped create that lets you read/reply/write mail offline. It is overall a fine stack, but it is terribly slow in the initial importation of messages from a file. The file follows a nice standard format that looks something like: MSG #: 1234 Sent: May 12 1991 18:50:12 Area: Comp.Sys.Mac.Hype [message text] <Return> Msg #: 12345 Well you get the idea. This takes a while to parse apart. Especially when reading in the message text since you do a Read until RETURN and then a check for "MSG #:". Slow. I'm working on implementing a fastread external that'll speed such reads to keys up. The idea being to use a Boyer-Moore search algorthim that should reduce search times considerably. For example, the average message runs about 20-25 lines so you pass through the inner loops 20-25 times (and HC's read is doing a linear search to find each return - call that 75 characters on average per line to check). My XFCN would reduce that from this linear-based time to something on the order of, hopefully, M/N-time (M=size of string being worked on; the message; N is the key length). But, if something like this is coming for READ I could drop the project. Is something like this coming: a read to keystring; which is FAST (not your average brute-force search for keystring)? Sorry, to be so long winded, but this is of interest to me since OffLine is gathering some competition in some respects (and the irony is I'm helping beta test the product), but the competition is not as refined where Internet is concerned (but is much faster). I want to remedy this. ** Ken ** * Origin: Twilight Clone - Macintosh Files Board - 301-946-8677
jkc@Apple.COM (John Kevin Calhoun) (05/17/91)
In article <674217627.0@blkcat.FidoNet> Ken.Knight@f421.n109.z1.FidoNet.Org (Ken Knight) writes: >What extension to the read command have been implemented in HC 2.1? You can now access files randomly as well as sequentially. read from file "Fred" at 100 for 12 read from file "Fred" until end -- 'eof' works too write myVar to file "Fred" at 200 write moreStuff to file "Fred" at end -- 'eof' works too In addition, the 16K limit on the amount of text that could be read at once has been removed. If the amount of text you ask for won't fit in memory, HyperCard sets the result to "Not enough memory to read from file." >Is something like this coming: a read to keystring; which is >FAST (not your average brute-force search for keystring)? No. But it might be faster for you to read large chunks of data into a local variable and then use the various HT functions and operators to parse your text. Using "offset", "is in", and "contains" with a larger HT container is faster than reading the file in small chunks. Kevin Calhoun jkc@apple.com