Erik Hansen wrote:
--- Dan Shafer <[EMAIL PROTECTED]>
wrote:
Actually, I suspect that for your app to
contain drawing tools, it's
going to have to create a palette of its own
and manage the process
inside your application. The Rev IDE tools only
operate within the IDE
as far as I know.
has this been done?
is there a plugin for sale?
Once upon a time I started down the road of making a universal drawing
tool palette, but in the real world I've found that each app requires
something a little different, so I'm not sure it can usefully be done as
a one-size-fits-all. And then there's the question of how to handle
the other properties (line size, fill/back color/pattern, etc.) -- in
the same palette a la FileMaker, or in a separate palette that eats up a
ton of screen space a la Flash. Decisions, decisions....
Fortunately it's not too difficult to slap one together from scratch
when you need it; mildly tedious if you do it more than once, but if you
make enough of them it becomes second nature after a while.
There have been only three things that were tricky for me to get my head
around first time out:
1. The various graphic primitives are governed by the style property,
while everything else is governed by the tool global property (pointer
tool, graphic tool, etc.). So while you "set the tool to pointer" to
engage the pointer tool, for graphics you first "set the style of the
templateGraphic to <style>", and then "choose graphic tool".
2. Since palettes are not in the message path for things outside of
their own stack, it can be helpful to have the palette insert a
frontScript to trap the newTool message so it can update its UI whenever
the current tool mode changes. While this isn't so important as long as
your palette is the only way to change tools, it can be handy for
working with other tools, or even within the IDE, so that its UI will
always accurately reflect the current tool.
If you'll have more than 10 tools with frontscripts active in your app,
given the limit on the number of frontScripts your app can have at
runtime you may want to set up a dispatcher like the one Rev uses for
plugins. I don't see much sense in setting up redundant messages just
for plugins, since those only run in the IDE where there is no limit to
the number of frontscripts. But for handling lots of tools in a
standalone it can be helpful.
3. Neither the Rev nor the MC IDE pass all mouse messages when the
pointer tool is active. This is reasonable, given that you'd rarely
want to take the same action on a mouseUp with the pointer tool as you
would with the browse tool. But it does make it impossible to
adequately test some things in a custom drawing environment without
first removing the IDE frontScripts that handle those messages -- not
for the faint of heart.
SuperCard provides an a solution to this with a parallel set of messages
exclusively for use with the pointer tool. So instead of "mousedown"
and "mouseUp" as you get with the browse tool, with the pointer tool
active in SC you get "pointerDown" and "pointerUp".
That's been requested in
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=2606>.
In the meantime, you can make a plugin to help during development which
removes and re-inserts Rev's frontscripts as needed if you need to work
with mouse messages while the pointer tool is active.
And those issues don't include the other two caveats of working with the
pointer tool that I alluded to earlier in my references to BZ#s 623 and 624.
BZ#624 is simply a request to subclass the object handle management to
allow more conventional behavior for line objects, and to allow
interactive resizing of polygon points. SuperCard, RADBuilder, and OMO
did this, and it would be nice if Rev went along with the convention
long established by those other xTalks (not to mention MacDraw,
Omnigraffle, Word, and most other programs that provide the same graphic
primitives).
BZ#623 is a request to outdo SuperCard in one area where SC really
shines right now, and has for years: In SC the tool is a property of
the window, not global as in HC and Rev. This lets you establish one
stack as a canvas, and all other stacks retain their browse tool mode.
If you set the style of all other windows to either palette or modeless
you can work around that, but sometimes that's not so simple to do if
you need to update your menus or other UI elements based on the
frontmost window, since the topstack will return the first stack of the
lowest mode, which may or may not be the one in front. Not impossible,
just more tedious than having window-specific tool modes.
BZ#623 takes this SC convention one step further, requesting that groups
have their own tool mode. This would allow something that can't be done
in SC at all: have your tool palette embedded as a toolbar right in the
document window, as in FileMaker Pro or MacDraw. There are usability
arguments going each way, some for palettes and some for an embedded
toolbar, but regardless of what may be theoretically "best" it'd be nice
to have the option. You can do it today with very careful use of the
cantSelect property but it's a lot of work to do it that way, and
riddled with pitfalls.
Ah, but how nice it would be to simply say:
set the tool of grp "Canvas" to pointer
PS - a modest rant about "compatibility" notes in the docs:
The docs note the syntax for the tool property as:
set the tool [of stack] to toolName
Older versions of the MetaCard docs noted that that the option of
specifying a stack was added "for compatibility with SuperCard".
Unfortunately neither is accurate.
While it's true that using the optional stack specifier doesn't bring
the engine crashing to its knees, neither does it do what one would
expect, namely setting the tool mode of only the specified stack, which
is what happens in SuperCard.
Instead, what happens is merely the same as "choose <tool>", making the
specified tool globally active for all toplevel windows.
That's so not what happens in SuperCard that I would be reluctant to
call it compatible. The absence of a script error is not the same as
compatibility, and in this case it may be a greater disservice than
simply flagging any such imported syntax as an error that needs to be
addressed. Chances are you'll want to redesign any imported SuperCard
drawing stuff to accommodate this significant difference, but without a
script error you're left to wonder why it doesn't work as described.
That's "compatibility" in the same way that FEMA provides "emergency
management". :)
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
