Page 1 of 2
Limitations of Dynamically Executing Script in LC
Posted: Mon May 03, 2021 10:49 pm
by SteveP495
Hi,
Only second post in, so pls continue to go easy with me
I have done some searching around re example code to dynamically create controls and attach scripts etc. I am interested in an app (pretty much all targets) that has the possibility to have plugins - aka providing some script which the app executes dynamically of course.
So my question is - are there any practical limits as to what can be achieved through executing script at run time ? Either some items/libraries are not available or something else ? [Yes I do realise that debugging would be a PITA but just asking]
TIA
Steve
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 2:59 am
by dunbarx
Hi.
Do you mean to create a control, set its script property, and then execute that script? Like this, in a button script on a new card?
Code: Select all
on mouseUp
create btn "ABC"
set the script of btn "abc" to "on mouseUp" & return & "beep 2" & return & "end mouseUp"
send "mouseUp" to btn "abc"
end mouseUp
Try it, it works fine.
But why do you want to do this?
Craig
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 3:13 am
by capellan
After reading a few books about Macromedia Director,
I just noticed that Macromedia Director developers use
a lot this method of creating controls, set its properties,
and executing their script.
https://archive.org/search.php?query=Ma ... ctor+lingo
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 2:40 pm
by dunbarx
Well and good. LC as well.
But I still want to know why such an exercise is useful. In other words, what does creating a new control with a preset script do that running that script from the original handler would not? Are you creating new controls for the user?
If so, then know that the new control can be named, either explicitly as I showed, and that all its properties can be accessed by using the "last" keyword all over the place:
Code: Select all
set the name of last control to "abc"
set the loc of last control to newLoc
set the style of last control to youGetWhatIMean
Craig
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 3:16 pm
by FourthWorld
See the templateButton, templateField, etc for rapid creation of multiple objects with a given set of properties.
See also behaviors, allowing you to assign a single script to any number of objects, for faster development and easier maintenance.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 5:25 pm
by jacque
Also you can load libraries supplied as normal or script-only stacks. These could be downloaded and applied dynamically at runtime.
There are no limits I'm aware of outside of available memory.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 7:51 pm
by SteveP495
dunbarx wrote: ↑Tue May 04, 2021 2:40 pm
But I still want to know why such an exercise is useful. In other words, what does creating a new control with a preset script do that running that script from the original handler would not? Are you creating new controls for the user?
Hi Craig,
It is for changing the app without the need to recompile. Either on my end ior at the client's end.
Picture somebody with an inspection app for example who now needs a new asset type to be inspected and needs a new screen for it.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:29 pm
by dunbarx
OK, I think. So the user can create or be presented with new controls, pre-scripted.
There may be other ways to do this, for example adding a menuItem and updated script to an existing menu-style Button or menubar menu, but the idea is the same.
And I assume you are creating new cards as well, what you meant by "new screen".
Craig
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:34 pm
by SteveP495
Yes correct. Very new to LC
How cool would it be to have the app (or just card) definition stored in an SQLite db on a phone !?
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:38 pm
by FourthWorld
SteveP495 wrote: ↑Tue May 04, 2021 9:34 pm
How cool would it be to have the app (or just card) definition stored in an SQLite db on a phone !?
The LC stack file format is very compact. If you need to store it in a DB you can use a blob field, but unless you need to manage the blog with relational metadata you'll find reading LC stack files from disk far more efficient.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:48 pm
by jacque
SteveP495 wrote: ↑Tue May 04, 2021 7:51 pm
It is for changing the app without the need to recompile. Either on my end ior at the client's end.
Picture somebody with an inspection app for example who now needs a new asset type to be inspected and needs a new screen for it.
There is a common technique we call a "splash stack" because the entire app consists of a single card that opens other stacks, which sometimes shows a splash screen before opening. What you describe could be done fairly easily by providing a stack for each item , or a set of related items, you need to inspect. The splash app can read a list of available stacks either from a server or, if new stacks are downloaded, from a list of files on disk. It would update its index on launch to include all the stack names. Clicking the list would open the appropriate stack.
This provides an easy way to dynamically add features and code to an app without recompiling. The only time you'd need to do a new compile is if for some reason you wanted to change how the index is created or stored, or you wanted to add scripts or features that should be shared with all the stacks that are opened.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:52 pm
by FourthWorld
The rest of the world just calls them document files, but by any name if you need to move files between two instances of an app LC files can do that as easily as anything else. The only difference is that LC files are cooler than other apps' files.
But that's it. Edit, save, transfer - just like any other file type.
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 9:56 pm
by SteveP495
That sounds cool. Are there any examples around of a 'splash stack' ? Like I said I'm very new
That and an uplift in NFC functionity and I'd be away
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 10:47 pm
by SteveP495
FourthWorld wrote: ↑Tue May 04, 2021 9:52 pm
The rest of the world just calls them document files, but by any name if you need to move files between two instances of an app LC files can do that as easily as anything else. The only difference is that LC files are cooler than other apps' files.
But that's it. Edit, save, transfer - just like any other file type.
Yes but of course a document file with execution ability is the cool bit
Re: Limitations of Dynamically Executing Script in LC
Posted: Tue May 04, 2021 11:25 pm
by FourthWorld
SteveP495 wrote: ↑Tue May 04, 2021 10:47 pm
FourthWorld wrote: ↑Tue May 04, 2021 9:52 pm
The rest of the world just calls them document files, but by any name if you need to move files between two instances of an app LC files can do that as easily as anything else. The only difference is that LC files are cooler than other apps' files.
But that's it. Edit, save, transfer - just like any other file type.
Yes but of course a document file with execution ability is the cool bit
Technically, the app opening the document is the executable part, much like interactive ebook readers, or spreadsheets, etc.
But LC files can contain darn near anything - so yes, they are the coolest files of all.
They're like everything Apple ever dreamed of with OpenDoc back in the day, but even cooler, omni-platform, and far simpler for devs.