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 _______________________________________________ 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
