LiveCode Forums.

I the midst of a radical re-editing of a rather complicated program,(www.phenomenalog.dk) moving handlers from one version to another, and up and down in the long substack script, I have brought myself into a desperate situation, because the sequence of handlers p.t.seem to conflict with the logical queue of messages.

With app 2400 lines of script, organizing the integration of 20 other substacks - and my very limited understanding of the details, I need a simple method to re-order the sequence of handlers.

Maybe their exists an application, which can solve the problem, or at least some rule of thumb to follow,step by step ?

I am using the LC community version 7.1 - and I notice, that in spite of getting a "no errors occured" when I save the last sequence, only 7 of the handlers are visible in the handler-list on the left-

Still an optimist
Kresten Bjerg

Hi Kresten,
Are you looking to reorder the handlers in the editor or their firing order?

Tom

Thanks for your reply
I am unsure of the meaning of firing-order Basically: I want the handlers brought into a sequence where they can use what they need from each other. And I know that such sequence of these handlers has been working. I just messed it up, trying to solve one little bug in a "function weekNumISO".
With sequence i just refer to the sequence of lines in the stack-script, the order of handlers from the first pre-open stack, open stack etc etc, and global variables are established.
I am open to sharing the script, if need be.
Best regards
Kresten

Hi Kresten,
I'm still a little confused. Custom handlers, command and functions usually lie outside the preOpenStack and openStack handlers and are then called as needed from inside preOpenStack and openStack handlers. So their order in the stack script is unimportant. Perhaps sharing a bit of your code would help.

Hi,

There is no "firing order" in LC, at least among handlers (of any kind) within a single script. It is indeed important, however, where you declare both global and script local variables. These are generally most safely and most usefuly placed at the top of the script. But beyond that there are no rules, and no constraints. It is important to know that if two handlers have the same name, only the topmost one will fire at all, the others being ignored.

And of course it is critical that the message hierarchy be carefully structured for robustness and universality. Thus it is dangerous to move handlers from one level of that hierarchy to another without careful consideration.

That you are having issues is both odd and worrisome. Can you give an example of a particular issue you are seeing?

Craig Newman

Unlike some other languages, the physical order of handlers in a script is irrelevant. They can be anywhere in the script. The only thing where order matters is the placement of global and local variable declarations, which need to be declared above any handler that uses them. For that reason they are usually placed at the top of the script above everything else.

Yes Craig, I know there is no firing order in LC. I wasn't sure if Kresten knew that. But the only way I know how to determine the problem is by asking questions.

Kresten,
Another reason a handler might not show in the tree is because it contains an error and isn't properly compiled.

Kresten

If some of your handlers no longer appear in the 'handler-list on the left' then something is wrong - I should think it's fixable, but until you see all the handlers you have in the 'handler-list' then your app will not be happy.

Things to look out for are 'clean' copy and pasting of handlers - did you by any chance only copy and paste part of handler (perhaps leaving an orphan 'end handlername' line in the old position? Check through all your script making sure that each handler does not contain extra 'end handlername' lines or is missing one.

One other thing to watch out for when pasting into the script editor is to make sure all quotation marks are nice and plain - curly quotes cause trouble and should be changed immediately to plain ones!

kresten wrote: - and I notice, that in spite of getting a "no errors occured" when I save the last sequence, only 7 of the handlers are visible in the handler-list on the left-

Let us know how you get on

Dave

If a script contains multiple handlers of the same name only the first will be shown in the handler list.

Thank you for the warnings and help to debug.
As I suceeded in resurrecting an old version, from which I have copied text of handlers (via word) I have reached a situation where now 38 of 66 handlers are visible in the list. Essential handlers do have same globals declared as in old version, but still dosnt appear in the list, and as they are called, directly or indirectly from the stack , returns the error: "Handler can't be found".
I had the hypothesis that empty scriptlines in or between handlers might cause trouble, so I have controlled for that, with no improvement.
During the experiments I have also approached the question of missing globals,and have "analyzed" som handlers and added variables addressed from the handler script as globals, not aware, that they might be only local. Can that have contributed to the mess ? And if so: how can I repair - i have no record of which handlers undervent such treatment.
I certainly appreciate this forum and the support it - and you - offers to a lonely old researcher-
still optimist
Kresten

from which I have copied text of handlers (via word)

Ahh... that via Word...
Try just a plain text editor, notepad or textWrangler. If the only form you have it in is Word then copy and paste it into a plain text editor first then copy it again and paste into the script editor.

Simon

Hi Kresten,
As Dave suggested, and I have run into this myself, watch out for curly quotes. If you have copy/pasted from word this might be one of the causes for your trouble. I always paste anything I've copied into the note pad first. This strips out the curly quotes and replaces them with ". I would copy your entire stack script and paste it into note pad. Then copy from there and past back into your stack editor.

HTH

Ahh, Simon beat me by 8 minutes.

Hi quailcreek,
Yeah, Dave beat us both with what he posted.

Simon

Dear Helpfull co-livecoders

I followed your advices, and controlled, but reached, after many days of experimenting, a point where I chose another track.
With access to the old stack I decided to avoid the word + Text-edit copying ( where globals were not included), and created a virgin mainstack, to which I could paste the full script, and from there copy-paste it to the new stack, so all handlers ( edited to fit the new format) were accepted, and functioning, not without further troubles, but basically having solved the problem of this forum-topic.

I hesitate to share my reflections along this pursuit,but still:

My basic endeavour is a new version (a radically simplifying re-construction) of a tool for all kinds of users (including programmers) to log activities and experiences, according to their own relevancies . outputs and inputs - along the way, 24-7.
As the tool is a livecode tool its use is paradoxically in conflict with pragmatic logging of the problems, errormesages and editings of a new version of itself. I circumwent this by parallel running of a standalone of the old version, which thus permitted me to log all the experiments, errorreports and failures, hour by hour, day by day, in the experimental live code programming of the new version.
This was indeed a healthy experience.
Because of my own, continuous and involved everyday use and development of the program , from hypercard days all the way through various revolution and livecode versions, in my production of standalones, for mac and for windows, I have - stupidly- performed only superficial testing (assuming all features to match those of my familiar use of the original).
I now have had to use the last published standalone 24-7 for three weeks, discovering that most essential features simply were lost ! Most embarassing.!
As the program was extremely ambitious, complex and demanding for a beginner I had concluded, that this was the reason that I never succeed in involving users. I now understand, that even if somebody downloaded, installed and tried, no wonder they left the shop never to return.
I encumber you with this detailed account primarily to excuse and warn- if any of you happend to pay attention to www.phenomenalog.dk - to avoid downloading the present version!
But - I must admit - also - in an optimistic mood: to question perhaps one or two of you to pay a short visit to the site, and follow the two blue links: to "target groups" and to "features".
If any of you reach so far, I should be grateful to get a mail with negative or positive feedbacks, as I am both rather isolated and full steam forward towards the simplified version and its preliminary testing.
Best regards from Kresten kresten.bjerg@psy.ku.dk (www.bjerg.psy.dk)