luke@ (Luke Whitaker) (07/31/89)
I have a problem that seems very trivial but I can't figure out. I want to set userLevel to 1 when my stack starts up. Sounds simple. I tried putting a "set userLevel" command in the "openStack" handler, and that's fine if my stack is started from another stack. However, if it is double clicked from the finder, then my openStack routine gets called, and THEN startup gets called, which goes all the way to the home stack and resets the userLevel to whatever is in the user preferences card. I could handle startup myself, but that doesn't seem very friendly if the user has added some extras, possibly including xcmds to his/her home stack. Am I looking at this the right way or maybe I shouldn't worry about the users own specials as far as my stack is concerned --- after all, I wan't to override the userLevel. Incidently, I can't protect the stack at level 1 because I need to manipulate the userLevel within the script myself. Sorry if this has been covered before. Mail me and I will summarise. Luke Whitaker, Computer Science, City University, London, EC1V OHB, England. JANET: l.whitaker@uk.ac.city.cs BITNET: l.whitaker%uk.ac.city.cs@ac.uk ARPA: l.whitaker@cs.city.ac.uk (or l.whitaker%uk.ac.city.cs@nss.cs.ucl.ac.uk) Uucp: ...!mcvax!ukc!citycs!luke (or luke@citycs.uucp)
bskendig@phoenix.Princeton.EDU (Brian Kendig) (08/02/89)
In article <113@citycs.UUCP> luke@ (Luke Whitaker) writes: >I have a problem that seems very trivial but I can't figure out. I want to >set userLevel to 1 when my stack starts up. Sounds simple. I tried putting >a "set userLevel" command in the "openStack" handler, and that's fine if my >stack is started from another stack. > >However, if it is double clicked from the finder, then my openStack routine >gets called, and THEN startup gets called, which goes all the way to the home >stack and resets the userLevel to whatever is in the user preferences card. If the person who uses the stack knows how to change the userLevel in the User Preferences card of the home stack, and if he actually felt like doing so, then he probably is intelligent enough to go through your stack without mucking it up terribly. You should assume that if he changed the userLevel to a level higher than "Browsing", he had a reason for doing so. If you still feel like being safe, however, there are two ways to go about keeping the userLevel at 1. You could simply do on idle set the userLevel to 1 end idle Blunt, but effective; unfortunately, you'd never be able to leave that level until you left the stack. For your own benefit you might change that command to 'if the commandKey is down then set the userLevel to 5 else set the userLevel to 1'. It's up to you. If you wanted to get tricky, you could try putting this in your stack script: on startUp send 'startUp' to first card of home set the userLevel to 1 end startUp This script should trap the startUp message, pretend to take care of it normally, but then set the userLevel correctly just before it exits. It should work as advertised, but since I don't have Multicrasher running on my 1M Mac, I can't test it right now. Good luck! >Luke Whitaker, Computer Science, City University, London, EC1V OHB, England. >JANET: l.whitaker@uk.ac.city.cs BITNET: l.whitaker%uk.ac.city.cs@ac.uk >ARPA: l.whitaker@cs.city.ac.uk (or l.whitaker%uk.ac.city.cs@nss.cs.ucl.ac.uk) >Uucp: ...!mcvax!ukc!citycs!luke (or luke@citycs.uucp) -- | Brian S. Kendig | I feel more like I | bskendig | | Computer Engineering | did when I got here | @phoenix.Princeton.EDU | | Princeton University | than I do now. | @PUCC.BITNET | | Systems Engineering, NASA Space Station Freedom / General Electric WP3 |
englandr@phoenix.Princeton.EDU (Scott Englander) (08/03/89)
I had to do this exact thing myself. Someone out in NetLand gave me the
basis for this stack script:
on initlevel
global savelevel, initflag
if the version < 1.2 then
answer "Please upgrade to HyperCard version 1.2 or greater" B
with "Cancel"
go home
else
put true into initflag
if the userlevel is not 2 then
push recent card
hide message window
set lockscreen to true
set lockmessages to true
push this card
go to card "User Preferences" of stack "Home"
put card field "User Level" into savelevel
-- closestack resets userlevel
setUserLevel 2 -- typing only
go to first card
pop card
end if
set lockmessages to false
set lockscreen to false
go to first card
set the cursor to 4 -- watch
set lockscreen to true
--
-- program variables are initialized here
--
end if
end initlevel
on StartUp
-- executed if launched from the Finder
initlevel
pass StartUp
end StartUp
on openstack
global initflag
if initflag is not true then initlevel
end openstack
on closestack
global savelevel, initflag
put empty into initflag
set lockscreen to true
set lockmessages to true
set userlevel to 5
domenu "compact stack"
set lockscreen to true
set lockmessages to true
push this card
go to card "User Preferences" of stack "Home"
setUserLevel savelevel
pop card
set lockmessages to false
set lockscreen to false
end closestack
================
Hope this helps!
p.s. I posted it rather than mailed it, as i thought it would be of
general interest.
--
- Scottsirkm@ssyx.ucsc.edu (Greg Anderson) (08/04/89)
In article <9719@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >If the person who uses the stack knows how to change the userLevel in the >User Preferences card of the home stack, and if he actually felt like doing >so, then he probably is intelligent enough to go through your stack without >mucking it up terribly. You should assume that if he changed the userLevel >to a level higher than "Browsing", he had a reason for doing so. Hear hear! Huzzah the gentleman who leaves the userLevel well enough alone! >If you still feel like being safe, however, there are two ways to go about >keeping the userLevel at 1. You could simply do > > on idle > set the userLevel to 1 > end idle No! That's evil! It's bad enough when a stack changes the userLevel on openstack. I _hate_ having to type "set the userlevel to 5" in the message box, ESPECIALLY when the stack in question is in the public domain and contains things that would be useful in other stacks. One particular stack that committed such a sin (no names, please!) contained XCMDs that could be copied, but the stack was protected (userLevel was set to one), so I couldn't look at the scripts that called the XCMDs in the example! After that, I learned about the "set userLevel" command and started the Coalition to Stop the Unnecessary Change of the UserLevel. >Blunt, but effective; unfortunately, you'd never be able to leave that level >until you left the stack. Even if you change the userLevel to 1 in an idle handler, CSUCU can still break into your stack. From the home stack (where userLevel is safely set to scripting), type: edit script of stack "foo" You will find that you can edit stack foo before the userLevel is set to one. Just find all references to "set userLevel" and remove them. Particularly evil stacks might have idle handlers on cards or in backgrounds, but we won't contemplate those for now. (Do buttons and fields get idle messages? Shudder.) There's always the "searchScript" command... >| Brian S. Kendig | I feel more like I | bskendig | >| Computer Engineering | did when I got here | @phoenix.Princeton.EDU | >| Princeton University | than I do now. | @PUCC.BITNET | >| Systems Engineering, NASA Space Station Freedom / General Electric WP3 | ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
sirkm@ssyx.ucsc.edu (Greg Anderson) (08/04/89)
In article <9734@phoenix.Princeton.EDU> englandr@phoenix.Princeton.EDU (Scott Englander) writes: >I had to do this exact thing myself. Someone out in NetLand gave me the >basis for this stack script: > > <extraordinarily complex and unnecessry script deleted> > >p.s. I posted it rather than mailed it, as i thought it would be of >general interest. >-- > > - Scott It is indeed interesting that anyone would go to so much work to do something so unnecessary. Changing the userLevel is bad enough -- actually going in and changing the home stack is quite beyond words. At least you changed it back afterwards. :) ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
ollef@sics.se (Olle Furberg) (08/06/89)
In article <8622@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >In article <9719@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >>...keeping the userLevel at 1. You could simply do.... ... >No! That's evil! It's bad enough when a stack changes the userLevel on >openstack. I _hate_ having to type "set the userlevel to 5" in the message >box, ESPECIALLY when the stack in question is in the public domain and >contains things that would be useful in other stacks. It's against Apple user interface guidelines to change anything without kind permission of the user (that's why programs have alert dialogs). An even more disgusting thing is all these hidings of the menubar: DON'T HIDE THE MENUBAR IN THE SCRIPT!!!!! If HyperCard crashes with the menubar hidden, I must reboot my Mac to get it back in any other program (including Finder). Hiding the menubar is not recommended by the interface guidelines: the menubar and the mouse is the two most important things in the Mac interface. Think of what happens if you get a mouse-freeze or the menubar isn't available? The only way out is one of the small buttons to the left of your Mac! The same goes for utilities like the setcursor XCMD: the mouse/cursor belongs to the user and should not be moved by any script!! Its OK to ad your own menus to the menubar by using some XCMDs. That's the best way to show the user what choices could be made without clogging up the screen. However, adding your own menus without changing the userlevel, might be complicated: on a Plus/SE-screen there's not much room for a new menu esp. when you are paint-mode. /Olle
sirkm@ssyx.ucsc.edu (Greg Anderson) (08/08/89)
In article <1989Aug6.001759.23338@sics.se> ollef@sics.se (Olle Furberg) writes: >It's against Apple user interface guidelines to change anything without >kind permission of the user (that's why programs have alert dialogs). > >An even more disgusting thing is all these hidings of the menubar: >DON'T HIDE THE MENUBAR IN THE SCRIPT!!!!! Well said. (Same goes with your other comments that I cut.) >Its OK to ad your own menus to the menubar by using some XCMDs. That's the >best way to show the user what choices could be made without clogging up the >screen. However, adding your own menus without changing the userlevel, might >be complicated: on a Plus/SE-screen there's not much room for a new menu >esp. when you are paint-mode. If the user is in paint mode, he probably doesn't want to use your custom menus anyway. Most stacks should be able to add enough (two or three) menus with "File Edit Go Tools Objects" showing (i.e., the user is in scripting mode). In the few instances where more than three menus are needed, it would be okay to change the userlevel to browsing if one of the menus had an option to return to scripting mode. However, I would tend to question any stack that used so many menus. I can think of instances where such an interface would be desirable, but before you go and throw up five custom menu items, first ask yourself if the same thing could not be done with buttons on an index card. > > > /Olle ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
englandr@phoenix.Princeton.EDU (Scott Englander) (08/08/89)
In article <8622@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) flames: >No! That's evil! It's bad enough when a stack changes the userLevel on >openstack. I _hate_ having to type "set the userlevel to 5" in the message >box, ESPECIALLY when the stack in question is in the public domain and >contains things that would be useful in other stacks. Thanks for your opinion, but how about considering that some of us might have a *legitimate* need to set the user level. And that's what this newsgroup is all about: sharing information and avoiding having to reinvent the wheel. Generalizing that such and such is "evil," when you haven't even seen the application in question, is flaunting ignorance, and gets in the way of this exchange of ideas. Anyway, if you're really a power user, and an aspect of someone's stack that you use frequently bothers you, just change it (once and for all)! The "set userlevel" command was included in the language because there is a need for it. -- - Scott
dfitzwat@pnet51.cts.com (Don Fitzwater) (08/09/89)
Interesting.
Danny Goodman makes a valid point re: HC and the interface guidelines, when he
suggests that, indeed, sometimes you MUST hide the menu bar when the commands
that are displayed have nothing to do with your stack's operation. It is far
more confusing to a user to see a menu item that he or she can pick that does
nothing. Remeber that (ideally) you are designing your stack for an end user
that you have no idea of how HyperCard literate (or Mac literate for that
matter) they are. I think messing with the userlevel is naughty and would
rather see the menubar hidden than have the stack set my userlevel to 2 or 3
(or 1 goodness sakes!).
UUCP: {amdahl!bungia, uunet!rosevax, chinet, killer}!orbit!pnet51!dfitzwat
ARPA: crash!orbit!pnet51!dfitzwat@nosc.mil
INET: dfitzwat@pnet51.cts.comgeoff@pmafire.UUCP (Geoff Allen) (08/10/89)
In article <835@orbit.UUCP> dfitzwat@pnet51.cts.com (Don Fitzwater) writes: >Interesting. >Danny Goodman makes a valid point re: HC and the interface guidelines, when he >suggests that, indeed, sometimes you MUST hide the menu bar when the commands >that are displayed have nothing to do with your stack's operation. It is far >more confusing to a user to see a menu item that he or she can pick that does >nothing. Remeber that (ideally) you are designing your stack for an end user >that you have no idea of how HyperCard literate (or Mac literate for that >matter) they are. I think messing with the userlevel is naughty and would >rather see the menubar hidden than have the stack set my userlevel to 2 or 3 >(or 1 goodness sakes!). I agree! I'm currently building a stack for *myself*, and I'm hiding the menubar, so it won't be in the way. For my application, nothing on the menubar is really needed, and I like the extra space and 'slicker' look of the screen without a menubar. Plus, if the user really wants the menubar, he (or she) can just type <command>-m (to show the message box) and type 'show menubar.' Count this as another vote for hiding the menubar and leaving the userlevel alone. -- Geoff Allen - WINCO Computer Process Engineering ------------------------------------------------------------------------------ ...{uunet|bigtex}!pmafire!geoff | Disclaimer: WINCO doesn't believe in Macs, ...ucdavis!egg-id!pmafire!geoff | so of course these are my own views.
bayes@hpislx.HP.COM (Scott Bayes) (08/15/89)
In the best traditions of keeping it understandable, give 'em a button that brings up or puts away the menubar. Don't expect 'em to know how to use the message box and HyperTalk to do this. Scott Bayes