Hi Carl,
Okie dokie, it's done. In the next release, L3DT will run python scripts using cdPython when passed from the command line or when dropped on the icon or exe (assuming cdPython is installed). The app will still run in GUI mode, but at some point in the future I'll allow you to either hide the GUI or minimise it.
Instead of implementing another scripting plugin, I think perhaps we could take better advantage of cdPython and write some wrapper classes around the zeolite.py module that comes with cdPython to simplify things even further. The wrapper module could do things like fetch zeofunc handles on initialization so the script author need not have to bother with all the "plumbing".
I'm interested in the idea of pre-fetching some zeofunc handles. Actually, what I was thinking of doing was adding another set of c++/h files to the API for calling commonly-used extension functions. That way, the extension functions can be made to look like the 'normal' API functions, which may make their use appear a bit less mystical. This is actually what I'm doing in some of the API functions already (if you look in the code for CExtAPI::format_GetActiveFormat, you'll see its calling a zeofunc). Would a greater library of functions wrapped this way help, do you think?
Anyway, I was a little intrigued in the idea of a simpler scripting language, so I went ahead and implemented the plugin.
It's still really basic, but it demonstrates the concept of calling extension functions in a command-line-esque script. For it to be useful I will need to add a whole bunch of zeofuncs (these will be useful for cdPython too, of course), and I'll need to improve the ZeoScript parser a little. It needs to handle, in some very basic way, piping functions return values to other functions. Something like:
- Code: Select all
// calling map_SaveFile(map hMap, string lpFileName, format hFormat, bool SetFlags, bool ShowProgress)
map.SaveFile <z:project.GetMap HF> "C:\test map\this is a test.bmp" <z:format.GetByExt HF 0 bmp> false true
...where <z:...> is another zeoscript call, the return value of which is popped into the arg list of the parent function. For extra shorthand, I'd probably also do <m:> for map-get (e.g. <m:HF>, short for project.GetMap), <v:> for variable-get (short for var_GetByName), and <f:> for format-get (short for format_GetByExt). If I do that, the above line becomes:
- Code: Select all
map.SaveFile <m:HF> "C:\test map\this is a test.bmp" <f:HF 0 bmp> false true
That's about as far as I'll go though. This scripter is not meant for complex things. It certainly won't have fancy stuff like object handles, and probably won't ever have logical flow control (if/else, etc). Above all, I don't want to spend time duplicating the goodies that are already available with cdPython, particularly since I have to implement stuff like custom map layers
. However, what I do want from ZeoScript is a really simple, terse and command-oriented script interface, which I don't think you could easily get with real programming languages like python because their syntax is more complex.
Oh, by the way, python scripts will be able to run ZeoScripts using the 'ZeoScript.RunScript' extension function, and likewise ZeoScripts will be able to run python scripts using 'cdPython.RunScript'. Thus we'll be able to mix and match languages in the same script, where you could do lots of routine things more tersely in ZeoScript, and more complex and structured things in python.
Cheers,
Aaron.