Strict Compile Mode Utility

A few weeks back, I switched over to using Strict Compile Mode in all my applications. SInce very few of my scripts declared any local variables, it was a time consuming task to get them all to compile error free. I ended up writing a utility to help with the task and am making is available free

Re: Strict Compile Mode

/catch does not have to be predefined in > Strict Compile Mode. > Pete > lcSQL Software <http://www.lcsql.com> > > > > On Mon, Oct 8, 2012 at 1:15 PM, Peter Haworth wrote: > >> I was surprised to find that not all variables have to be defined in this >&

Re: Strict Compile Mode

I just came across another instance of this situation. The variable you name in the catch part of try/catch does not have to be predefined in Strict Compile Mode. Pete lcSQL Software <http://www.lcsql.com> On Mon, Oct 8, 2012 at 1:15 PM, Peter Haworth wrote: > I was surprised to

Re: Strict Compile Mode

Bob- Friday, October 12, 2012, 1:49:33 PM, you wrote: > Bloodlusting zombies then?? Well, I had in mind that it's stacks that have the problem, but point taken. Bloodlusting zombies lead a relatively simple life, and little things like global vars can really confuse them. So be kind to your nei

Re: Strict Compile Mode

stephen- Friday, October 12, 2012, 11:27:22 AM, you wrote: > this problem could be solved by using a single global ARRAY with the key > being the stack name. That solution would work even better if stack *names* were unique. -- -Mark Wieder mwie...@ahsoftware.net ___

Re: Strict Compile Mode

That's a great solution too! On Oct 12, 2012, at 11:27 AM, stephen barncard wrote: > this problem could be solved by using a single global ARRAY with the key > being the stack name. > > On Fri, Oct 12, 2012 at 11:15 AM, Mark Wieder wrote: > >> Bob Sneidar writes: >> >>> I think globals make s

Re: Strict Compile Mode

On Oct 12, 2012, at 11:15 AM, Mark Wieder wrote: > Bob Sneidar writes: > >> I think globals make sense in a standalone. > > OK - that could make sense, but you'd still have to develop them in the IDE. > >> It seems to be the IDE that people have problems with them. > > Er... I don't think it

Re: Strict Compile Mode

I've just removed the one global variable I had in lcStackBrowser and I'm sure the visual nature of your analogy will remind me never to use them again :-) Pete lcSQL Software On Fri, Oct 12, 2012 at 10:32 AM, Mark Wieder wrote: > Global variables are always recipes for p

Re: Strict Compile Mode

this problem could be solved by using a single global ARRAY with the key being the stack name. On Fri, Oct 12, 2012 at 11:15 AM, Mark Wieder wrote: > Bob Sneidar writes: > > > I think globals make sense in a standalone. > > OK - that could make sense, but you'd still have to develop them in the

Re: Strict Compile Mode

Bob Sneidar writes: > I think globals make sense in a standalone. OK - that could make sense, but you'd still have to develop them in the IDE. > It seems to be the IDE that people have problems with them. Er... I don't think it's "people" that have problems with global vars. -- Mark Wieder

Re: Strict Compile Mode

I think globals make sense in a standalone. It seems to be the IDE that people have problems with them. Bob On Oct 12, 2012, at 10:32 AM, Mark Wieder wrote: > Peter Haworth writes: > >> That seems like a recipe for potential disaster, > > Global variables are always recipes for potential d

Re: Strict Compile Mode

Peter Haworth writes: > That seems like a recipe for potential disaster, Global variables are always recipes for potential disasters. I almost never find a need to use a global variable, although as I mentioned, Chipp managed to look at the pile of horse turds and find a pony. -- Mark Wieder

Re: Strict Compile Mode

On 11/10/2012 22:21, Peter Haworth wrote: Thanks for the idea - it worked for me too! Don;t worry, I won;t ask why - I've given up trying to figure out why LC does some things :-) On Thu, Oct 11, 2012 at 11:35 AM, Guglielmo Braguglia wrote: this happen very often also to me ... ... I don't kn

Re: Strict Compile Mode

Read my other post on this. If you want it to be visible only to your stack, store it in a property, then write a function called getGlobal() (or something like) and pass it a local variable name as a reference. Have the function retrieve the global in the referenced variable. You will also have

Re: Strict Compile Mode

tecting a stack prevents access to its scripts but not its custom properties; there at least ought to be an option to apply password protection to custom properties. > > Please note that, also if this rules remain valid, the behavior of > LiveCode is different if your "Strict Com

Re: Strict Compile Mode

Right. I have said before, I think there should be a stack or application global so that an application and it's substacks have access to it, but not foreign stacks. This is where things can go catawonkers if you are running two database enabled apps. It is recommended by RunRev to store your da

Re: Strict Compile Mode

local variable of the script with the correct value. Please note that, also if this rules remain valid, the behavior of LiveCode is different if your "Strict Compile Mode" is ON or OFF !!! ... and this creates more confusion !!! With "Strict Compile Mode" ON ... you are o

Re: Strict Compile Mode

Pete- Thursday, October 11, 2012, 5:23:18 PM, you wrote: > ! Sorry I don't remember the exact details, maybe Chipp will chime in and set the record straight, but it was something like wanting to perform an operation of several stacks. He loads up a global variable from one stack into mem

Re: Strict Compile Mode

On Thu, Oct 11, 2012 at 4:55 PM, Mark Wieder wrote: > Normally I think of this > as a nuisance, but Chipp Walters once showed me a very clever way to take > advantage of this "feature". > ! ___ use-livecode mailing list use-livecode@lists.runre

Re: Strict Compile Mode

Peter Haworth writes: > It's definitly true if you want to refer to it as a global when the script > runs, I agree. But I got the impression from Mark's post that perhaps the > compile process (or I guess more correctly the Apply process) recognises > globals that have been defined in other scri

Re: Strict Compile Mode

It's definitly true if you want to refer to it as a global when the script runs, I agree. But I got the impression from Mark's post that perhaps the compile process (or I guess more correctly the Apply process) recognises globals that have been defined in other scripts and not in the current one,

Re: Strict Compile Mode

On Thu, Oct 11, 2012 at 3:03 PM, Bob Sneidar wrote: > the doctor who is told by his patient that his shoulder hurts when he moves > it "like this." The doctor replies, "Well don't do that!" That was Groucho Marx And decades later, I got the same physician when my sinus was reacting to white win

Re: Strict Compile Mode

uot; HTH, Bob On Oct 11, 2012, at 2:26 PM, Peter Haworth wrote: > Hi Mark, > Checked my global definitions and there were none for the variable in > question, but Guglielmo's suggestion worked for me. > > However, this puts another little gotcha into the whole area of

Re: Strict Compile Mode

Hi Mark, Checked my global definitions and there were none for the variable in question, but Guglielmo's suggestion worked for me. However, this puts another little gotcha into the whole area of global definitions. Before starting to use strict compile mode, I've been bitten by refe

Re: Strict Compile Mode

Hi Guglielmo, Thanks for the idea - it worked for me too! Don;t worry, I won;t ask why - I've given up trying to figure out why LC does some things :-) Pete lcSQL Software On Thu, Oct 11, 2012 at 11:35 AM, Guglielmo Braguglia < guglie...@braguglia.ch> wrote: > Hi Pete, >

Re: Strict Compile Mode

Hi Pete, this happen very often also to me ... ... I don't know, but ... if you are debugging your code stepping-by-stepping and you stop the execution, some time LiveCode create this problem. The only solution is to save the stack, close LiveCode (/is not sufficient to close the stack/) and

Re: Strict Compile Mode

Pete- Thursday, October 11, 2012, 10:18:25 AM, you wrote: > I checked all my the local commands in the script and they are all within > handlers except for one and it does not refer to the variable named in the > error message. There are no global definitions in the script. Check to see if ther

Strict Compile Mode

Finished converting all the scripts in a stack to include local variable definitions and got clean compiles of everything a couple of days ago. Today, I made some changes to a handler that did not involve any new variables. When I compiled, I got the error message "local: name shadows another var

Re: Strict Compile Mode

Sometimes my sense of humor just takes a vacation…. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Oct 9, 2012, at 11:37 AM, Bob Sneidar wrote: > I think he was joking. > > On Oct 9, 2012, at 4:53 AM, Peter M. Brigham wrote: > >> That's fine if you never use vi

Re: Strict Compile Mode

On Tue, Oct 9, 2012 at 8:09 PM, J. Landman Gay wrote: > > That's what script local variables are. Declare them at the top of the > script (or before any other handler uses them) and all handlers in that > script (and that script only) have access to it: > > local sCounter *blink* Now that you pu

Re: Strict Compile Mode

On 10/9/12 9:10 PM, Dr. Hawkins wrote: I would *really* like a semi-global scope that applies only to other routines in the same script, and not to other scripts . . . That's what script local variables are. Declare them at the top of the script (or before any other handler uses them) and all

Re: Strict Compile Mode

On Tue, Oct 9, 2012 at 9:51 AM, Bob Sneidar wrote: > OH! Kind of like a local global? I've used so many languages over the years that they all run together, but isn't it C that scopes things so that if I have a routine defined within another, it has access to the parent's variables/names, unless

Re: Strict Compile Mode

Just to add to my consternation, the problem I described happened on a customer's machine and try as I might, I could not reproduce it on my computer using the same versions of LC and OSX. I'm convinced that there weren't any other plugins or front scripts on the customer's computer that might hav

Re: Strict Compile Mode

I didn't try that Bob but will give it a whirl. Pete lcSQL Software On Tue, Oct 9, 2012 at 9:49 AM, Bob Sneidar wrote: > Pete, out of curiosity, did you try "show stack tStackName"? It should be > the identical command, but what the hey? Worth a shot. I do not know of an

Re: Strict Compile Mode

I think I tried that Mark and in this case, got nothing back. It's as if the engine starts to execute the set command and never returns to the script so the catch construct is never reached. I can't remember if I tried setting the global you mentioned that causes debug to step through the IDE cod

Re: Strict Compile Mode

Thanks Ben, those are interesting conventions. I hadn't come across the extra prefix to denote the data type of the variable, although I have seen a convention where the letter "a" is appended to array variables. Pete lcSQL Software On Tue, Oct 9, 2012 at 10:14 AM, Ben Ru

Re: Strict Compile Mode

Richard and Jacque, Thanks for the explanation, I had guessed it was something like that. However, I do sometimes still experience script local variables being wiped out when I edit/Apply changes to the script they are defined in. It doesn't happen all the time and I haven't been able to tie it d

Re: Strict Compile Mode

Pete- Tuesday, October 9, 2012, 9:36:51 AM, you wrote: > For example, with help from a kindly customer, I discovered that the > following line of code in a script: > "set the visible of stack tstackname to true" > ... caused the rest of the script to not execute. I end up bracketing code like

Re: Strict Compile Mode

Ah! Once again, crystal clear explanations from Jacque. Thanks that makes sense now. On Oct 9, 2012, at 10:22 AM, J. Landman Gay wrote: > On 10/9/12 11:28 AM, Peter Haworth wrote: > >> Still don't understand what "Variable Preservation" was supposed to do >> though. It sounds like a different

Re: Strict Compile Mode

On 10/9/12 11:28 AM, Peter Haworth wrote: Still don't understand what "Variable Preservation" was supposed to do though. It sounds like a different thing than "explicit variables" or "variable checking". It's largely historical now. In the olden days, editing and recompiling a script would w

Re: Strict Compile Mode

script Edit menu. How does that interact with the "Strict Compile Mode" Preference setting, if at all? Still don't understand what "Variable Preservation" was supposed to do though. It sounds like a different thing than "explicit variables" or "variable chec

Re: Strict Compile Mode

On Oct 9, 2012, at 9:44 AM, Richard Gaskin wrote: > Peter Haworth wrote: > > Still don't understand what "Variable Preservation" was supposed to do > > though. It sounds like a different thing than "explicit variables" or > > "variable checking". > > Script-local variables (those declared as lo

Re: Strict Compile Mode

Pete, out of curiosity, did you try "show stack tStackName"? It should be the identical command, but what the hey? Worth a shot. I do not know of any messages that get generated by simply making a stack visible, so it's doubtful that some message is generating a silent error and exiting to top.

Re: Strict Compile Mode

Peter Haworth wrote: > Still don't understand what "Variable Preservation" was supposed to do > though. It sounds like a different thing than "explicit variables" or > "variable checking". Script-local variables (those declared as local outside of a handler) are the only ones affected by that s

Re: Strict Compile Mode

Indeed! Although recent frustrations have made me thing seriously about using lock messages/wait a lot more even when there's no apparent reason for doing so. For example, with help from a kindly customer, I discovered that the following line of code in a script: "set the visible of stack tstack

Re: Strict Compile Mode

;explicit vars' mode by > default. However, since the menu item "Variable checking" is sticky > between launches, it is now as far as I know meaningless. > OK, I now see there's another variable in play - the "Variable checking" item on the script Edit menu.

Re: Strict Compile Mode

I think he was joking. On Oct 9, 2012, at 4:53 AM, Peter M. Brigham wrote: > That's fine if you never use visual effects, since everything unlocks when > the current handlers are done and the engine issues an idle message. But if > you need visual transitions, scattering around lock screen com

Re: Strict Compile Mode

That's fine if you never use visual effects, since everything unlocks when the current handlers are done and the engine issues an idle message. But if you need visual transitions, scattering around lock screen commands is a nightmare -- I can't tell you how much time I've spend trying to chase d

Re: Strict Compile Mode

On 08/10/2012 21:15, Peter Haworth wrote: I was surprised to find that not all variables have to be defined in this mode. It seems that using a variable in a repeat command such as "repeat with x=1 to 10" does not require x to be defined as a local variable, nor is an error flagged when x is use

Re: Strict Compile Mode

Actually, that's the only way I got my Pachinko game to work. Bob On Oct 8, 2012, at 3:30 PM, Peter Haworth wrote: > Don't worry, I still have plenty of those to keep me from being nostalgic! > > I've pretty much decided that every handler should start with lock messages > and lock screen and

Re: Strict Compile Mode

Don't worry, I still have plenty of those to keep me from being nostalgic! I've pretty much decided that every handler should start with lock messages and lock screen and that I'll scatter random wait with messages commands throughout my code :-) Pete lcSQL Software On M

Re: Strict Compile Mode

Peter Haworth writes: > I'm switching over to to using strict compile mode in all my stacks, which > I should have done long ago. Yay! But aren't you going to feel nostalgic for all those runtime bugs you used to have to hunt down? > I was surprised to find that not all v

Re: Strict Compile Mode

Ima gonna say it's just something that was overlooked, or something that might have required an engine mod they didn't want to get into at the time. On Oct 8, 2012, at 1:15 PM, Peter Haworth wrote: > It also seems that sometimes LC constants have to be enclosed in quotes. > For example "Set the

Strict Compile Mode

I'm switching over to to using strict compile mode in all my stacks, which I should have done long ago. I was surprised to find that not all variables have to be defined in this mode. It seems that using a variable in a repeat command such as "repeat with x=1 to 10" does not