englandr@phoenix.Princeton.EDU (Scott Englander) (04/01/89)
Spreadsheet-like fields! I second that. Just spent HOURS working on a
stack moving all those little identical fields around, and writing the
code to reference their names. Perhaps a way to reference cells would
be like an array:
put field table[3,4]
You get the idea. Other items:
Grouping of objects (fields, buttons). I ALWAYS want to move lots of
stuff together when arranging a card.
Records (a la Pascal). I suppose i could kluge it by assigning globals
to item numbers and then referring to "item [fieldname] of [recordname]"
but this gets cumbersome.
Search and replace while editing scripts. Or at least the ability to
use McSink to do this without having to press OK first and then get
back into it after using McSink.
The ability to change a field's number from within the field info dialog
box. Right now, you have to choose the field tool, select the field,
choose "bring closer," double-click on the field to see what number it
changed to in the dialog box. This is important, because field number
determines tabbing order, and to move one from 38 to 10 requires
executing the above sequence many times (it doesn't always move closer
or farther each time).
Many more, can't think of them now.
--
- Scottbayes@hpfcdc.HP.COM (Scott Bayes) (04/04/89)
>Records (a la Pascal). I suppose i could kluge it by assigning globals >to item numbers and then referring to "item [fieldname] of [recordname]" >but this gets cumbersome. This strikes as a case where user-definable objects would be a useful general tool in which to implement a particular need. We have only 5(?) object classes now: button field card bkgnd stack. What about some "new" messages: put "subfield: nameField, dateField" into classInfo new class record classInfo --defines class "record", described by classInfo new record myRecord --works like "new button" menu item, etc. creates --new object of class record, named "myrecord" put "Scott" into subfield "nameField" of record myRecord --"subfield" could be --optional --and, put "on mouseUp" & return & "put empty into subfield" && quote & "nameField" & quote && "of me" & return & "end mouseup" into the script of myRecord --and, set the icon of myRecord to 1124 --whatever You'd need an "object tool" with which to manipulate these beauties if you give them a full iconic/graphic HyperCard type interface, else you could only manipulate them "scryptically" :-) I have no full definition for the language in which classInfo might be described. The above is just a limited example. Defining subcontainer names (the "subfield" stuff above) may not be the only thing to be done in a class definition. Objects "for the rest of us"??!??! Scott (not the Scott who posted the included text) Bayes
englandr@phoenix.Princeton.EDU (Scott Englander) (04/05/89)
Thought of another one:
Accessing all the contents of one background field as one container,
i.e. on all cards. I've had numerous occasions to do something like
put fielditem item_no of field "name" into cur_name
(where item_no is either a card number or id; this puts the contents of
field "name" on that card into cur_name)
or
write allfield "name" to file "namedata"
(writes records to the file, one for each card)
The problem with the way it is now is that you have to keep track of the
card IDs where particular pieces of data are stored, and then go to that
card to get the data. This is cumbersome script-wise, and
time-consuming (unless you have a 68030). Maybe what i really need is a
RDBMS!
****************
I'm now working on a stack that partially involves using HC as a front
end for Cricket Graph. (or rather Cricket as a way to graph the data in
the stack, with minimal effort). I have it make use of Macromaker to
get to CG and do the plots. Macromaker is extremely fragile, though,
and if anything changes since you recorded the macro (like icons got
moved around on the desktop), it breaks, and you have to record the
whole thing over. I've been able to overcome some of this by
modularizing the macros, so one calls another by keystroke, but the
result is hardly the idiot-proof product i want to leave with the user,
and is also not exportable -- macros must be recorded on the user's
machine in order to work right.
It would be great if HyperCard could serve as a _true_ front end for
applications, allowing you to send mouseups to buttons in dialogs and do
"domenu"s, etc.
--
- Scottfry@brauer.harvard.edu (David Fry) (04/05/89)
In article <7574@phoenix.Princeton.EDU> englandr@phoenix.Princeton.EDU (Scott Englander) writes: >It would be great if HyperCard could serve as a _true_ front end for >applications, allowing you to send mouseups to buttons in dialogs and do >"domenu"s, etc. See the April 4th MacWeek. As previously reported, Apple is working on a system of inter-application communications based on HyperTalk. HT would be an integral part of the Mac system, and you could send scripts from one program to another. You may soon get your wish! David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138