I am trying to understand whether or not xojoscript is appropriate for an application.
I have an existing app that responds to voice commands. Right now it does only what I have preprogrammed it to do. I need to make it user-extendable. I want my users to go in and decide that when they say XYZ command the app will go on and do some stuff they want. This could be opening a program, playing a sound or any number of things I can’t imagine or preconfigure.
I was thinking on using one of these:
*. Iron Python
*. Iron Ruby
*. Lua
*. CS-Script
*. Mono
But those require that the user is actually good at programming. steep learning curve and so on. Xojo is so easy that it would be a perfect solution. But as far as I can tell scripting documentation is not abundant and I can’t really find tutorials or good examples. So here are my questions:
Could you give me a brief rundown of what can be accomplished with scripting in Xojo?
Where can I find a list of exposed classes/objects that the user can call?
Tutorials? Examples? (obviously i saw the ones that come with Xojo)
If you have ANY comments at all on scripting or experience with any of the engines, please let me know.
Xojo Script is not that type of scripting. It is just Xojo complied on the fly without direct access to anything, except through methods you provide in the context object. By itself it can’t deal with UI, the file system, get to the command line etc etc…
You would need to provide context methods to do those things, to make them accessible to XojoScript.
[quote=93558:@Karen Atkocius]Xojo Script is not that type of scripting. It is just Xojo complied on the fly without direct access to anything, except through methods you provide in the context object. By itself it can’t deal with UI, the file system, get to the command line etc etc…
You would need to provide context methods to do those things, to make them accessible to XojoScript.[/quote]
I knew it was too good to work for me.
Any ideas on other scripting solutions that you can think of? or comments on the ones I listed.
I wrote an article about this for RB Library. It’s based on Real Studio, but still applies to Xojo.
See above.
There are none. You can supply a class (called the context class) that contains methods you can call, but that’s it. No Date. No Pair. No anything that’s an object. Also you cannot pass objects twixt your application and the script (without jumping through hoops and “serializing” them).
I should probably have said that: yes, you can do everything you want to using XojoScript, with some work. The language is the same as the Xojo language itself, so you can create your own set of Xojoscript classes and prepend them as source code to the user’s script. I do this with my app , and I prepend nearly 15,000 lines of source containing hundreds of classes, modules and interfaces. It takes about 1 second to compile the script the first time. The user programming manual runs to hundreds of pages. The script allows such stuff as report creation, graphics, custom dialog creation, etc. So, yes, it can be done.
You COULD make it work in Xojo… But you would have to write the interfaces (methods) that allow the XojoScript to talk/listen to the outside world. It’s significant work, but it would allow you to expose exactly the API you want to end users for different types of tasks.
I will say I think someone would need to know Xojo pretty well to do it.
I have added xojo-scripting capabilities to a seminar management solution of mine, which allows the user to add his own logic to the app. For instance to select data from a database, pass it to an applescript which completes Word documents. It works very well and I am quite happy about XojoScript.
Seems the voice command aspect is just an added feature to the UI logic. But your problem may not be so much choosing a script language, as rendering your app scriptable.
If I understand right, what you want the user to be able to do is to add commands to your program. In a non-voice activated app the most common example is keyboard shortcuts. On Mac, AppleScript GUI scripting basically does that : automate an app through simulated keyboard entries and menu clicks. With logic added in the langage.
If you want to add scripting capabilities to your app, before anything else, you need to render your UI scriptable. That implies centralizing all UI events in one place, where they can be managed, and eventually simulated. In essence, you have to write an internal API method.
Let us imagine you want to provide “piano play” keyboard or voice command shortcuts. You will have to make sure that every time the user uses the keyboard within any control, everything goes through the same method, where it can be recorded or replayed before going to the program logic. Then you can have a red button on your window, which once clicked starts to record all keys, until the stop button is clicked. After that, you will have a sequence of keys that can be affected to a new keyboard combination or special voice command.
Key events are but one element of UI input, which I took as the easiest example of shortcut. But let us imagine that you want to record all UI input in your app. Then you have to centralize all mouse events on all controls and their results, including listboxes which can be rather complex. For each of these events you need to record it in the sequence with all its parameters, for instance through a list of commands such as
Double click TextArea 50,100
Menu Edit Copy
Click TextField1
Menu Edit Paste
PopupMenu select "Cauliflower"
And so on. So now, instead of a simple string representing keys punched in succession, which can be played through the API method, you have to parse and interpret the language and parameters. That is where complexity shows its ugly face. Mous events are a lot less simple to replay than keyboard. To take a very basic example, a popupmenu cannot be clicked in code. So its events have to be replayed by code. Same thing for TextArea and menus. No to mention sliders, and so many aspects of a modern UI.
Making an app internally scriptable is no doubt feasible. But you need to spend the appropriate time to think the API and implement it before going any further. Then, interfacing any language is comparatively a rather simple process.
If you are thinking about scripting your app on Mac, AppleScript is probably the best way to go. It spares you all the UI events design changes. On PC, you may have to build your own, or maybe research existing utilities.
