I'll take a stab here. The line is one statement with functions that must each be evaluated in turn according to the order of precedence. Because it's one statement, I suspect each getVal() function is getting queued as though you used send in time, so as soon as a breakpoint is encountered, you introduce idle time in which the engine can work.
This is why I like to separate out functions that return a value, like so: breakpoint put getVal("abc", dbtr) into tVal1 put getVal("def", dbtr) into tVal2 put getVal("ghi", dbtr) into tVal3 put getVal("jul", dbtr) into tVal4 setVal "someVal", tVal1 + tVal2 + tVal3 + tVal4 Now I can debug each function independently, first by monitoring the values returned to see if they are what I expect, and then stepping into the ones that don't return what I expect. This was actually discussed many years ago in a Livecode Conference in one of the coding classes. While it may look efficient to embed functions within functions, it's much easier to troubleshoot by breaking out each command or function. Bob S > > On May 22, 2018, at 15:47 , Dr. Hawkins via use-livecode > <use-livecode@lists.runrev.com> wrote: > > It seems to me I filed a bug about this a couple of years ago, and it was > fixed. > > If I have a line like > > setVal "someVal", getVal("abc", dbtr) + getVal("def", > dbtr)+getVal("ghi", dbtr) + getVal("jul", dbtr) > > and I stop the IDE in the first getVal() with the blue box when it hits a > breakpoint, the other three getVal() still get called--and slowly, after a > delay of seconds for each. > > I'm in (supposedly) the latest 9.0. > > Are others seeing this, or is it out to get me again? :) > hawk > -- > Dr. Richard E. Hawkins, Esq. > (702) 508-8462 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode