"Seamless Tiles Generator 2" updated

[Wilhelm Sanke, FB01]

Stephen Barncard stephenREVOLUTION2 at barncard.com wrote:

>> I would very much like to know what kind of error dialog you get and which
>> operations could not be cancelled.

> as I said, the IDE doesn't like the imbedded substack with the name 
> Answer Dialog.
> The custom dialog just needs another name.  The support code is trivial.

I know.

I use a number of totally customized dialogs - created from scratch - in my
stacks. See the last public version of  the "Imagedata Toolkit"
<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip> and especially my
sample stack "modal dialogs" from 2003
<http://www.sanke.org/Software/CustomModalDialogs.zip>

What I - and we as the MC-user group - have done is to further develop and
improve the answer and ask dialogs, namely 
- to allow placing the dialogs anywhere
- to avoid the truly oversized width of the Rev dialogs.
This is now established standard for the dialogs in the MC IDE.

Two things concerning the Rev IDE are "trivial" here:

You would need only "two" additional script lines in the scripts of the Rev
answer and ask dialogs to achieve the option to "place" the dialogs. Likewise it
would be easy to diminish the disproportional width of the dialogs. The
Revolution team has apparently never paid any attention to such possible and
trivial changes.

And it would be likewise trivial to exempt answer and ask dialogs from the
stack-collision routine in the Rev frontscripts.-

I agree with Jacqueline about much of what she stated in her post of Sun Oct 12
14:09:12 CDT 2008 about the relative merits of both IDEs, but I have the feeling
that her argumentation is somewhat influenced by her double loyalty to
Revolution and Metacard (which I appreciate, and which I also feel to some
degree) - and in that downplaying disadvantages of the Rev IDE that have time
and again been discussed on both lists.

The Rev IDE has much improved over time, but IMHO is still the weakest part of
Revolution. There have been stacks with specific features not long ago that
simply could not be handled by the Rev IDE. The Application Browser would
freeze. Stacks would slow down considerably and become virtually unusable etc.
In the meantime many things have indeed improved, but a number of aspects still
urgently needs further development.

Jacqueline uses the example of the "developer" based on her own experience:

"But if the developer is not 
careful, it is possible to damage the native MC IDE dialogs during 
development." 
and 
"I am working with a stack right now that has 
duplicates like this, and I am seeing lots of misdirection when I have 
my own answer dialog open. It's very important to make sure you supply a 
long stack reference to the copy you really want to save. This isn't 
always obvious to new users."

I would distinguish here between a necessarily careful "developer" who should
know what he is dealing with and who is able to overcome such possible
misdirections and  a "user" who simply wants to use whatever sort of dialog is
provided in a given situation and who does not want to be annoyed by unwarranted
error messages.

To come back to the feedback from Stephen:

> Also the code doesn't recognize "cancel" from file dialogs -- deletes image

> and there is no "cancel" button on a couple of the dialogs.  The 
> dialog for amount of 'tile routine' effect for one.

You are right here. Using "cancel" when importing an image deletes the existing
image. I have already fixed that and will upload a new stack the next days.

I am not so sure about a "cancel" button when choosing a width for the tile
routines. Once you have decided on a tile border routine, why would you want to
cancel selecting one of the width options? And there is the "reset image" button
which can reset the tile image to its original state.
On the other side it surely would not hurt to add a "cancel" option to the
tile-routines dialogs.

So, thanks again for your feedback and appreciation and go on enjoying the stack
if you find the time.

Best regards,

Wilhelm Sanke
<www.sanke.org/MetaMedia>

--------------------------------------------------------
This mail sent through http://www.uni-kassel.de/www-mail