Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!uflorida!gatech!ncar!tank!uxc!uxc.cso.uiuc.edu!a.cs.uiuc.edu!s.cs.uiuc.edu!jgolton
From: jgolton@s.cs.uiuc.edu
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Problem with "word"
Message-ID: <214100002@s.cs.uiuc.edu>
Date: 18 Oct 88 18:34:00 GMT
References: <135@sunset.MATH.UCLA.EDU>
Lines: 34
Nf-ID: #R:sunset.MATH.UCLA.EDU:135:s.cs.uiuc.edu:214100002:000:1569
Nf-From: s.cs.uiuc.edu!jgolton    Oct 18 13:34:00 1988


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