bayes@hpfcdc.HP.COM (Scott Bayes) (02/24/88)
I am only an egg... In my Apple HyperCard Manual for the mentally deficient, I see no way to do something that seems to me fairly obvious. I want to construct richly hyper-linked textual data bases. An example would be gathering up great gobs of say comp.sys.mac notes files into a stack, and cross-linking the bejeesus out of them, creating "topical threads" through the stack. Is there a simple script, XCMD, or whatever that will perform the following sequence in one chunk? after selecting text in a field (click-drag, double click, whatever): create a transparent button just the size of the text selection label the button some way (like the "*" in the Help stack), to indicate a hot-spot. I forget, is there a "framed transparent" button? perform a link to.. and let me choose a target card (or stack) return to my selection ?? Right now, it seems I have to: create new button select style and size it manually (the real nasty for this task) I don't know how to mark the hot-spot, except by modifying the field content to add a "*" or something link to.. and I can't remember whether HyperCard returns me to my previous card Also, is there a "floating button" for use in scrolling fields? One screen is pretty small, so I'd need scrolling fields for my text. How do I attach the button to a selection that may be offscreen or in a different display-relative position at any time? Scott "on mouseUp" Bayes bayes@hpfclw
ns@CAT.CMU.EDU (Nicholas Spies) (02/26/88)
There are several potential solutions to making alot of cross-linked
references within (and without!) HyperCard:
1) Using a LOCKED field (locked to intercept mouse clicks) include the
following script to get a word clicked on:
on mouseUp
set lockText of the target to false
repeat two times -- double click where user clicked
click at the clickLoc
end repeat
put the selection into selected -- fetch resulting selection
go card selected -- or whatever else you want to do
set lockText of the target to true
end mouseUp
(This approach originally appeared on the net a few months ago and is
useful mainly to link to cards named with the words selected [among other
uses]).
2) If words are in scrolling fields (ONE PER LINE), you can calculate the
line number by doing some math using the clickLoc, the "top" of the field
rectangle, the scroll value, the textHeight and by factoring in the effect
of the wideMargins. This is best done in the form of a function using these
factors for "the target" and returning the line number clicked on; use the
line number to fetch the field line contents and link as above to a card
named with the word found.
3) Creating "*" buttons is FAR easier if you write a handler to make a button
with all the qualities you want (name, style, font, size, etc) at the location
you click on after you invoke the handler in the Message box. As part of
this process, set the script of the newly-created button to the text returned
by a function you write. Such a function is written thus (the $ is the
option-return "continuation" character that is NOT optional):
on buttonScript cardNum
return $
"on mouseUp" & return & $
"go card" && cardNum & return & $
"end mouseUp" $ return
end buttonScript
Make one long string with & and &&, putting in return for each end of line,
and option-return to make it readable in this script.
on NB cardNum -- new button
get the number of card buttons -- or bkgnd buttons
add 1 to it
put it into bNum
wait until the mouseClick
put the clickLoc into cLoc
doMenu "New Button"
set name of card button bNum to "*" -- or whatever
set rect of card button bNum to $ -- or use calculated size for rect
item 1 of cLoc, item2 of cLoc, item 1 of cLoc + 50, item 2 of cLoc + 20
set style of card button bNum to [whatever]
set textFont of card button bNum to [whatever]
set textSize of card button bNum to [whatever]
...etc..
set script of card button bNum to buttonScript(cardNum)
end NB
Leave with button tool active for final positioning; you can use command-tab
to select browse tool when done.
So (unless I made a mistake!) buttonScript(5) would return
on mouseUp
go card 5
end mouseUp
which is made the script of the button created by your main button-creating
handler, invoked in Message with NB 5 <return> followed by a click where you
want the button to be.
I have found that many common actions (aligning fields, some drawing,
show/hide, etc) are best done by writing handlers and using Message as a
command line.
4) The non-HyperCard option is to get Guide 2.0, which is altogether different
from HyperCard. Guide uses ordinary (multiple) windows that co-exist with
DAs, can be resized and moved around, etc. If you have text elsewhere, just
import as plain text and add four types of buttons:
1) replacement- opens and closes (hides) an arbitrary amount of text
1a) a variation allows only one of a set of buttons to open at once
2) reference - "go to" text or graphics in same or other file
3) note - display a pop-up note field
4) command - invoke an external command (CODE resource like XCMD in H-C).
In addition, Guide supports the pasting of color graphics created elsewhere,
and graphics too can be opened and hidden or marked with hot-spots that act
just like regular text buttons. (I use the Canvas DA; Canvas is like a
happy marriage of MacDraw and MacPaint, plus much more...). Using the DA
version of Canvas gives color and more functionality than HyperCard
graphics; the only limitation is that you have to paste graphics. But Guide
is predominately a programmable outline processor where graphics appear
within text but can't be composed with the precision available in HyperCard,
so pasting is just fine.
The external commands supplied with Guide permit 1) launching other
applications and 2) use the serial ports, mainly for output. (Two complete
videodisc drivers took me about an hour apiece to write using the supplied
serial routines, with graphic mockups for control panels). OWL will supply a
developer's kit for writing these external CODE resources, I assume much
like XCMD stuff from APDA.
Guide is a programming evironment like HyperCard, but it may appeal to
those wishing to cross-link text and graphics with a minimum of fuss,
without losing contact with the regular Mac environment. (You know,
full-screen windows, color, DAs, etc).
Dan Winkler's general response to my (and others') wishes for graphics
fields hasn't been sitting well with me: his reason for rejecting them cited
the tradeoff between simplicity and power and that power was useless if
simplicity is lost. [I'd have inserted a quote if I had it available.]
I think the reason this doesn't wash is that although foreground and
background graphics are doubtless a programming triumph, they are not as
generalized (read 'simple') as graphics fields would be. Foreground and
background graphics are just a special case of two full-card-sized graphics
fields. Further, the paradigm of text fields is easily comprehended and
graphics should be able to be manipulated in the same way; that is, one
should be able to slide around an arbitrary number of bit-image objects to
compose graphics, or show or hide graphics as one can text fields. In my
opinion, this would be a cleaner paradigm, and much more powerful too.
It would make sense that graphics fields were nixed because they would take
up too much disc space, but it doesn't make any sense that a less consistant
graphics paradigm would be chosen on principle; I hope the idea is
reconsidered.
Taking another tack, with the advent of DAs such as Canvas, it would make a
great deal of sense to have a version of HyperCard that was stripped of the
graphics tools altogether (why use 350K+ or whatever when a 60K [on disk] DA
does as well, or better?) to allow more card buffering in RAM and a general
improvement of the database functionality of HyperCard. BTW, Graphic Works
and Canvas (the program and the DA) have MacDraw objects and MacPaint-like
bit-planes that can be moved around and overlapped just like objects. Once
you draw in this sort of environment it's hard going back...
HyperCard's authors seem to have taken the same approach as Jobs did with
the original Mac; its a do-it-all closed system with only certain prescibed
ways to extend its capabilities (your own HyperTalk commands, XCMD, XFNC but
no high-level support for new menus, dialogs, windows, lists, etc). It might
be interesting if HyperCard were broken down into several modules or a main
application and DAs that would invite integration with programs offered by
other vendors. The core program to "run" a stack should only require a
fraction of the memory of the full-blown development version, and would make
it more attractive for tutorial and stand-alone use, where stacks shouldn't
be changed anyway. Even if memory usage wasn't affected, at least it might
make H-C useful without a hard disk.
It might also be nice if a stack could be compiled along with the HyperCard
core program into a stand-alone program with all extra code (say, for
uneeded tools and for handling messages that are never explicitly used)
removed. This would doubtless make H-C applications run much faster and take
up much less space.
DISCLAIMER: I have no connection with Canvas, Graphic Works or Guide except
as a satisfied user.
--
Nicholas Spies ns@cat.cmu.edu.arpa
Center for Design
of Educational Computing
Carnegie Mellon Universityhoward@cpocd2.UUCP (Howard A. Landman) (02/27/88)
In article <10520001@hpfcdc.HP.COM> bayes@hpfcdc.HP.COM (Scott Bayes) writes: >Is there a simple script, XCMD, or whatever that will perform the following >sequence in one chunk? > after selecting text in a field (click-drag, double click, whatever): > create a transparent button just the size of the text selection > label the button some way (like the "*" in the Help stack), to indicate > a hot-spot. I forget, is there a "framed transparent" button? > perform a link to.. and let me choose a target card (or stack) > return to my selection I think the buzzword for what you're looking for is "text buttons". Wait for the next release of HyperCard. I read somewhere that Atkinson considered this to be THE single most important missing feature, and was working hard to implement it for the next release. You're better off waiting than implementing it in script kludges. There are ways, if you're desperate, but I hope you're not that desperate. Personally, I think having the text be boldface would be the best indicator. Boxes over text always look weird. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET
bayes@hpfcdc.HP.COM (Scott Bayes) (03/02/88)
I have seen a number of excellent responses to my question about "rich hyper-linking" in HyperCard, both here and in my e-mail. Thank you all. I'm glad to hear Atkinson thought this is a major feature worth doing. Its lack makes HyperCard much less HyperTexty than I had hoped for. Scott Bayes