sho@tybalt.caltech.edu (Sho Kuwamoto) (11/28/87)
I want to implement a very simple spreadsheet like window for purposes
of data entry. What I mean by very simple is the following:
1) Cells can only hold numbers
2) The user should be able to click in a cell and get an insertion
caret, and be able to use TextEdit like things (shift for
selection, etc.) as well as type.
3) The user should somehow be able to select a range of cells.
I thought perhaps the List Manager would come in handy, but after
reading it over, I somehow don't think so. It seems very difficult to
provide a mechanism to let the user edit the contents of a cell in
intuitive way. (or at all)
I know this may sound ridiculous, but what would be the overhead in
opening up a TextEdit record for each cell? In my case, that would
come out to about 600 records maximum.
I also thought about having only one TextEdit record, but moving it
around to whichever cell was being modified, and putting the right
characters in it. This seems inelegant.
I would rather not write this all from scratch, but if it is
necessary, I would appreciate any tips you may have to give.
-Shorick@uwmacc.UUCP (the absurdist) (11/30/87)
In article <4693@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: >I thought perhaps the List Manager would come in handy, but after >reading it over, I somehow don't think so. It seems very difficult to >provide a mechanism to let the user edit the contents of a cell in >intuitive way. (or at all) The answer is, don't edit on the cell itself, edit in an edit box. The two most popular spreadsheets in the world (123 and Excel) are both implemented in this way, although neither uses the List Manager. When they double click on a cell, COPY the contents to a textEdit record displayed above the spreadsheet; let them edit there, then either replace the cell with the edited cell or cancel (replacing the contents of one cell with a new value is quite easy in the List Manager). This has the advantage from the "intuitive" standpoint that it is clear they are working on a copy; the original is still there on the list where they can see it, think about it, and compare it to the new version. The list manager can do a LOT; developing a replacement for it would be a substantial enough investment of time that you'd probably lose functionality in other branches of your program. -- Rick Keir -- all the oysters have moved away -- UWisc - Madison "Watch the skies...."
tim@hoptoad.UUCP (12/05/87)
There's no reason you can't create a text edit field exactly the size of the
list cell, which would look to the user as if it were the list cell. When
there's a click, copy the field into a text edit record. When another cell
gets clicked, convert from the text edit record back into the cell. I think
it would likely be more confusing to put the text edit field somewhere else,
as the absurdist suggested.
--
Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/05/87)
In article <3487@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >There's no reason you can't create a text edit field exactly the size of the >list cell, which would look to the user as if it were the list cell. When >there's a click, copy the field into a text edit record. When another cell >gets clicked, convert from the text edit record back into the cell. For months, I've actually been using a program I wrote that works this way. I manage the mailing list for a folk club, and I need reports sorted in zip code order and in alphabetical order by last name, and mailing labels in zip code order. The Alpha sort routine has to ignore "Jr." and "III". The woman who does the typing has been using the Mac so long that she naturally uses MacASCII when appropriate, so the file is full of names that have foreign letters in it. I didn't want to burden the folk club with the need for expensive software, so I wrote my own. As Tim says, it uses a list of text records, but if you select one for editing, it turns into a text edit record without any visual indication. The Dialog Manager, and HyperCard use a similar scheme to time slice one text edit record across multiple editable text fields. Since the club only has 2000 to 5000 names on its list, list manager's 32767 item limit has not been a problem. This software works, and I use it, but it still has some rough edges (The disk error mesages aren't as clear as I would like, since it is just for me, it only handles one size of label.) If I thought there was some interest in it, I'd release it as shareware, with a $15.00 use fee, and source code avaliable for $100.00 (I've already had customers for the source at that price.) The folk club mailing list isn't mine to sell, but if you are interested in buying that, I could put you in touch with the club's governing board. Should I rewrite my software as a hypercard script? Advantages: fast searching no size limits Disadvantages: I've been planning to add incremental searching (searching while you type the search string.) and two lists side by side. One client wants to type in names from a handwritten list, and have the software chime for a unique match against the master list, and copy the name to the second list. It'll beep if it can't find any matching names in the master list. That will let her use the handwritten list to create a subset from the handwritten list, mostly without looking at the screen. Then she'll print the subset list. I don't know how to do this in Hypercard. This client also has an old fat mac that she can't afford to upgrade, so if I use hypercard, she won't be able to run it anyway. Since I use the list manaager, the typist can see many records all at once, each on its own single line. (The get expanded to 2 to 5 lines at print time.) I don't know how to fit this in with the "a record is a card" philosphy of hypercard. The search keys are fairly complex: the one for zip code order is: take the last token on the last line as a zip code (the mailing list is a local Berkeley one, so I don't have to worry about foreign conventions. This makes mis-entered data show up well in the print outs.) If two zip codes match, then compare last names: a last name is the last token on the first line. If the last token ends in a period character, or is in a list of illegal last names: ("II, III, IV, V") and there is a previous token on the line, then try that one. If two last names match, then compare the two records as text. I've also been asked to produce reports that are sorted by zip first, then by street name, then by street number, then by last name, so the folk club can find multiple mailings to similar addresses. Once again, it seems easier to just write it than to write it in HyperCard. What are other people using? --- David Phillip Oster -- This sentence is a lifelike replica of Arpa: oster@dewey.soe.berkeley.edu -- one by Douglas Hofstadter. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu