A while back, I started playing with the idea of invoking a (gcode)
subroutine from within MDI. One problem is that the current file is
closed and all knowledge about it destroyed when you stop and switch to
I implemented a quick fix that is enabled by setting LAZY_CLOSE in the
.ini file (damn, I forget which section it has to be in). When
LAZY_CLOSE is set, the current file isn't closed until a new one is
opened. Together with some other minor changes, that allows a MDI
program to do whatever is wants in the context of the last run program.
Off hand, I have not the foggiest idea of what happens if the program is
exited from within a subroutine.
At any rate, that change is implemented in TRUNK. I'll probably start
playing with it soon to give it some real testing. The change should
have no affect if LAZY_CLOSE is not set. So, if you like the existing
behavior, don't set LAZY_CLOSE.
The recent IRC discussion on starting a program at a particular line
brought this to mind. If you are just restarting the current program,
LAZY_CLOSE might be useful. You can call a predefined subroutine from
MDI to set the modes the way you want/need them.
Comments are solicited. If you think it was a dumb idea, let me know. If
lot's of people think it's a dumb idea, I can take that change out of
the source. But since it doesn't break existing behavior, it shouldn't
BTW: I think the idea of enabling things that change existing behavior
by settings in the .ini file is a good model to follow. That let's us
add and modify features without breaking existing behavior for current
users and programs.
Of course, the next step is to make it so some of these features can be
enabled from within a particular program. That, too, is pretty easy to do.