twakeman@hpcea.CE.HP.COM (Teriann Wakeman) (12/17/87)
Two questions:
(1) When somone aborts a script print command in Hypercard, how can my script
identify that the print command has been aborted so it can carry out script
below the print commands.
The Problem: I want to print a card containing graphics, fields and buttons.
I do not want the buttons to print. My script hides the
buttons, prints the card, then shows the buttons. If the
print command is aborted, the buttons stay hidden.
(2) Background info: I am writing a Hypercard database that consists of
several stacks manipulated from one index stack. I call this a stack
cluster. There are two core stacks in the cluster. One is the index stack
that provides an index of the data along with navigational and editing
functions. The other is a data stack. The other data stacks in the cluster
are optional. Each optional stack is a framework for maintaining certien kinds
of data. It is intended that the user will install only those stacks providing
frameworks for the kinds of data she wishes to keep.
What I want to do: On startup of the index stack, identify which data stacks
are in the cluster.The information will be used to:
A. hide navagational and editing buttons for data stacks not in the
cluster (I consider a data stack to be in the cluster if it is in the same
hierarchical level as the index stack).
B. For a script that will automatically compact all data stacks in the
cluster when exiting the cluster (Sinse the menu bar is hidden, there is
only one normal way to exit the stack cluster).
QUestion: Is there a better way to identify the existance of a stack within
a hierarchical level other then a go to stack command????
If not: if the go to command fails, is there any way to head off
the "where is stack XXX" dialog box?
All I want to do is test for the existance of a stack and put the result in
a hidden field. Any ideas???????
TeriAnn Wakeman
Hewlett-Packard Corp. Quality
HPMUG cooridnator
(415)857-5057cfc@wjh12.harvard.edu (Christopher F. Chabris) (07/16/88)
We have two questions about Hypercard programming. Any assistance with either or both would be appreciated. Thanks. 1. How can one hide the cursor for an indefinite period of time? 2. Is there an XCMD that will wait for the next screen refresh, so that we can display a picture without part of it appearing for an additional 16 milliseconds (one refresh cycle)? -- Chris Chabris cfc@wjh12.harvard.edu
kateley@Apple.COM (Jim Kateley) (07/16/88)
In article <256@wjh12.harvard.edu> cfc@wjh12.UUCP (Christopher F. Chabris) writes: >We have two questions about Hypercard programming. Any assistance with >either or both would be appreciated. Thanks. > >1. How can one hide the cursor for an indefinite period of time? If you are using version 1.2.1 of Hypercard, you can "set the cursor to none". This will only be in effect for the duration of the handler. Setting it in the "on idle" handler just fights Hypercard's desire to set the cursor to what it wants. Jim Kateley UUCP: {sun, voder, nsc, mtxinu, dual}!apple!kateley S,P,HnS! DOMAIN: kateley@apple.COM Applelink: kateley1 Disclaimer: What I say, think, or smell does not reflect any policy or stray thought by Apple Computer, Inc.
benjamin_kuo@pedro.UUCP (Benjamin Kuo) (07/23/88)
>how to hide the cursor for an indefinate period of time
You can either set a script to display a "blank" CURS resource, or have the
script or something type something into a field... (Which automatically
hides the cursor). np@doc.ic.ac.uk (Nigel Perry) (02/16/89)
Two questions:
(a) I've written a handler to modify a script (does addreviation etc.)
and another which goes through a stack applying this to every script.
Problem is it doesn't always work, the code is soemthing like:
set script of this stack to Convert(the script of this stack)
<loop thru each bg>
set script of this bg ...
<loop thru each field and card>
set the script of card/field n to ...
<loop thru each card>
etc.
Sometimes the scripts of the target stacks get set to "Convert(...)"
instead of to the result of the Convert! By changing the lines
which convert stack/card/bg scripts to:
put the script of this stack/cd/bg into tmp
set the script of this ... to Convert(tmp)
and leaving the card/field lines as above the problems seem to go away.
(I have lockRecent/Messages/Screen all set while doing this). Any ideas?
(b) In XCMD/XFCN's is there an official/recommended way of storing globals
between calls to the XMCD? I see "Menus for HyperCard" (code in Dan
Shaffers book) store stuff in the hc msg window stucture.The copy
of Menus I have stores stuff in resources non-purgable in memeory.
I thought of storing data by patching a little used trap (InitPacks?)
to be a jump to the original followed by a handle to my data.
Ideas, recommendations anybody?
Thanks in advance. Nigel.
---
Nigel Perry Department of Computing
Imperial College
Janet: np@uk.ac.ic.doc London
DARPA: np%uk.ac.ic.doc@ucl-cs SW7
Uucp: np@icdoc.UUCP, ukc!icdoc!np Englandanson@spray.CalComp.COM (Ed Anson) (02/21/89)
In article <685@gould.doc.ic.ac.uk> np@doc.ic.ac.uk (Nigel Perry) writes: >(b) In XCMD/XFCN's is there an official/recommended way of storing globals >between calls to the XMCD? I see "Menus for HyperCard" (code in Dan >Shaffers book) store stuff in the hc msg window stucture.The copy >of Menus I have stores stuff in resources non-purgable in memeory. >I thought of storing data by patching a little used trap (InitPacks?) >to be a jump to the original followed by a handle to my data. The OFFICIAL way to store globals is to convert the data to text and store it in a HyperCard global. HyperCard provides call-backs for the purpose. Personally, I don't like that idea, since it can be a major performance problem, not to mention a pain in the ... You CAN store stuff in non-purgeable resources. But there are some severe drawbacks. The most serious is that HyperCard closes your current resource file (the stack) when you move to another stack. The resource may or may not be in the file when you come back, and if it is, it may or may not be valid data. Your idea of patching a trap may be on the right track. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
mikael@sm.luth.se (Mikael Eriksson) (02/22/89)
In article <2600@spray.CalComp.COM> anson@spray.UUCP (Ed Anson) writes: >In article <685@gould.doc.ic.ac.uk> np@doc.ic.ac.uk (Nigel Perry) writes: > >>(b) In XCMD/XFCN's is there an official/recommended way of storing globals >>between calls to the XMCD? > >The OFFICIAL way to store globals is to convert the data to text and store >it in a HyperCard global. HyperCard provides call-backs for the purpose. > >Personally, I don't like that idea, since it can be a major performance >problem, not to mention a pain in the ... Another approved way to do this is to have a Handle to the data. (At least it was recommended by the Apple reps here in Sweden.) To save it just convert the *Handle* to text (with NumToHex for example) and save the text in a global. To retrieve the data do a StuffHex. Example: (In TML Pascal) const globalName ='MyHCGlobal'; var saveThis: Handle; globalString: Str255; (* Help routines *) procedure PasSetGlobal(paramPtr:XCMDPtr; name,value: Str255); (* Set global name to value *) var hndl: Handle; begin hndl:=PasToZero(paramPtr,value); SetGlobal(paramPtr,name,hndl); DisposHandle(hndl); end; function PasGetGlobal(paramPtr:XCMDPtr; name:Str255):Str255; (* Return the value of global name *) var hndl: Handle; str: Str255; begin hndl:=GetGlobal(paramPtr,name); ZeroToPas(paramPtr,hndl^,str); PasGetGlobal:=str; DisposHandle(hndl); end; (* To save the data *) PasSetGlobal(paramPtr,globalName,NumToHex(paramPtr,ORD(saveThis),8)); (* To retreive the data *) globalString := PasGetGlobal(paramPtr,globalName); if length(globalString)=8 then begin StuffHex(@saveThis,globalString); ... end else error; -- Mikael Eriksson (Email: mikael@sm.luth.se) ......... You are in error. 2+2=5 Thank you for your cooperation. The Computer.