AW: The Art of Dissolving Splash Screens
stephenREVOLUTION at barncard.com
Sun Jul 1 23:37:26 CDT 2007
>Stephen Barncard wrote:
>>One of the neatest features of working with the splash screen
>>method is that in MacOSX, you can create the splash screen
>>standalone once, and from then on one can work in the IDE with the
>>code INSIDE the standalone package.
>This is interesting, but I'm not sure I understand what you are saying.
>Max OSX package, right?
>1) What exactly is the code "inside" the standalone package that
>you can edit in the IDE?
stacks and directories with more stacks (the 'startup splash' is the
>2) Don't you mean that you keep a *.rev stack which you work with
>in the IDE and then rebuild as a stand alone each time?
nope, as long as the startup is the same, I never rebuild. I used to
rebuild each time until I discovered I could do this.
>3) Or do you mean that you can actually open stuff inside the
It's not an executable, it's the .app PACKAGE which is really a
folder, that the system will let you double click. But of course the
user doesn't know this and isn't likely to use the ctrl-click (show
package contents) to open it.
>I can see how this mgith work on the mac if you has
>stack file included in the application bundle. But then how would
>you re-output those for Windows if you were in buildng a cross platform
Until REV or MS comes up with a plan that does the same kind of
packaging, I won't. I said before I don't do or care about Windows. I
have over 12 stacks in this thing, inside folders. My few encounters
with Windows have been extremely frustrating, annoying, stressful and
pointless, and I have lived a Windows-free life for over two decades.
If I had to work with it, I'd choose another profession.
My client doesn't want the app cross platform either, and it's a
wonderful world. I really do realize how fortunate I am.
>>Add, subtract stacks at will, and all the paths will stay the same,
>>too. The only downside I have with it is that backup software will
>>look at the package date, not the date of stack files within the
>>package. So the stack files inside need their own system of backup.
>>You can even test the standalone package as an app, while at the
>>same time the same files are standing by inside the IDE. (I do quit
>>the standalone for code editing) This is the fastest
>>compile-run-test-change-compile turnaround in the business, bar
>>With all due respect to Chipp, I really like the Mac application
>>package system. You can put EVERYTHING you need in one, nice, clean
>>package. Stacks, sounds, picture files, movie files, everything.
s a n f r a n c i s c o
- - - - - - - - - - - -
More information about the use-livecode