On 2016-07-02 17:52, Richard Gaskin wrote:
If someone out there wants to set scripts that won't run it's not my
place to tell them not to, but if it helps your development work to
let that oddity go it won't affect anything I do since I prefer
writing scripts that are at least possible to run. :)
As far as I'm aware - the functionality of the LiveCode Script Editor
has always been to set the script of the object *regardless* of whether
it compiled or not. The reason here is that if you do not do that, then
you could lose work that you have done as the version which doesn't
compile is held in a state of 'limbo' (i.e. in the script editor window
and nowhere else).
Given that LiveCode is a dynamic environment, where you can easily do
things 'behind the IDE's back' (perfectly legitimately) this errs on the
side of caution - it means regardless of what might happen in the
environment, if you have clicked 'Apply' in the script editor, then you
will not lose the changes you have made.
The reason I think this is 'okay' from the point of view of editing
projects within the IDE is that a script edit operation should really be
considered to be this:
1) Pause the running project (i.e. switch to Edit Mode)
2) Apply the edited script
3) Resume the running project (i.e. switch back to Run Mode)
If (2) fails due to compilation errors then you can't really 'resume'
the running project as it is not in a state it can be run (it is
incomplete!). Obviously, the IDE doesn't enforce this at the moment but
one can imagine that it could be enforced without too much
'interruption' to the current workflow. (Indeed, 'widgets' do actually
have this distinction - they only 'run' in Browser mode, when in
'pointer' mode notionally they are considered to be being edited and
thus processes that occur whilst 'running' do not occur).
When considering the IDE case, however, the IDE is something which
cannot be paused to edit itself, because it is editing itself - if it
were paused you wouldn't be able to edit anything (it's turtles all the
way down!). Hence, Monte's modification in the case of the IDE *right
now* is probably reasonable, as long as it is specific to IDE stacks
*and* the S/E shows a visual reminder that the script being edited is
not applied to the script property).
A more helpful approach in the future, however, might be that
non-compiling scripts are stored in the object in a custom property and
the script property of the object itself is not touched in this case.
When you edit such an object:
1) the script editor would show the non-compiling script (and
indicate that it is different from the actual set script)
2) you cannot set breakpoints, or 'run' handlers in that script - you
need to switch to the actual set script view
3) if the debugger triggers on the object, it displays the actual set
script view which would be visually distinct from the non-compiling
script view.
(The Visual Studio IDE has long had an 'Edit-and-Continue' option for
C++ which works quite well as long as you don't violate various
unwritten rules about modifications to the C++ code; if your edit and
continue fails and the debugger triggers in this case you are clearly
shown that it is not the actual code which you were editing and thus it
is stale).
Anyway, food for thought here I think!
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
