AW: The Art of Dissolving Splash Screens

[Stephen Barncard]

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

yes

>
>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 
executable)

>
>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
>executable?

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
>app?

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 
>>none.
>>
>>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.
>
>-
>
>Sivakatirswami

-- 


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -