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