LiveCode Forums.

Ok, serious -

Resizestack makes me crazy. If I misspell the name of a control or do anything other very ordinary thing to do...even if I TRY to take every precautions not to mess in my resizestack handler before I test it - It´s human to do mistakes - it just haults. I´m so tired of livecode just stop responding if I did a mistake in resizestack. And I HAVE to use resizestack to handle my geometry.( Because, you know, the built in geometry options are...well...not usable for a complicated set of controls)

It´s just stupid that I can´t stop the handler with the stop button in the script.

YES, I know about breakpoints.

..........

What? Try? 15 years off and on with "Livecode" and I haven´t heard of this one. Fabulous! What a relief.

Thanks!

But: Even if this is a great way of trying before implementing, I think the livecode development enviroment should really be more aware of actually being in develop mode - and be less keen on running things if it´s bad. I mean, even if the editor shows me the script, pointing me to the line with the error....I can´t stop it? Even if there is a stop button? It should not freeze and force you to force quit livecode....

..........

holdKjeft

well spotted. So what you say is that all of my complaints is my own fault or MacOS fault? Nothing in the dev. enviroment?

..........

Hermann,

Honestly, perhaps you have too much experience with LC, I've 15 months only (but 'fluently' speak some other programming languages).

You are definitely right about that It´s years of bad habits.

Anyway, The "try" command and the little shut-up handler is a part of my new habits now. So much quieter around here now.
Thanks a lot.

Cheers,

Sjat

Vrede!

Waarom ben je zo boos?

After 15 years I am just beginning to understand Livecode: many people make the mistake
of thinking it can be mastered very quickly. This is a huge mistake.

One can become competent at a few rather primitive things very quickly.

I know as I did when I authored a CD for information about Music for Scottish schools called "Listen Hear" in 2002.

When I think about that now I shudder at how badly that was done, and how primitive and inefficiently the whole thing was put together.

While Livecode may look easy on the surface, to get anything really jazzy done one has to put in a lot of work, time and concentration [like anything else in our world!!!!!!].

RunRev do not help things by their advertising that gives the impression one can go "from Zero to Hero" in less time than it takes to cook lunch.

Unfortunately, RunRev's advertising has to take into account the fact that, in the "West" at least, the educational systems have taught the slack-jawed yobboes
that they can be heros (when they cannot, and should be the sort of moronic factory workers that are a very necessary component of our societies) with an absolute
minimum of effort and intellectual input.

I am looking forward to the backlash, where people wake up to the fact that going to some scrubby, third-rate "university" for some largely useless bit
of paper is of less value than doing a good job that contributes to the greater good of one's society.

When I went to University I was one of 5% of kids, who having stayed in school until 18, had proven their worth in exams: now, everybody who stays in school until 18
goes to some "university" where they sit on their bottoms and end up with a "degree" which largely consists of parroting stuff in exams rather than demonstrating one can think.

This is how things should be again.

Waarom ben je zo boos?

He he
I just spent the last week refactoring my code and Livecode just freezed on me a lot. It takes a big chunk of the development time. The IDE has behaved like this for as long as I can remember.

After 15 years I am just beginning to understand Livecode: many people make the mistake
of thinking it can be mastered very quickly. This is a huge mistake.

That is absolutely true. I´m not that naive anymore. But some things still irritates me after a long day. Like the thing I just pointed out:
WHY do Livecode hang/freeze when reporting an error in a resizestack handler? The whole reason for the debugger to report the bug and show it to you with a stop button - is so that you can do just that STOP the error. This (in my view) ERROR and BUG in the IDE/Debugger has been around forever. And It´s not just the resizestack handler - it happens in other situations also.

RunRev do not help things by their advertising that gives the impression one can go "from Zero to Hero" in less time than it takes to cook lunch.

Totally agree, I think they sell this product with a wrong banner: "So easy you can build a game like this Sheep Herder" - which is more like a sweeping comapnion than a game. If you get past "Drag a button and a field and make the button put hello world into a field" and want to change the look of that scrollbar....you better be prepared for a surprise. I think this type of selling point gives Livecode a bad reputation - and it teaches beginners (me included) to be lazy and think wrong.

But, Hermann, thank you again for teaching me some new things. I´ll try to be less a cry baby from now on and maybe finally grow up. But please, Livecode, stop hanging on me so much when youre debugging.

Sjat

Sjatplat wrote: WHY do Livecode hang/freeze when reporting an error in a resizestack handler?

It won't make you less frustrated, but it helps to understand the reason. The entire debugger is written in LiveCode and is subject to the same limitations as your own scripts. It can get into a loop that can't be resolved without breaking into its own scripts in the debugger. By default, the IDE ignores attempts to debug its own scripts, which means the user has no way out. You can change the default behavior by setting the global variable gRevDevelopment to true, and if you do, then the debugger will in fact work to stop the script. The down side is that leaving that variable set to true can cause lots of problems during general use, which is the reason users are protected from it.

The only solution will be to move the debugger into a separate thread so that its own behavior is not shared with your stacks. RR wants to do this eventually, but for now we are stuck with having the debugger share the message path with our stacks. I have been just as frustrated as you are when the freeze happens (and it isn't just in resizestack handlers either, that one is very easy to get around.) RR is very interested in bug reports about these cases so that they can revise the IDE to work around them; if you have a repeatable example you'd help us all if you report it.

To work around issues with resizeStack handlers, move your script into a custom handler of your own. Say you call it "doResizeStack". You can debug it there easily by calling it from the message box, because no system message is being intercepted by the IDE. Once it is working properly, you only need to put in a call to "doResizeStack" in the resizeStack handler. This is standard procedure for me, until at least RR gets multithreading.

It won't make you less frustrated, but it helps to understand the reason.

It helps a lot to know why something has stayed that way for so long. Moving the debugger outside Livecode is of course a big step.

The "Try - end try" -control structure really made my day when it comes to resizestack. I´m doing a lot of ui design and ui-geometry these days and the great thing about "try" is that I can see visually where my error might be if e.g. a button didnt move.