LiveCode Forums.

Hey guys, I just remembered something I read in the Documentation and thought it would be relevant, the ExecutionContexts is a feature I particularly use in debugging, its a nice thing to have for an error reporting dialog and I remember reading in the Documentation that it may not be present in future versions of LiveCode and I wanted to ask if there is any plans to remove it as I personally find it hella useful.

Plus I've actually managed to make use of a little security function that traverses the ExecutionContexts to build a little security system for my APIs. So an API function calls SppCanAccessAPIFunction() and the aformentioned function then does a little bit of checking to determine what kind of security context to enforce on the public API. Makes for a neat little security system on my APIs.

Kind regards.

I take it that it is only the immediate caller that you check in your APIs?

If so, how about a context-local property 'the caller' - returning a long id to the object making the call...

Not to worry. Just about everything I've got would break if we removed it. And you're aware that the format is different if there are behavior objects involved, right? There's an extra parameter at the end of the line that specifies the object.

Your security function sounds awesome. Care to share the code?

Ask support... support@runrev.com

Basically the private function SecpCanUserAccessAPIFunction (It turns out I was using Secp rather than Spp, ma bad) does a check, it places Item -2 of line -2 of the execution contexts into a variable named tFunctionName and then does a check against a list of functions that require a security check before continuing and performs the security check so effectively say I have a security sensitive API function called KiShutdownSystem() which performs a shutdown of the application.

It should only be called by callers who have a user account of SYSTEM and thus KiShutdownSystem() first calls SecpCanUserAccessAPIFunction() which performs a check so ultimately something like this:
Basically the functions rely on the ExecutionContexts and I just want to know if the team plans to follow on with the decision to nerf it completely in the future as I think it is a pretty nifty little property. Plus again, it's useful in an ErrorDialog message when you are sending an error report to the developer.

@Dixie: Well, you could ask support, but Heather would only end up asking me anyway

In any case, I can't see 'the executionContexts' going anywhere - but it would be better if more specific features were introduced to allow people to do what they currently use it for. That property has always been 'subject to change' (although not wildly) in order to support the interactive debugger. However, it's not changed much at all in the last 10 years, so I can't see it changing much in future.

The forum wouldn't let me just explain my happiness with a simple Yes, so I feel the need to document it in a way that would allow me to explain it in a lengthier message.

This was sufficient. XD

One of my longer-term goals is to be able to grab the stack frame *before* a line gets executed, rather than after.

The forum wouldn't let me just explain my happiness with a simple Yes

LOL

You cannot make another post so soon after your last.

<sigh>

That "item -2" is going to get you into trouble with behavior objects, where you'll find what you're looking for in item -3. Here's how I resolve "the target" given the fact that a line in the executionContexts may have 3 or 4 parameters, with there being a fourth parameter only if the code is in a behavior object. You may want to do something similar.

Are you sure? The security check function is implemented in the same stack as the public API, for example the KiShutdownSystem() function is defined in the stack script of stack Ntoskrnl and so is the SecpCanUserAccessAPIFunction() private function, thus when the EC returns it returns the value:

Stack "Ntoskrnl",KiShutdownSystem,761
Stack "Ntoskrnl",SecpCanUserAccessAPIFunction,1421

There are no behavior objects in the middle, its a straight jump from one function to another.

mwieder wrote:One of my longer-term goals is to be able to grab the stack frame *before* a line gets executed, rather than after.

Don't you have this information already? You get a 'trace' message before a line of script is executed, so that would be the context before the next line, and after the previous. (I might be misunderstanding what you mean, of course...)

@Mike- no, you're fine as long as you're not dealing with code in a behavior object. In that case you'll see another parameter after the line number, and so the function name you're looking for will end up in item -3 instead of -2. If you're not looking at a function in a behavior object then there's no problem.

Hmm, so would using "Put Item 2 Of Line -2 Of The ExecutionContexts" not work better as it doesn't appear like a new parameter being introduced would affect it then, I may expand on the functionality in the future to allow the security system to perform a check on behalf of API functions in other components but for the time being this is good for my public API.

Where you may run into trouble there is that there's (currently at least) no restriction on object names containing commas. If you run up against a stack named "one,two,three" then trying to pull item 2 of that will cause unpredictable results. And I hate those.