roh@gmdzi.UUCP (Peter Rohleder ) (10/31/89)
I thought about writing a background script which automatically sets the style
of the field which probably contains a large chunk of text to the necessary
style. (By the way: I'm working with HyperCard 1.2.2)
Theat means: If the chunk of text exceeds the size of the rectangle of
the field the style should be set to scrolling - otherwise the style
of the field should be set to rectangle.
My thought was to position the text selection behind the text, then to look
if the scroll of the field is unequal zero. If it is unequal zero, the text has
a size that makes scrolling necessary, otherwise I decrease the size of the
rectangle of the bkgnd field until the scroll is unequal zero. Then I set the
rectangle to the last value which it had before the scroll changed to non-zero.
This script should always get executed on "openCard".
It works fine so long as you don't decide to run it with the screen locked.
When I lock the screen it seems that the value of the scroll doesn't get updated
correctly and HyperCard runs into a never ending loop.
In all HyperCard(HyperTalk)-Manuals which I have access to, you
can read that all scripts should run as good or even better with locked
screen if you decide that locking the screen seems more senseful for
the user. Or are there any exceptions ?
What do you think ?
Or do you have a XCMD which probably can help me to solve the problem
of changing the field style corresponding to the size of text it contains ?
If you want, you can try it:
on openCard
--- lock screen --- try to run the script with locked or unlocked screen
set cursor to watch
select after last word of field WhichContainsText
put the scroll of bkgnd field WhichContainsText into SCR
if SCR = 0 then
get the rectangle of bkgnd field WhichContainsText
put it into theR
repeat until SCR <> 0
put last item of theR into low
put low into prevVal
get the rectangle of bkgnd field WhichContainsText
put it into theR
subtract 5 from low
put low into last item of theR
set the rectangle of bkgnd field WhichContainsText to theR
select after last word of field WhichContainsText
put the scroll of bkgnd field WhichContainsText into SCR
end repeat
get the rectangle of bkgnd field WhichContainsText
put it into theR
put prevVal into last item of theR
set the rectangle of bkgnd field WhichContainsText to theR
set the scroll of bkgnd field WhichContainsText to 0
set style of bkgnd field WhichContainsText to rectangle
else
set style of bkgnd field WhichContainsText to scrolling
end if
select before text of bkgnd field WhichContainsText
if style of bkgnd field WhichContainsText = "scrolling" then
set the scroll of bkgnd field WhichContainsText to 0
end if
--- unlock screen
end openCard
on closeCard
lock screen
set style of bkgnd field WhichContainsText to scrolling
set the scroll of bkgnd field WhichContainsText to 0
get the rectangle of bkgnd field WhichContainsText
put it into theR
put 309 into last item of theR --- 309 is the location of the bottom
--- if you have a scrolling field
--- may also be another calue
set the rectangle of bkgnd field WhichContainsText to theR
unlock screen
end closeCard
Peter Rohleder
roh@gmdzi.uucptim@hoptoad.uucp (Tim Maroney) (11/02/89)
In article <1649@gmdzi.UUCP> roh@gmdzi.UUCP (Peter Rohleder) writes: >If the chunk of text exceeds the size of the rectangle of >the field the style should be set to scrolling - otherwise the style >of the field should be set to rectangle. > >My thought was to position the text selection behind the text, then to look >if the scroll of the field is unequal zero. This is a very clever idea. However, the right way to do it is to use the built-in textMaximum property of every text field. What's that? You missed that property? Well, that's probably because they didn't bother to put it in, despite the fact that HyperCard must and does keep track of this quantity internally. It's one of many places where HyperCard simply does not give you the information you need to do what you want. (And you can't compute it yourself from the number of lines, because that doesn't take wrapping into account.) If this were one of the few places where this happened, I wouldn't bother to bitch about it here. But it isn't. I doubt that many HyperTalk programmers would disagree with me that the most annoying thing about the language is the Rube Goldberg nature of so many non-trivial scripts. So often, you have to come up with something clever and contorted to do things that would be perfectly straightforward if HyperTalk were a little more fleshed out. It's like going halfway around the world and back just to run down to the corner market. In this way, I think C programming is easier; while it's sometimes obscure even to those of us who've been doing it for many years, at least you can just do what you need to do, rather than running into language limitations all over the place. And I don't feel that adding the maybe twenty to forty necessary new properties and commands to HyperTalk would make it as obscure as C. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I've got troubles of my own, and you can't help me out. So take your meditations and your preparations and ram it up yer snout!" - Frank Zappa, "Kozmik Debris"
sean@eleazar.dartmouth.edu (Sean P. Nolan) (11/02/89)
In article <8871@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >What's that? You missed that property? Well, that's probably because >they didn't bother to put it in, despite the fact that HyperCard must >and does keep track of this quantity internally. It's one of many >places where HyperCard simply does not give you the information you >need to do what you want. (And you can't compute it yourself from the >number of lines, because that doesn't take wrapping into account.) Fair enough. A necessary feature (or at least one that would be very useful) is missing. So you tell Apple about it. >If this were one of the few places where this happened, I wouldn't >bother to bitch about it here. But it isn't. > [goes on to harsh on Apple about limitation of Hypertalk] Unfair. Hypercard is a revolutionary idea; Hypertalk even more so. Constructed in such a way that virtually anyone can not only use, but PROGRAM their computers - jeez, it's almost english. OK. So because they're missing a few capabilities, somehow they've done us some great injustice. It's only version 1.2.5 now. Hypercard is a project of tremendous magnitude -- they keep track of buttons, fields, window updates, dialog boxes, message handlers, on and on and on. The point being that the difference of HyperTalk is you can just say "do this" instead of having to worry about initializing managers, passing stuff to DAs, updating windows, etc. I don't know how coherent that was. But I don't think anyone really thought that Hypercard would explode like it has. It's an incredible piece of work. Give a little credit; don't act like they've somehow cheated us. The features will come. --- Sean +----------------------------------------------------------------------------+ | Sean P. Nolan | Net: Sean_Nolan@Mac.Dartmouth.EDU | "Let's face it: | | Dartmouth College | | IBM is no fun." | | Hinman Box 2658 | SCALP 'EM! | :::::::::: | | Hanover, NH 03755 | | John C. Dvorak | +----------------------------------------------------------------------------+
time@oxtrap.oxtrap.UUCP (Tim Endres) (11/03/89)
In article <8871@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
In this way, I think C programming is easier; while it's sometimes
obscure even to those of us who've been doing it for many years, at
least you can just do what you need to do, rather than running into
language limitations all over the place. And I don't feel that adding
the maybe twenty to forty necessary new properties and commands to
HyperTalk would make it as obscure as C.
And I have written only 4 libraries that allow me to crate HyperCard
like applications in no time flat. Actually, better that HyperCard.
In fact, I have heard only one comment about my latest creation...
"How do you do that in HyperCard?"
The answer: You don't.
HyperCard is not for development of applications. Period.
It is a nice prototyper. It is great for simple generic problems.time@oxtrap.oxtrap.UUCP (Tim Endres) (11/03/89)
In article <16461@dartvax.Dartmouth.EDU> sean@eleazar.dartmouth.edu (Sean P. Nolan) writes:
Unfair. Hypercard is a revolutionary idea; Hypertalk even more so.
FACT: Hypercard is not revolutionary, Hypertalk even less so.
Look, HyperCard's concept has been around since Ted Nelson. Many years.
(Sorry, Ted) Hypertalk is Basic. Bill had an old idea with the perfect
platform. He did a decent job, but could have done better.
Hypercard is a project of tremendous magnitude -- they
keep track of buttons, fields, window updates, dialog boxes, message handlers,
on and on and on. The point being that the difference of HyperTalk is you
can just say "do this" instead of having to worry about initializing managers,
passing stuff to DAs, updating windows, etc.
This is true. For the "non-programmer" HyperCard gives access to
Macintosh resources that otherwise would seem untouchable.
I don't know how coherent that was. But I don't think anyone really thought
that Hypercard would explode like it has. It's an incredible piece of work.
Give a little credit; don't act like they've somehow cheated us. The features
will come.
I think the current problem with HyperCard, and the reason for all the
debate, is that HyperCard has been dubbed a programming language.
While it is, it is not a complete development environment for the
Macintosh system. Never will be. Use it for what it is good for and
the discussions go away.lhe@sics.se (Lars-Henrik Eriksson) (11/03/89)
In article <1649@gmdzi.UUCP>, roh@gmdzi (Peter Rohleder ) writes: >Theat means: If the chunk of text exceeds the size of the rectangle of >the field the style should be set to scrolling - otherwise the style >of the field should be set to rectangle. > >My thought was to position the text selection behind the text, then to look >if the scroll of the field is unequal zero. If it is unequal zero, the text has >a size that makes scrolling necessary, otherwise I decrease the size of the >rectangle of the bkgnd field until the scroll is unequal zero. Then I set the >rectangle to the last value which it had before the scroll changed to non-zero. > >This script should always get executed on "openCard". > >It works fine so long as you don't decide to run it with the screen locked. > >When I lock the screen it seems that the value of the scroll doesn't get updated >correctly and HyperCard runs into a never ending loop. I would guess that some field attributes (like the scroll) are updated when the screen is updated. If the screen is never updated because it is locked, then the scroll never gets updated either. -- Lars-Henrik Eriksson Internet: lhe@sics.se Swedish Institute of Computer Science Phone (intn'l): +46 8 752 15 09 Box 1263 Telefon (nat'l): 08 - 752 15 09 S-164 28 KISTA, SWEDEN
sean@eleazar.dartmouth.edu (Sean P. Nolan) (11/04/89)
In article <TIME.89Nov2171613@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >Look, HyperCard's concept has been around since Ted Nelson. Many years. >(Sorry, Ted) Hypertalk is Basic. Bill had an old idea with the perfect >platform. He did a decent job, but could have done better. You misunderstood. Hypertext has been around for a whole long time, of course. Hypercard is revolutionary because it is the first product to bring the idea to some sort of fruition --- the first commercial application. The entire Macintosh interface was created years before Apple created the Mac, but that doesn't make the Mac any less revolutionary. It brought the technology to the "peeepul." *grin* --- Sean +----------------------------------------------------------------------------+ | Sean P. Nolan | Net: Sean_Nolan@Mac.Dartmouth.EDU | "Let's face it: | | Dartmouth College | | IBM is no fun." | | Hinman Box 2658 | SCALP 'EM! | :::::::::: | | Hanover, NH 03755 | | John C. Dvorak | +----------------------------------------------------------------------------+