Build times

[mvillion]

Just watching it closer.

The bit that is causing the delay is

'Auto detecting library inclusion'.

It sits here for 10-12 minutes sometimes.
(Other times 20 seconds).

Same stack. Same build process. Always saving the project just before. As far as I can tell, my process is always the same.

[bogs]

I'm sorry mvillion, when i said to look at the processes, I meant (for apple) using the "Activity Monitor" to see what was taking up resources on the system during a build although it is good to know where in the build process the slow down takes place. It really shouldn't require (I don't think) a lot to figure out the libraries when they probably are not changing.

Check the activity monitor, and see if something goofy is suddenly shooting up in resource usage when that happens.

[jacque]

Just watching it closer.

The bit that is causing the delay is

'Auto detecting library inclusion'.

It sits here for 10-12 minutes sometimes.
(Other times 20 seconds).

That was my first thought, you have "search for inclusions" turned on in standalone settings. The more controls in the stack, the longer it takes while LC searches the scripts of every control. There must be some caching going on if it runs quickly sometimes, maybe it only does a new scan when new controls are added.

Turn off the search and set up any inclusions you need manually. I think you'll see consist build times that happen much faster.

[bogs]

Maybe I thunk wrong ? It happens a lot you know.

[dunbarx]

Matt.

Build times notwithstanding, are there any lingering issues with that little thing about not being able to save custom properties?

Craig

[mvillion]

Custom properties of the stack issue

When I first encountered this I decided to create simple test

I created a stack with three buttons

1 = set the cTest of this stack to "Fish"
2 = set the cTest of this stack to empty
3 = put the cTest of this stack into T_Variable
answer T_Variable

I ran it and in the IDE it worked perfectly.
I then pressed button 2 and created a standalone app.

When running the standalone app, button three would only ever display empty, even after pressing button 1 before exiting (Unless I pressed button 1 just prior)

[bogs]

That actually sounds like it worked as coded.

I ran it and in the IDE it worked perfectly.
I then pressed button 2 and created a standalone app.

2 = set the cTest of this stack to empty

So, if I followed correctly, everything worked in the IDE, i.e. you pressed button one and put "Fish" into ctest
...if you press button 3, you would see "Fish" at this point
...if you press button 2, you would "empty" ctest/Fish

You pressed button 2, then compiled the standalone. There is nothing in cTest at this point.
You start the standalone, and pressing button 3 gives you "", unless you press button 1 (set cTest to "Fish") just prior to pressing button 3.

Am I missing something?

[mvillion]

I don't think so.

This test proves to me that Stack custom properties are stored at complie time and cannot be modified and saved once in a standalone app.
You can modify them but they will reset to the state at compilation after an application restart.
No matter what state I left cTest in when I closed the standalone app, when it is opened it will always be blank. (The state of compilation).
In the tutorials, I found nothing that made this distinction and it functions differently in the IDE than in standalone.
(It would have to else there is nothing to allow the setting of a custom property.)

[SparkOut]

Properties of a standalone stack can be modified, as the stack is loaded into memory. This is volatile though as a standalone cannot save differences to itself. This is as per all operating systems.
When you try your test 3 button standalone, press button 1, then button 3 and you should see "Fish".
If you restart the standalone and press just button 3, it will show empty content. Which is expected.
Therr are numerous discussions about this on this forum and tutorials about how to save content between application loads. Sounds like you would be best off with the "splashstack" technique.
I'd find some links but using phone so easier for you just to search.

[bogs]

@ mvillion , just realized SparkOut must have posted just prior to me
OH I see. Yes, that is all correct, to a point.

From my understanding of it (and I am sure someone with a ton more knowledge will jump in if I crusk this up), when you are in the IDE you are working in straight up memory. In other words, cust. props will carry over there (unless you close and remove from memory with the stack).

However, as Craig pointed out up there :

An entirely new issue has been raised. Standalones are executables. They cannot save anything at all, never mind custom properties or, say, field data. There are a million threads on this subject.

Everything, though, can be saved if you use the "splash" stack method. Do you know about this? Do write back, because you are missing something absolutely vital.

What the splash stack method means is that you use a stack compiled to an exe to 'launch' the program and other stacks. The 'other stacks' are saved just as regular stacks, not standalones. Any custom properties/fields/etc that you want the state to carry over, you store in the regular stacks, and they will remain unchanged between runs.

This lesson does a pretty good job of explaining the launcher or "splash" stack, as Craig was mentioning. In particular, this part of it:

Creating the launcher
The launcher stack will be built into a standalone and all we need it to do is to open our main application, it can then close itself. Add the following script to the stack script of the launcher stack.

on openStack
open stack "Main Application.livecode"
close stack "Launcher"
end openStack

Thats all we need to do. The launcher will then open the Main Application stack, which can be modified and saved as it is not a standalone.

Make sure to also pay attention to this part, Building a standalone, where it illustrates how to save everything, and you should be set to go.

Hope that helps.

[mvillion]

Brilliant. Thanks

[bogs]

You know, as I re-read that lesson, I became curious about something. Could the code to launch the other stack be put in before the launcher stack ever shows? For instance -

Code: Select all

on preOpenStack
open stack "Main Application.livecode"
close stack "Launcher"
end preOpenStack

thereby eliminating ever showing the launcher stack on-screen?

I can already see where something like that might be useful.

[richmond62]

This maybe completely off the point, but then again, maybe not.

As a standalone cannot save stuff within in it my Devawriter, when it quits, saves a text file to the user's default folder
containing the contents of a field within Devawriter. When Devawriter is restarted it "looks around" for a text file named as being from Devawriter's
previous session, and if it finds one it loads its contents back into the text field.

I don't see any particular reason why custom props couldn't be restored in the same sort of way.

[mvillion]

I agree. They can be and that is what I did. I just did not know that they were not stored until I coded myself into a corner and had to code myself out.

[dunbarx]

Just so we are clear, custom props are saved in the IDE, just like, say, field text. Or anything else at all. One has to save the stack before closing and quitting LC, of course.

In a standalone, I like custom props more than external files just because I like to keep things local if I can. In one large project I do maintain a folder of external files, since these are visible to all users on my network. These files are constantly accessed and reloaded into each user's standalone, restoring past data in preparation for changes to that data. The updated information is then saved back into that folder.

Richmond's point that custom props could be saved in an external file is indeed valid, assuming one did not use the splash method. If you are the sort that likes a single stack standalone and loves external files, then fine. But there can be many types of changes to a stack that go far beyond what might be considered reasonable to save that way. The splash stack seems, to me, the default go-to method.

Consider that you wanted to change the backColor of a button. One could certainly, in a naked standalone, track that property and store it in an external file, resetting it in the next session. Or, in the splash world, simply change the color.

Craig