dce@smsc.sony.com (David Elliott) (01/02/90)
Is there a way to tell HyperCard to ignore commands for hiding the menubar and message box? My screen is large enough to not need these to be hidden, and I'd prefer not to go in and hack things like Developer Stack to leave these on the screen. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "But Pee Wee... I don't wanna be the baby!"
face@arizona.edu (Chris "Face" Janton) (01/03/90)
In article <1990Jan2.154142.5638@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: > Is there a way to tell HyperCard to ignore commands for hiding the > menubar and message box? My screen is large enough to not need Here is the code from my Home stack - I can't remember exactly why I did it this way, but it does the trick on hide what if what = "menubar" then put foo into temp else if what is in "234" then put foo into temp else pass hide end if end hide ------------------------------- Chris 'Face' Janton CCIT University of Arizona Tucson, AZ 85721 Phone: +1 602 621-6848
cecala@m2.csc.ti.com (Tony Cecala) (01/04/90)
In article <1990Jan2.154142.5638@smsc.sony.com> dce@smsc.Sony.COM (David Elliott) writes: >Is there a way to tell HyperCard to ignore commands for hiding the >menubar and message box? My screen is large enough to not need >these to be hidden, and I'd prefer not to go in and hack things >like Developer Stack to leave these on the screen. >-- >David Elliott >dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce >(408)944-4073 >"But Pee Wee... I don't wanna be the baby!" Tony Cecala User Interface Designer PO Box 655303, MS 8223, Dallas, TX 75265 Texas Instruments, Inc. Arpanet: cecala@m2.csc.ti.com ------------------------- *I speak for me only*
cecala@m2.csc.ti.com (Tony Cecala) (01/04/90)
In article <104252@ti-csl.csc.ti.com> cecala@m2.csc.ti.com (Tony Cecala) writes: > <Nothing new, I screwed up.> Here's the lost document. In article <1990Jan2.154142.5638@smsc.sony.com> dce@smsc.Sony.COM (David Elliott) writes: >Is there a way to tell HyperCard to ignore commands for hiding the >menubar and message box? My screen is large enough to not need... >-- >David Elliott >dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce David, here's something that you could put in your home stack. It lets you command-shift-m to toggle the message box if it should be hidden somehow. Good luck. on hide w if w="menubar" then put "trapped menubar" into msg else pass hide end hide on domenu w if w="message" and (the shiftKey is up) then put "trapped message" into msg else pass domenu end domenu Tony Cecala User Interface Designer PO Box 655303, MS 8223, Dallas, TX 75265 Texas Instruments, Inc. Arpanet: cecala@m2.csc.ti.com ------------------------- *I speak for me only*
dce@smsc.sony.com (David Elliott) (01/05/90)
In article <1297@amethyst.math.arizona.edu> face@arizona.edu (Chris "Face" Janton) writes: >on hide what > if what = "menubar" then > put foo into temp > else if what is in "234" then > put foo into temp > else > pass hide > end if >end hide All the solutions I got were similar to the above. This brings up a fundamental problem. I get the feeling that I missed something in my reading. Is it the case that any command passes a message that can be trapped for by "on"? I am guessing this because there is no "hide" system message documented. In addition, how does one find the range of arguments sent to these traps? That, why is the message box 4, and what are 2 and 3? BTW, I have the Goodman book, and have decided that this book should win a prize for the world's lousiest index. Is there a good reference book for HyperCard with a really good index? -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "But Pee Wee... I don't wanna be the baby!"
sinton@cantuar.UUCP (Robert J.P. Sinton) (01/18/90)
From article <1990Jan4.200726.6221@smsc.sony.com>, by dce@smsc.sony.com (David Elliott): > This brings up a fundamental problem. I get the feeling that I missed > something in my reading. Is it the case that any command passes a > message that can be trapped for by "on"? I am guessing this because > there is no "hide" system message documented. A while back I tried (just for fun) this card script: on add arg1,arg2,arg3 answer arg1 && "/" && arg2 && "/" && arg3 end add In the message box I typed: put 1 into temp and then: add 1 to temp Imagine my surprise when it worked! the answer dialog gave: 1 / to / <container> I tried for ages to do something like adding 1 to arg1 so that "add 1 to temp" when temp was 1 would result in temp having the value 3. Unfortunately, the third argument is trapped as the string "<container>", rather than a useable reference to the actual container, so the message lost its meaning through being intercepted. Very frustrating, it made me feel that the ability to alter mathematical logic was just beyond my reach :-) ----- Robert -- Internet: sinton@cosc.canterbury.ac.nz Robert J.P. Sinton Telecom: +64 3 667 001 x6367 (MSc student) UUCP: ...!{watmath,munnari,mcvax,vuwcomp}!cantuar!sinton Mail: Comp. Sci. Dept, Univ. of Canterbury, Christchurch, New Zealand
bskendig@phoenix.Princeton.EDU (Brian Kendig) (01/19/90)
In article <1472@cantuar.UUCP> sinton@cantuar.UUCP (Robert J.P. Sinton) writes: > A while back I tried (just for fun) this card script: >on add arg1,arg2,arg3 > answer arg1 && "/" && arg2 && "/" && arg3 >end add > In the message box I typed: >put 1 into temp > and then: >add 1 to temp > Imagine my surprise when it worked! the answer dialog gave: >1 / to / <container> > > I tried for ages to do something like adding 1 to arg1 so that >"add 1 to temp" when temp was 1 would result in temp having the value 3. >Unfortunately, the third argument is trapped as the string "<container>", >rather than a useable reference to the actual container, so the message >lost its meaning through being intercepted. Very frustrating, it made me >feel that the ability to alter mathematical logic was just beyond my reach :-) First of all, having the command `add 1 to arg1' in your `on add' handler would result in an infinite recursion... ;) I've come across that <container> problem before. Seems to me that I once tried to trap the `go' command and take special action for specific destinations, but no matter what I typed after `go', my handler would always receive the message go to <card> which doesn't help much at all unless I really did type `go to <card>' (which I didn't). What's the deal here? Why isn't my card receiveing the same thing that the system must be (or else I couldn't `go' anywhere!)? I can't seem to replicate the problem right now, but I remember working around it clumsily way back when. << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | | Systems Engineering, NASA Space Station Freedom / General Electric WP3 |