jgsmith@watson.bcm.tmc.edu (James G. Smith) (10/02/90)
Well, if not HC 2.1, then maybe 3.0. What I would like is a new object, the data field (as opposed to the text field). In a data field you would be able to select a column or a row. Except for this ability, this new object could be just exactly like a text field. So call those guys back from vacation and get started on this, okay Apple... I mean Claris. BTW, we all have seen the guys from Apple on the net. Is there anyone from Claris reading this list? *
via@well.sf.ca.us (Tony Cecala) (10/07/90)
I agree completely that row/column functionality should be added to HyperCard fields. This would tremendously improve functionality, make simultaneously scrolling columns a snap, and would open up a new genre of HyperCard applications. By adding it as a property of fields it could be comfortably absorbed into the current user interface. Functions like "the clickChunk" could return the selected cell coordinates. While I'm sure that the team is already considering this. I'd like to add my vote in favor of it. Tony Cecala VIA, Inc.
maller@applelink@apple.com (Steve Maller) (10/09/90)
In article <21064@well.sf.ca.us> via@well.sf.ca.us (Tony Cecala) writes: > I agree completely that row/column functionality should be added > to HyperCard fields. This is a highly-requested feature, but one that would be much trickier than you think from HyperTalk's point of view. Everything inside of HyperCard can be referred to as plain text (fields, properties, variables, chunks, etc...). If you implement a spreadsheet-type field, how will you refer to parts of it? In a way that is smooth from one variable type to another. We argued about this feature (and arrays, too) and decided that it would be too much of a kludge in the native HyperTalk lexicon. Maybe someday if we can figure a *clean* way of doing it... Steve Maller HyperCard Engineering Team Apple Computer ------------- I speak solely for myself in these matters
rudd@calvin.tmc.edu (Kevin Rudd) (10/09/90)
There are a number of different ways of referring to sub-elements of different systems. Fortran uses (coords), Pascal and C use [coords], etc. One could use any kind of delimeters to provide this functionality without violating the spirit of HC. foo.x.y might work as might the addition of row x column y of foo. Since matrices and such are different types of objects, they must be "similar" to other types, not "exactly the same as". For example, buttons and text fields are different. One cannot say: word 3 of line 5 of card button foo. It just doesn't work. By the Apple/Claris response I would expect that buttons and fields will either be consolidated or one will lose out to the other to maintain the "consistent user interface". Understand that the "consistent user interface" is the one thing that sets the mac apart from other machines---PC's and workstations alike. However, there is no reason to release crippled software solely for the sake of a "consistent user interface". Does MacWrite obey the EXACT commands of Hypercard? Or the Finder? None of these things are identical. For that matter, will a HC 2.0 stack work on HC 1.5? HC 1.0? If the "consistent user interface" were really a requirement, no new features would ever be seen as compatability must be maintained. Only bug fixes and performance enhancements would need to be considered. Of course, the previous paragraph is really not the case. New versions almost always have new (and sometimes different) features. Hence the creation of the Mac line. The Mac II line. Otherwise we'd all be sitting behind increadibly fast (but dumb) Apple I computers. By adding a new field type of "Data" or "Matrix" or "Array" to "Button" and "Text" HC would be vastly increasing the capability of users to generate applications. Consider the common application called a "Calendar". This is kluged beyond belief in the Apple Distribution of HC. The problem would have been trivial for the programmer had s/he had a grid instead of an assembly of fields. Please, Apple. Do not be blind to progress for the sake of 100% stability. And don't plead compatability on some items and then change the rules on other items. Neither is a good way to be. Support your users --- the ones who buy your computers and pay your saleries and dividends. Remember, if Apple doesn't support the customers, either someone else will or there won't be customers. In either case, Apple loses. Custom statement and disclaimer: I don't use HC. One of the major reasons is that it is impossible to set up fields with more than 0 dimensions. Many of the applications which HC begs to solve REQUIRE this capability. Otherwise HC is only a flat image/text linked system good for games like Cosmic Osmo and imitations of simple 3x5 cards. -- Kevin.
jgsmith@watson.bcm.tmc.edu (James G. Smith) (10/09/90)
Is there any way to select non contiguous text, or would this also be too messy a kludge. All I really want is to be able to select a column of text. Something like "select word 2 of every line in field foo". Maybe this is just the same problem. By the way, doesn't the program Plus have such data fields? * .
TJACOBS@cc.utah.edu (10/10/90)
In article <10614@goofy.Apple.COM>, maller@applelink@apple.com (Steve Maller) writes: > References:<2106@gazette.bcm.tmc.edu> <21064@well.sf.ca.us> > > In article <21064@well.sf.ca.us> via@well.sf.ca.us (Tony Cecala) writes: >> I agree completely that row/column functionality should be added >> to HyperCard fields. > > This is a highly-requested feature, but one that would be much trickier > than you think from HyperTalk's point of view. Everything inside of > HyperCard can be referred to as plain text (fields, properties, variables, > chunks, etc...). If you implement a spreadsheet-type field, how will you > refer to parts of it? In a way that is smooth from one variable type to > another. > > We argued about this feature (and arrays, too) and decided that it would > be too much of a kludge in the native HyperTalk lexicon. Maybe someday if > we can figure a *clean* way of doing it... > > Steve Maller > HyperCard Engineering Team > Apple Computer > ------------- > I speak solely for myself in these matters HyperTalk already understands "items" and "lines". Couldn't "rows" and "columns" just be an alias for items and lines? Then what you need is is a way to display those kinds of fields in a spreadsheet fashion and to handle clicks on that kind of field. A special field could be used for cell programming which allows you to use HyperTalk in a normal fashion. Eash cell which has a script would simply be held in the fields script like the following: on R1C2 do some hypertalk stuf... return (some value) end R1C2 . . . on RnCn do some more stuf... return (some value) end RnCn Then when ever a click on a cell has occured or has changed then you simply execute the handler for that cell. The special field for editing the handlers would simply take care of the cell addressing and perhaps hide the on...end stuf. This could all be done with regular HyperTalk and a regular field. Then of course you would need the multi cell selection/copy/paste stuff. It seems like the way to do is is with a multi-celled "List" structure which is already in rom or system toolbox code. Now, if you have a background field like this, then you have a 3 (or more) dimensional spreadsheet! This seems fairly clean to me. Am I missing something? Tony Jacobs Center for Engineering Design University of Utah
taylorj@yvax.byu.edu (10/10/90)
In <10614@goofy.Apple.COM>, maller@applelink@apple.com (Steve Maller) writes: >In article <21064@well.sf.ca.us> via@well.sf.ca.us (Tony Cecala) writes: >> I agree completely that row/column functionality should be added >> to HyperCard fields. > >This is a highly-requested feature, but one that would be much trickier >than you think from HyperTalk's point of view. Everything inside of >HyperCard can be referred to as plain text (fields, properties, variables, >chunks, etc...). If you implement a spreadsheet-type field, how will you >refer to parts of it? In a way that is smooth from one variable type to >another. Just to get the ball rolling, here are my thoughts... To add a spreadsheet or array capability to HyperCard you simply need to define two new delimiters. One for rows and one for columns. You could then refer to "column X of row Y" or "cell X of row Y". It seems like the logical delimiter for cells would be the tab key. HyperCard would have to stop throwing away tabs, but it could just ignore them when they occur anywhere but in a field with the "showCells" property set to true. The delimiter for rows could just be the return character (and "line" could be used instead of "row"), but you would then be limited to a single line of text per cell. Using a separate delimiter for rows would make things work more like the tables in MS Word 4.0. Unfortunately, I haven't been able to think of a good delimiter for rows. Maybe the option-Return character? Perhaps I just haven't thought it out thoroughly enough, but I see no major obstacles to this scheme. Maybe if Steve could share the objections produced by the HyperCard team when they discussed this, those of us on the net might come up with some interesting solutions. Jim Taylor Microcomputer Support for Curriculum | Brigham Young University | Bitnet: taylorj@byuvax.bitnet 101 HRCB, Provo, UT 84602 | Internet: taylorj@yvax.byu.edu
SAS102@psuvm.psu.edu (Steven A. Schrader) (10/11/90)
In article <98061@cc.utah.edu>, TJACOBS@cc.utah.edu says: > >In article <10614@goofy.Apple.COM>, maller@applelink@apple.com (Steve Maller) >writes: >> References:<2106@gazette.bcm.tmc.edu> <21064@well.sf.ca.us> >> >> In article <21064@well.sf.ca.us> via@well.sf.ca.us (Tony Cecala) writes: >>> I agree completely that row/column functionality should be added >>> to HyperCard fields. >> >> This is a highly-requested feature, but one that would be much trickier >> than you think from HyperTalk's point of view. Everything inside of >> HyperCard can be referred to as plain text (fields, properties, variables, >> chunks, etc...). If you implement a spreadsheet-type field, how will you >> refer to parts of it? In a way that is smooth from one variable type to >> another. >> >> We argued about this feature (and arrays, too) and decided that it would >> be too much of a kludge in the native HyperTalk lexicon. Maybe someday if >> we can figure a *clean* way of doing it... >> >> Steve Maller >> HyperCard Engineering Team >> Apple Computer >> ------------- >> I speak solely for myself in these matters > >HyperTalk already understands "items" and "lines". Couldn't "rows" and >"columns" just be an alias for items and lines? Then what you need is is Alternatively, you could add in a tab character, and define a row as a tab delimited text, much as an item delimited text is an item. I know that this is not strictly, ASCII here, but If I want to print on the Laser my items will not line up if I use spaces (which would be an alternate way of doing things). The tab will also help to indent paragraphs of text. Since Apple extended ASCII supports the TAB why can;t it be added to HyperTalk? ---------------------------------------------------------------------- Steven A. Schrader (SAS102 @ Psuvm.Bitnet) Student Consultant Coordinater Student Support Initiative, The Center for Academic Computing The Pennsylvania State University
mxmora@unix.SRI.COM (Matt Mora) (10/12/90)
In article <90284.080451SAS102@psuvm.psu.edu> SAS102@psuvm.psu.edu (Steven A. Schrader) writes: >delimited text, much as an item delimited text is an item. I know that this >is not strictly, ASCII here, but If I want to print on the Laser my items >will not line up if I use spaces (which would be an alternate way of doing >things). > >The tab will also help to indent paragraphs of text. Since Apple extended ASCII >supports the TAB why can;t it be added to HyperTalk? >---------------------------------------------------------------------- > Steven A. Schrader (SAS102 @ Psuvm.Bitnet) Since when is the tab key not standard ASCII? I believe that the only problem with the tab key is that textedit doesn't support it and since hypercard's fields are based on TE the limitation will be there for a while. -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
rmh@apple.com (Rick Holzgrafe) (10/18/90)
MAJOR DISCLAIMER: I have nothing to do with HyperCard! Nothing! Now: In article <17178@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: > In article <90284.080451SAS102@psuvm.psu.edu> SAS102@psuvm.psu.edu (Steven A. Schrader) writes: > > >delimited text, much as an item delimited text is an item. I know that this > >is not strictly, ASCII here, but If I want to print on the Laser my items > >will not line up if I use spaces (which would be an alternate way of doing > >things). > > > >The tab will also help to indent paragraphs of text. Since Apple extended ASCII > >supports the TAB why can;t it be added to HyperTalk? > > > Since when is the tab key not standard ASCII? I believe that the only problem > with the tab key is that textedit doesn't support it and since hypercard's > fields are based on TE the limitation will be there for a while. There's more of a problem than that. I don't say that any of this stuff is unsolvable, but it adds up. Consider: where do tab stops appear? You can't say "every eight columns" with a proportional font. So, every inch? Every quarter-inch? OK, let's make it a property of a field, and measure it in points, where one point = one pixel on standard Mac monitors. Now how do you set or change the tab spacing? From HyperTalk it's easy - Set the tabWidth of card field Foo to 50 - except that you'll usually have to guess at the number of points you need, and then look at it to see if it's right, then type more HyperTalk to tweak it if it's not right - kind of a pain. And non-scripting users are locked out by a HyperTalk-only solution; what do you do for them? Complicate the "Field Info" box, probably, by adding a "Tab settings" button or control. But "Field Info" is modal, so they too will have to guess, click "OK', look at the result, and try again. Next observation: tabs are less use than you might think if you can't put them exactly where you want them. That is: instead of "tabs every inch", what most people usually want is a tab HERE, and a tab HERE, and one way over HERE and no other tabs at all. This is because one frequently wants columns of differing widths to accomodate entries of differing widths. If there are tab stops in the middle of what the user wishes to consider a single wide column, then differing entry lengths require a differing number of tab characters to reach the next column. This is a pain both when you're editing your entries manually, and when you're trying to generate the entries from HyperTalk. So, tabs are less wonderful if they can't be placed arbitrarily - but think how much that complicates the tab-setting problems discussed above! And then there's the matter of the existing convention for the tab key, which is to switch to the next field. Suddenly the tab key has changed its behavior, an annoyance Apple just hates to visit on its users. (Not that we never do: just that we don't like to. :-) Even worse, I suspect the solution would be to keep the old behavior of the tab key except for "tab-enabled" fields; and now the tab key can have TWO behaviors on the same card, and you can't tell which you'll get until you try it. Well, none of this is insuperable; word processors do it every day. I just wanted to point out that it's not *simple*. It's one of those cases where an innocent request ("I just wanna line up my text nicely") leads to a whole rat's nest of difficulties. I've tried implementing tabs myself, in simpler environments, and believe me - they're complicated. So add up all the time to decide on the user interface, and test it on live users, and tweak it until it's right. Add in the time to design and code the software, and remember that it has several parts: drawing tabbed text, hit-testing tabbed text, editing tabbed text, the user interface for setting tabs, and the HyperTalk extensions for dealing with tabs. Add in the time to rigorously test it all, and knock all the bugs out. Don't forget to document how it all works, both for the casual user and for the HyperTalk programmer, and both for the printed manuals and the Help and Reference stacks. Review and debug the documentation, and test THAT on casual users to make sure it's understandable. And while you're adding up all that time, also add up the expense and extra manpower required to do it all, and the incremental expense of the increased size of HC itself, its Help stacks, and its printed manuals... ... and now maybe you can see a reason why you *don't* have tabs in HyperCard, even if you don't see any reason why you *can't*. :-) :-) :-) Hope this helps you all to endure the frustration. I, too, "just wanna line up my text nicely" - but I think we'll all have to wait! ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."