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
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to