sam@sonia.math.ucla.edu (10/18/88)
I have been working on a little stack to practice my Czech grammar with.
I have a field with the correct hard adjective declension, basically a bunch
of words I want to memorize, and a button which asks for one of them and
checks that I type it in correctly.
/
One word is novy including the accent mark above y. Now I have a Czech font
which uses option-y for accented y, so the field includes n-o-v-option-y
as the first word of line 1.
But " Put word 1 of line 1 of card field 2 into card field 3"
gets me only "nov", so I assume that hypercard doesn't recognize option-y
as part of a word. I hacked around this by adding periods at the end
of all the offending words, but is there a better way?
v v
dekkuji dobre!
******************************************************************************
Sam Needham, UCLA Mathematics
Tooral Li-ooral Li-addity
******************************************************************************ns@cat.cmu.edu (Nicholas Spies) (10/18/88)
The HyperCard Script Language Guide: The HyperTalk Language, on page 55,
says that "Words are composed of any characters, including punctuation,
delimited by spaces, and are designated by the chunk name _word_..." sounds
simple enough--only problem is that it's not true, in that European characters
such as the German double-s ("B") are treated as a space, too.
This is a particular shame, because it further complicates using HyperCard for
language-tutorial stacks, an obvious and important class of application.
Some new text operations would help greatly: such as...
--the clickLine == return the line number of a field clicked on, compensating
properly for scrolling and wideMargins;
--if the above is too difficult, because of line wraparound, have the
clickLine return the _text_ delimited on either end by return characters;
--the clickWord == return the space-delimited word clicked on; this
shouldn't be hard to do because HyperCard can do it already with a
double-click for selection OR command-click to put word into Message, both
which sort of do what's wanted but require special user action and have the
side effects of selecting the word or showing message box.
-- the clickChars first, last == return an arbitrary string of characters
starting from character "first" to character "last"; thus the clickChars |,|
could be used to return substring between "|" characters, for example.
--the offsetLine(pattern, text) return the line number of pattern in text;
this would be extremely useful for table lookups.
--permit the programmer to decide what character to use to separate an
item list; retain commas as default, but permit changing the character used
for items with "set itemChar to <char>" which would last for the duration of
execution of the current handler; this would not conflict with current usage
and would allow many interesting parsing operations to be done quite easily.
-- define "comma" as a system constant, like "space" and "return".
--the selectedPos == return the character position of the start of the
selection, even if the selection is just an insertion point; one should be
able to indicate where to, say, split a paragraph of text with a single
click, rather than having to make a slow and potentially dangerous selection
by dragging accross the text.
--
Nicholas Spies ns@cat.cmu.edu.arpa
Center for Design of Educational Computing
Carnegie Mellon Universityjgolton@s.cs.uiuc.edu (10/19/88)
This is not a problem with HyperCard, but with the Mac OS, which has a
built in (and difficult, I believe, to modify) word delimiter routine.
This routine considers some characters word-worthy (a-z,A-Z, and a few
others), and others not (':', option-y, option-g, etc.). I've had the
same problem working with Esperanto fonts.
Here are some ugly solutions which are perhaps less messy than typing
periods after everything, or doing some serious Mac OS hacking:
First, Use a font manipulation program to copy the bothersome
character(s) to a character in Mac's ascii set which IS word-worthy.
You now have two copies of the character, one word-worthy and one not.
You can then either
1) Allow user to type word-worthy characters only. This would mean
doing unintuitive things like typing option-w when you're thinking "g
with an accent".
2) Trap incoming keystrokes (perhaps using the InKey() XCMD) when the
user is entering foreign text in a field. Convert any non-word-worthy
characters to their word worthy equivelant before it gets put into the
field. This makes typing painfully slow for the user, but it should work.
3) After the user enters text into the field (on closeField), run the
field text through a filtering function which simply copies
word-worthy characters verbatum, and converts non-word-worthy
characters to their word-worthy equivalent. This could easily be
written either as a HyperTalk script or an XCMD. This is okay as long
as you're not trying to do anything fancy while the user is entering
text.
Joe Golton
jgolton@s.cs.uiuc.edu