Ken -

thanks for the explanation. It was unclear from the code what this was for, and 
I didnt find it in the docs.

Am 15.09.2011 um 18:51 schrieb Kenneth Lerman:

> The reason USE_LAZY_CLOSE was originally put in the code was so that 
> after loading a file, it would not be closed until another one was 
> opened. That way, MDI code could call subroutines in the (still open) file.

This only works if an interpreter instance already has *parsed* the file and as 
a consequence the oword label is defined

Parsing happens in the UI interpreter instance immediately after opening the 
file for preview generation. 

However, in the task instance of the interpreter, this does not happen until 
the program is actually executed. 

Therefore, depending on wether the program has been run or not (!), you either 
get (this is per v2.5_branch):

Program not yet run:
- MDI call to oword subroutine fails in the task interp instance with 'Unable 
to open file <owordlabel>
- whereas in the UI interp instance the MDI oword call succeeds, since the 
program was parsed on 'open file'; which also means preview and world model 
might diverge.

Program already run:
- MDI call to oword subroutine succeeds in both interp instances.

I think it originally might have been a good idea before named oword procedures 
could be called from external files, but given above semantics I suggest to 
remove that feature, and to document the following restriction:

"If you want to call oword subroutines from MDI, the oword subroutine needs to 
be in its own NGC file."

If there are no objections, I'll add this change as well.

-Michael



------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to