Creating objects INTERACTIVELY in grous (was "StripeList...")

[Richard Gaskin]

Lynch, Jonathan wrote:
>>"But in the meantime, while we lobby RunRev to first 
>>address things that can't be done in script at all 
>>(like... ...the ability to interactively create objects 
>>within groups)"
>
> Unless I misunderstand the meaning of this, I thought this was already
> an ability. I have programs that do this frequently. I am sure I am just
> misunderstanding - but if you don't mind, please clarify, just to help
> me understand the limits of what we can do.

You can turn on the editBg, which hides the group's scrollbars and 
everything not inside the group.

And you can create an object via script, with:

    create btn "MyBtn" in group "MyGroup"

But what I'm looking for is the ability to make a standard drawing 
environment, something like the old SampleDraw program that shipped with 
SuperCard, a simple MacDraw-like app.

Central to such an app is the ability to INTERACTIVELY create objects 
within the scrolling pane, using the conventions we've used in similar 
apps since the earliest days of Mac OS:

1. Select a tool from a tool palette
2. Drag out the shape within the scrolling pane

The closest workaround I've found yet is to allow the user to create the 
object, which is done on TOP of the group, and on newGraphic you clone 
it into the background and delete the original.  This has a very 
disconcerting appearance as the object first appears on TOP of 
scrollbars and any other non-group objects in the window, and is 
potentially problematic as it could allow an object to be created 
outside of the scrolling region such that when it's copied into the 
group it's outside of the pane bounds.

Because Rev has greater flexibility with its scrolling groups than 
SuperCard does with its scrolling windows, we should be able to have a 
much broader range of design options, including having a tool set in the 
margin of the window outside of the scrolling region, a la FileMaker or 
Claris Works etc.

After much discussion with Scott Raney, Ken Ray, Tuviah, and others over 
a period spanning two years, we've collectively agreed that the ultimate 
solution would be to implement tool modes on a per-group basis, so that 
you could say:

   set the tool of grp "DrawingPane" to "graphic tool"

....and only that group has that tool active when the mouse is within 
it; all others remain in the default "browse tool" mode.

This has been requested as Bugzilla item #623:
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=623>


There is an error in the original report there, caused by a misleading 
phrase in the documentation.  The original report suggests that this 
feature would be an extension to groups of a feature currently in place 
which allows tools to be set on a per-stack basis.  This feature does 
not actually exist; tool modes in Rev are currently always global.

This misunderstanding is due to an unusual definition of "compatibility" 
used to describe a number of stub routines in the engine, routines which 
allow certain syntax to be interpreted without error even though they 
have no effect.  There are a number of these implemented to avoid script 
errors for works ported from HyperCard and SuperCard, such as "set the 
userlevel to 4"; it has no effect, but also does not generate an error. 
  Same with allowing "set the tool of window 'MyWindow' to 'pointer 
tool'", which is valid syntax in SuperCard but does nothing in Revolution.

Such stub routines are marked in the docs as "implemented for 
SuperCard/HyperCard compatibility".  This phrasing was initiated by Dr. 
Raney, who in most cases I agree with but on this one I differ.

That such syntax is supported to the degree that it doesn't trigger a 
script error is, in most cases, recognized as very valuable for porting, 
since most of the time the behavior has little or no effect on the 
program's flow.

However, in some cases it can also be misleading:  if an expected 
behavior isn't present and no script error is generated, the developer 
may falsely believe that the absence of the behavior may be related to 
something she did.

If a token is not implemented as it was in the program it was originally 
defined in, I believe it doesn't meet the definition of "compatible" and 
another word is needed to denote that it's merely stubbed.

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev