LiveCode Forums.

I made a small executable for windows that starts up without any delay while in the development environment, but when saved as standalone it frequently takes as long as 20 seconds to launch. A console timing test showed a 19.47 second delay between program launch and the time the window became visible. Since the program is so small and made to be frequently accessed, this is not only a confusing bug, but a very annoying one as well.

It is apparent that some scripts are executing long before the program window becomes visible, so I don't understand why the main stack is not opened for so long after starting.

Does anyone know why this happens and is there a way to make the program start up as quickly in the standalone as it does in the IDE?

The only script that runs on startup and preopenstack is a quick file integrity check and a self-extraction of the required installation files if missing. This would explain a slow launch on first run, but not on every run.

I found that running the executable in compatibility mode for Windows XP SP3 causes it to start several seconds faster, though it looks a bad to tell the end-user to set a compatibility mode for a program that was only just released. Also, this is designed for use by the more computer-illiterate end-user and I don't want to add a walk-through to my webpage for something I would rather not need in the first place.

Any help would be appreciated.

After additional testing. I found that there is nothing being executed between startup and preopenstack. There is just a huge pause between them and I can't find any reason why or any means of speeding things up.

Even running preopenstack from within startup and skipping it later has no effect.

This is just a shot in the dark but...
I wonder if you "set the dontUseQT to true" if that will speed things up?
The IDE loads QuickTIme on startup so it is probably faster.
If you don't need slick blend transitions no need to load it.

Simon

It may not be the solution I was looking for, but I found a workaround. Instead of using "preopenstack" I made another handler called "run" and placed everything in there. At the end of "startup" I called "run" and now it works just fine.

There seems to be a bug on the preopenstack handler right now.

Nice thought on DontUseQT, but I do need to use show/hide functions. Disabling QT causes the program to crash.

Just noticed that the problem still persists. It only seemed to be solved because I was running my program in compatibility mode. Once that is disabled it is slow again.

I may have found the problem... I have a text field that contains the entire contents of a required DLL so that the program does not need to have the DLL carried around along with it in order for it to work. It seems to be a bit slow with loading the DLL field into memory. I am trying to move it to another card and see if that helps at all.

Do NOT use a field to store binary data! NEVER!

Put your DLL into custom property and that should do the trick:
...
set the cStoredDLL of this stack to url("binfile:path/to/the/someDLL.dll")
...

Wow, that was unexpected!

Simon

I've never heard of cStoredDLL before. It's not documented anywhere and not even mentioned online prior to your post.

At any rate, I've managed to get it working smoothly. I put the DLL on another card and call it using: This works decently well, but is there a way of having a DLL stored internally so that it doesn't even need to be set or accessed at all as a file? That would be preferable by far.

If there is no way to avoid this, I'll just use your method. A hard-coded variable will work for now.

Hi,
Klaus was using cStoredDLL just as a custom name (like variable name).
His suggestion was to make custom property in your stack (named cStoredDLL) and put the binfile into that.

I guess his CAP words would suggest you really should not use a field. No Really.

About not having to write the file out... Heck maybe this will help, I've never done it before.

Simon

Since a field functions much like a variable, only with far more features, there really is no reason that a field would be a problem, especially if it is an invisible, locked field on a card that the user has no access to.

I am trying out a stack variable for now as suggested. It seems to take the same amount of time to start up, but since the DLL field is on a different card it only makes sense that it would be the same.

Storing BINARY data in a field may result in LOSS of data when you later write the fields content to a file on disc!
Livecode modifies the LINE-ENDINGS of fields to fit the current platform, which is not healthy for binary stuff!

And keep in mind that "the defaultfolder" in a standalone might be a folder where your standalone (resp. its current user)
does NOT have write permission!
Use -> specialfolderpath("documents") or something else where you definitvely have write permissions.
After that you can easily set "the externals" of your path to that file at the new location!

In Livecode please use the SLASH as a pathdelimiter:
...
the defaultfolder & "/revzip.dll"
...
Using the BACKSLASH is only necessary and mandatory when using pathnames in SHELL commands on Windows!

Sorry, for seeming a bit "picky", but I only want your best

No problem.

As I said, It has been working flawlessly thus far.

Just to be safe, I already removed the DLL field and replaced it with a stored variable. It works exactly the same way in my case and even takes the same amount of time to load, so line endings are not an issue and this makes no real difference in launch time. I imagine the only reason I would run into a problem is if I forgot to include the "for binary" part when reading from or writing to the file. If LiveCode does edit the binary data of the file upon writing it to a field, then that is a serious problem with the IDE itself since the binary modes are included strictly for the purpose of handling raw file data without any modifications. After extensive use of this in several different cases, I have found that LiveCode, at least in recent builds, does NOT modify binary data at all in any case unless directly instructed to do so. You can give it a try yourself if you don't believe me. If you know what you are doing, you will not have any problems.

Also, the program uses shell ATTRIB calls to set the attributes of the write locations and even creates its own installation folder in the same directory as itself using these same attribute settings, which locations it checks thoroughly on each launch and repairs files if necessary. It uses a "Same as Invoker" UAC manifest, so the only reason it can't write to the file is if the user has no access either. Since the file is a portable standalone, it wouldn't make much sense for the user to place the file somewhere he/she doesn't even have permissions to write in. Actually, that would be impossible. Using a specialfolderpath would only result in junk files and broken installations if this were to be used on an external drive (one of the intended uses), not to mention that it would not allow the use of multiple installations on one machine.

Finally, LiveCode does not really care much if you use a slash or a backslash internally, so long as you do not need to delimit the items of that variable. Since no delimiting is necessary and no further access is required, there is no issue with using windows-style markings internally since they are both treated the same. Whenever it really matters, I am a little more cautious about how I mark folder paths. When it doesn't make a difference, it's only a matter of style at that point and I really don't care.

Thanks for the advice. This problem has already been solved and I would consider this officially CLOSED.

WAIT!

You might be interested in the shorter URL file syntax!
...
## A cool one-liner
## binary stuff -> BINFILE
put the cStoredDLL of this stack into url("BINFILE:" & "path to/new/location for the/dll.dll")
...
## "simple" text -> FILE
put the cStoredText of this stack into url("FILE:" & "path to/new/location for the/text.txt")
...
Same applies when reading files INTO Livecode!

I already knew about that. I am not a novice. I have been using LiveCode back since the initial release of RunRev on Mac years ago, so I am fairly experienced with the basic operations. I've just run into problems with using URLs before and decided I am not a fan. They're a bit finicky sometimes. If the file is being used at all, it tends to skip the URL calls to the file and just go on executing. And I'd rather have a bit more control over my file operations.

In this instance it would be safe, but I have had times when either only part of the file was read from or written to or sometimes nothing was done or the file was just emptied.

In any case, it does the same exact operation and takes the same amount of time to execute. The only difference is the number of lines of code used and the ability to check if the file can be written to or not before just putting something somewhere (open file for binary write -> check the openfiles). I'll change it later if I want it to look a little neater.

Just so you know, the code included earlier was NOT a quote from my code. I just put that there to show what I was doing. The startup handler is actually pretty extensive. I needed to fix a few slower scripts in it to reduce startup time by a few seconds as well.