Blog

*** Updated 7.7.2005 ***

Zinc allows you to have a browser appear over top of your Flash movie so you can make an interactive web browser. However, Zinc’s programming model assumes AS2 classes don’t exist and _root is… well, just like everyone views _root; as their playground, putting anything they want there and assuming it won’t change.

What we do is something Darron Schall showed me, only a little different. It allows us to treat _root as a class, get syntax checking, and emulate what Flex does with “mx.core.Application”. We override _root’s __proto__ so it points to our Singleton class, call its constructor manually, and call onLoad if it hasn’t been called already. I had to put a conditional for onLoad because sometimes it gets called for you, and sometimes it doesn’t (like when you debug in Flash).

Example

// ensures Flash/MTASC compiles class
import com.Application;
var depend:Application;
delete depend;

// override _root's proto
this.__proto__ = _global.com.com.Application.prototype;
//call constructor
_global.com.Application.apply(this, null);
// call onLoad if it hasn't been called already
if(this.calledOnLoad == false)
{
        this.onLoad();
}

That, however, pisses Zinc off. We have do store a reference to the Browser’s class instance on _root (Application class) so it knows to forward events it gets such as when a webpage is done downloading in the browser(in this case, “onBrowserDocumentComplete”). However, after doing the above _root.__proto__ override, I no longer receive those events. It seems the _root Zinc thought was there is no longer there, even though I can clearly trace out the funciton it needs as there and available. Making it static doesn’t work either. However, putting this in the constructor does:

this.onBrowserDocumentComplete = this.onBrowserDocumentComplete2;

Where the “onBrowserDocumentComplete2” is the class method, and onBrowserDocumentComplete is merely a variable you define up top:

public var onBrowserDocumentComplete:Function;

Something about _root’s “instance” is what Zinc likes I guess. Anyway, I now get my _root events again from Zinc.

Only one thing to do when you can’t code anymore…

Spend 4 hours doing something stupid.

Thanks for the idea JD!

First off, wanted to report the sad news my blower’s dead; wrong mixture of gas & oil, piston’s busted or something.

Anyway, deploying a project yesterday and doing the unthinkable, loadMovie. A parent SWF loads a child SWF after a successful login. These child SWF’s are basically applications and the shell that loads them is just a security mechinism. We’re using Zinc, and we originally we’re just compiling this “shell” natively; so the EXE would be a small exe the user’s download to their computer, but the SWF’s remain on the server that the shell actually downloads, making it easier to keep up to date without having to distribute a new EXE since the shell just logs in and downloads SWF’s.

Anyway, during testing we kept getting security sandbox violations. I was extremely confused since Flash as a projector or SWF running on the desktop has free reign and can do anything it wants, when it wants. I figured maybe because the new Flashout (0.2.1.2) now hosts the Flash Player in a browser window, it’s bound by domain restrictions (even localhost).

…but a Zinc projector? It’s an exe right? Guess not. Even using the option of Zinc to merely load the SWF from a remote URL instead of compiling the SWF in didn’t work; same issue.

So, reading the docs found 2 good examples of when to use System.security.allowDomain for SWF’s loading SWF’s. Our’s was the 2nd, where a shell SWF loads other SWF’s into it, and wants to be able to interact with them; like set variables on it when it’s loaded, call methods, etc. So, we did:

System.security.allowDomain(_parent._url);

in the children SWF’s. You can be sure _parent’s already loaded (because the _parent loaded you), and the _url of the parent could change, but this is the exact way without hardcoding it. Works like a charm.

Still, I’m confused what Zinc is doing, making the SWF’s act like they are in a browser. As an exe, I am not held to the security sandbox.