Limitations of Dynamically Executing Script in LC

[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

[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

[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

[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

[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.

[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.

[SteveP495]

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.

[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

[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 !?

[FourthWorld]

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.

[jacque]

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.

[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.

[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

[SteveP495]

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

[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.

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.