The subject says (nearly) all:
How to make REALbasic apps scriptable nowadays ?
You can use Xojoscript. Create a Xojoscript object and assign the item you want to script to the Context property. The script will then have access to all the methods and properties of the item.
e.g. This would change Window1’s Title property via a script:
Dim script As New XojoScript
Dim scriptsource As String = "title = ""Hello, world!"""
script.Context = Window1
script.Source = scriptsource
script.RunYou mean AppleScript on Mac OS X?
Eventually if you’re willing to spend some money, IMHO an alternative could be also the LuaScript Plugin from Einhugur software.
Taken from the Einhugur website:
[quote]Lua script plugin is a script interpreter that you can plug into your application to use to give your users ability to script your applications.
- REAL Studio built application can run the Lua script as whole or call separate functions within the Lua script.
- Lua scripts can call REAL Studio functions that you register to be visible to Lua scripts.
- REAL Studio built application can read and write global variables from a Lua script.
- Its easy to make functions to allow Lua script to manipulate your REALbasic objects.
- You can create Lua classes from REALbasic code.
Lua is a powerful, fast, lightweight, embeddable scripting language
On Linux and Mac OS X it takes little over 200 kb when compiled into your application. On Windows it takes little over 300 kb. (Little over 400 kb if compiling Universal binary on MacOS X that has both PPC and Intel code).
The Lua plugin is small
On Linux and Mac OS X it takes little over 200 kb when compiled into your application. On Windows it takes little over 300 kb. (Little over 400 kb if compiling Universal binary on MacOS X that has both PPC and Intel code).
Lua is proven and robust language
Lua has been used in many industrial applications (e.g., Adobe’s Photoshop Lightroom), with an emphasis on embedded systems (e.g., the Ginga middleware for digital TV in Brazil) and games (e.g., World of Warcraft). Lua is currently the leading scripting language in games. Lua has a solid reference manual and there are several books about it. Several versions of Lua have been released and used in real applications since its creation in 1993. Lua featured in HOPL III, the Third ACM SIGPLAN History of Programming Languages Conference, in June 2007.
Lua is fast
Lua has a deserved reputation for performance. To claim to be “as fast as Lua” is an aspiration of other scripting languages. Several benchmarks show Lua as the fastest language in the realm of interpreted scripting languages. Lua is fast not only in fine-tuned benchmark programs, but in real life too. A substantial fraction of large applications have been written in Lua.
The Lua script engine Lua is designed, implemented, and maintained by a team at PUC-Rio, the Pontifical Catholic University of Rio de Janeiro in Brazil. Lua was born and raised in Tecgraf, the Computer Graphics Technology Group of PUC-Rio, and is now housed at Lablua. Both Tecgraf and Lablua are laboratories of the Department of Computer Science of PUC-Rio.
See more at www.lua.org and by all means support their project by buying a book from their site.[/quote]
I took a look at both XojoScript and Lua and came to the conclusion that XojoScript would probably be an easier end user scripting language (although as a developer I like Lua). My main concern now is not knowing if XojoScript is going to be supported for an iOS target as the application that I am working on would also be a good fit for iOS and I want the app user scripts to be the same script source code across Windows/Mac/Linux and iOS. So now I am wondering if I should create my own (simple) scripting language and then either translate for Windows/Mac/Linux or interpret for iOS if there is no XojoScript support for that target.
In my interview with Joe Strout (the guy who is doing the iOS version of Xojo) at XDC he pretty much said that XojoScript would not be on iOS because of Apple’s developer’s guidelines. That could change if Apple relaxes some of their rules, but for now I would assume that it won’t be possible.
(You could send a script to a server and have the script run there, or use Javascript, which is available on iOS. Python also seems to be available on iOS, though I wouldn’t know how you’d access it via Xojo.)
[quote=32727:@Marc Zeedar]In my interview with Joe Strout (the guy who is doing the iOS version of Xojo) at XDC he pretty much said that XojoScript would not be on iOS because of Apple’s developer’s guidelines. That could change if Apple relaxes some of their rules, but for now I would assume that it won’t be possible.
[/quote]
Hi Marc, I was concerned about that too so I raised in in another conversation here - you may want to read through the short conversation.
There are some programmable apps on the App Store now (Codea, TechBASIC, etc), and another poster wrote the following:
So although XojoScript may not make it through ( a shame) it seems like the rules are already relaxed enough even if Xojo have to restrict the use of some of the script functions.
Thanks for the information though - if the guy doing the iOS version says ‘no’ then he should be right about the exclusion, it would be good to know why (in detail) from Xojo because it will be the loss of a good feature.
The problem is that XojoScript is a JIT, which requires the ability to write instructions into memory and then execute them. iOS prevents any memory page that was ever writeable from being executable.
Languages like Python work because they’re interpreted. It would be possible to make an interpreted version of XojoScript, but it isn’t a simple flip of a switch.
The exact line from my article reads:
I think Joe Ranieri’s response sums up the specific difference: interpreted versus compiled (Xojoscript is compiled).
Thanks again Marc and Joe, I fully understand now but I wasn’t able to get a useful answer in the previous conversation where I got
I know that is the ‘standard’ response but in this case as you seem to know the answer already it would have been more useful to give it 
Your replies at least allow me to design the script part of the application appropriately. I am going to pose another if you don’t mind…
Assuming that plug-ins will be supported in the iOS target (with new compilation by the 3rd party) can you envisage any problem with the Einhugur LuaScript interpreted approach? I believe that Codea is Lua based and the source for Lua is freely available so the actual implementation does not necessarily have to come from Einhugur although they have made it easy and fairly inexpensive and up to date so I would rather not have to invest my time in making a plug-in.
But that’s just it. If Apple were to change their mind tomorrow, our answer would change accordingly. What i was suggesting, however indirectly, is that you should not be writing code for a target that is not currently available. First of all, any code written for iOS will have to use the new framework… And as we’re not even at Alpha yet, things are still subject to change. I’m just trying to save you some headache down the road.
Regarding plugins, I wouldn’t make an assumption like that. I seem to remember there being an issue with dynamically loading external code. We can probably should get Joe R or Joe S to speak to this though.
I understand the urge to speculate about such things, but you really should be coding with the tools you have today, and not what you (and others) are dreaming that we might release someday in the future. You’ll have a much better experience with Xojo that way.
Greg’s right – don’t go making this assumption. Plugin support isn’t on the initial roadmap for a variety of different reasons, including, as Greg mentioned, the ‘lack’ of dynamic libraries on iOS.
Sorry all, I was thinking (and forgot to write) about AppleScript (and WindowsScript ?)
However, I will read carefully all your answers.
[quote=32808:@Greg Olone]But that’s just it. If Apple were to change their mind tomorrow, our answer would change accordingly. What i was suggesting, however indirectly, is that you should not be writing code for a target that is not currently available. First of all, any code written for iOS will have to use the new framework… And as we’re not even at Alpha yet, things are still subject to change. I’m just trying to save you some headache down the road.
Regarding plugins, I wouldn’t make an assumption like that. I seem to remember there being an issue with dynamically loading external code. We can probably should get Joe R or Joe S to speak to this though.
I understand the urge to speculate about such things, but you really should be coding with the tools you have today, and not what you (and others) are dreaming that we might release someday in the future. You’ll have a much better experience with Xojo that way.[/quote]
<- Started with a smile. Greg, whilst I appreciate your advice and I believe you are showing genuine concern, you have made a wrong assumption in my motive for asking. I am not coding nor writing code for this scripting part. I am considering ‘application architecure and design’. I have an application that I am coding, it is 99.9% Xojo code & framework with a tiny dependency on Cocoa declares to get a NSStatusItem menu in a Mac Target. In fact apart from Xojo types and classes the model only needs JSONItem and the controller part that polulates the model only needs HTTPSocket. I appreciate that the whole UI could be a different UI framework for iOS but the Model part of the MVC is completely separated as it should be, and so I am hoping to be able to re-use that model part in any forthcomming iOS app. Now I need to add some kind of script to the model so that when a particular state change occurs a user can script something using the model (not referencing the UI) and I need to decide how to do that by firstly looking at any script technology that may be available - hence my questions. I think that you, Joe and Marc have given me what I need now because from what you have stated:
Things can change but the best knowledge today is:
(1) No XojoScript for iOS.
(2) No plug-ins on the initial iOS roadmap.
And that really does help to know.
Looking back an my initial post in the other conversation - I wrote:
[quote=30320:@Carl Clarke]I searched to find a list of concepts from the Xojo Language & Frameworks that will not be supported in any future iOS target but could not find one. I know that the whole iOS thing is still under development but has Xojo released a list of things that will not be supported?
I came to this question because I was wondering if XojoScript would be supported on iOS as I need to implement a feature in an application where the user can code a response to some application event and I need to choose to either make my own simple scripting ‘language’ or allow the use of the more powerful XojoScript and I would like to take much of the application code to iOS in the future. Then I thought, if Xojo Inc. know that some things are just not going to work it would be good to have a list of them so I can avoid them now.[/quote]
So although we have taken a longer path to get to the answers, we got there on the script subject.
I do understand that you have company policy on pre-releasing information but I thought that this was to manage user expectation in as much as you don’t want to say a particular feature is in and not be able to deliver it or deliver it quickly. What I was asking for is to know what is out from your best knowledge today as shown in bold in the above quote. If I know something is out (at least for now) then I can avoid it and perhaps be pleasantly suprised that one day it becomes in - so you will have managed my expectation correctly. Smiling again -> I think a list of out things is perfectly reasonable if you dont want users to have sight of your roadmap because the roadmap would create expectations that you may struggle to deliver. Please don’t then say that if it is not on the out list that users would assume that it is in, I know there may be some difficult users but we are not all of the same mentality. Out means out for me i.e. don’t take the risk to depend on it. Scripting seemed like a risky area and that is why I asked.
Incidently the plug-ins situation is interesting, I have not directly used any 3rd party plug-ins and never thought about the dynamic linking aspect in iOS. Since Xojo supplies some database support as plug-ins I guess these could be initially out too and SQLite only may work. Again I would not expect you to state that SQLite is in but if you knew that MSSQL. MySQL, ODBC, Oracle or PostGreSQL were going to be out on the initial roadmap then it would be helpful to know.
Thanks for the information.
For AppleScript, you need to make a “Scripting Definition” file (.sdef file in plist format) and place it in the Resources folder, then reference it in the app’s Info.plist. Apple has info on the format here:
https://developer.apple.com/library/mac/documentation/applescript/conceptual/applescriptx/concepts/scriptable_apps.html
But there is a free app that assists in creating Script Definition files (and also converting older resource fork based AETE files) here:
Sdef Editor:
http://www.shadowlab.org/softwares/sdefeditor.php
Once you have your new sdef file, place it in the Resources folder of the app bundle. Then modify the apps Info.plist file to point to it:
<key>OSAScriptingDefinition</key>
<string>AppleScriptVocabulary.sdef</string>
For the record, I’ve developed a quite smart wrapper to make a Xojo app scriptable with Applescript. It is based on “Cocoa Scripting”, which makes handling objects much easier than with the old AE-based API.
My wrapper handles all the NS… base classes for you, so you do not have to mess with Cocoa objects at all. Contact me if you’re interested.
A demo app showing its abilities can be downloaded here: http://files.tempel.org/RB/Scriptability/AppleScriptable-App.zip
FileMaker ships a framework as part of their iOS SDK which is linked into the new app.
Sounds possible to me do also support framework packaged plugins.