Running external module and accessing the created objects

[Rick Johnson]

On Saturday, March 9, 2013 9:34:53 AM UTC-6, Kene Meniru wrote:
> OK. Sorry to have caused all the confusion. Let me try
> this again.

Sounds to me like you should solve this problem in two manners:

============================================================
 Interactive Input
============================================================ 

Create an interactive environment where the user can enter commands directly into the namespace using your API in real time, then when he is ready to see the result of those commands, he can call "display command" or push a "display button" and the App will run the appropriate outside programs to show the visualization. 

============================================================
 Scripts loaded at runtime
============================================================ 

If you prefer the user to write "scripts", and then have your App read these scripts (and create visualizations from the commands within the scripts) then the only difference between step 1 and step 2 is *when* the commands are interpreted. In this case your app will *load* the scripts AFTER they are completely written (this could be done automatically by the app at runtime IF the path to these scripts is known, or could be accomplished by the user picking files in a dialog (Menu->RunScript).

I think you are trying to create step 1 without the interactive environment. This is your mistake. Having users work with "raw files" and then *somehow* watching a "raw file" for certain "display commands" (in real time) is folly. 

Heck, when you edit a file in a text editor you are only seeing a representation of the file from the last time it was saved, and your app could never know when the "file data" and the "file view" where synchronized; without an asinine amount of foolish programming of course.

If this is not what you want, then i suggest you create a simple representation of your code (or link to the actual code).