Re-execute a card ?

[kevin11]

Apologies for this question, can't find the answer in documentation or sample scripts.

I'm currently evaluating a trial livecode, to make sure it can do the things I want, and it seems the answer is a resounding yes (and so easily and quickly too) !

but...........

I have a card, say, card "A", that does :

onpreopencard
do stuff based on some global variables
end

on opencard
do stuff n things, and set up links that go to card B, or card C, etc, depending on some global variables
end onopencard

and finally,
on linkclicked
change some global variables
go to card A, or B, or C or whatever

This works fine, but the problem is, for some of the links what I want is for the current card "A" to "reload", and do all the preopen and onopencard stuff, but using the new global variable values. Seems that this doesn't happen, as if you already have the card visible, you can't force a preopen and onopen (or can you ?)

which means the solution is for me to convert the the preopen and onopen stuff to functions and/or commands, and the onclicked section then to repeat these functions/commands to repopulate the card when a link to A is clicked. However, this seems to me to require a degree of duplication, and when I was first tought programming I was told this was a no-no, as it wasted punched cards. And nowadays obviously this also violates my human rights (the Right to an Easy Life).

So is there a better way of doing this ? A sort of "Here's a click and I know you are open but pretend you aren't and just do it your preopen and onopen all over again with these new global values"

[dunbarx]

Hi.

Though the engine sends these messages automatically upon the event, you must read up on the "send" command. You can:

send "preOpenCard" to this card

or

send "openCard" to card "B"

Wirte back often.

Craig Newman

[kevin11]

Thanks.

That's what I have tried - to send a preopen card to the card already open. The preopen card code doesn't execute.

So, I did a little test card, and you are perfectly correct. Which of course sent me scuttling back to my code, to find I was sending the preopen from within a switch block that didn't itself get executed. doh !

Thanks for your reply - it is much appreciated as it sent me back to fix my code instead of allowing me to waste time finding a workaround.

(so where's the Auto Bug-Removal button then ?)

[Regulae]

Hi there,

I'd like to join others who have welcomed you to the forum. Your idea for an Auto Bug-Removal button is excellent, something well worth raising in the "Feature Requests" section of the forum.

Regards,

Michael

[mwieder]

(so where's the Auto Bug-Removal button then ?)

<g>

I actually thought about that one along the way to writing PowerDebug http://www.ahsoftware.net/PowerTools/Po ... DDemo.html. Here's the scenario: there are quite a few bugs that trip up the compiler and they're simple to fix up, so if the debugger can report them to you, why shouldn't it be able to fix up the script errors and continue compiling? Should just be automatic and why make the developer go through the extra steps of getting the error message, fixing the error, and trying again?

It's easy enough to catch certain kinds of errors in the errorDialog handler, and in general you have all the information you need to fix the errors transparently without bothering the developer with trivial things.

It turns out that the problem is more social engineering than technical issue. The compiler might have found a valid issue to fix up, but it might also turn out that you had a typo in your code and really meant something else. An automatic change in your script would actually make the underlying bug harder to find by converting the code into something else.

[kevin11]

It would indeed be difficult for some things to be fixed, but the solution is simply to replace the "Auto Bug-Removal" button with the "Clever Auto Bug-Removal" button. To be user-friendly, such a button is best placed next to the "Make a nice App" button.

[Regulae]

Hi there,

Excuse my being pedantic, but your proposal introduces some design redundancy. Given that an App can scarcely be considered nice unless it's bug-free, surely the script of the "Make a nice App" button would simply include a CleverAutoBugRemoval handler, removing the need for the separate button? You could then replace the two buttons with one large one, maximising usability in accord with Fitt's Law. Just a suggestion.

Regards,

Michael

[dunbarx]

This thread is becoming silly. Why the need for a button? Just build that functionality into the engine itself.

Done.

Sheesh.

[mwieder]

The engine's already smarter than I am. At least with a button I can dumb the code down to my level.