Floorplanner Tech Blog

The Flash Player on OS X currently lacks support for mousewheel events. This means that users cannot use their mousewheel on OS X, in the Floorplanner we use the mousewheel to easily zoom in to your Floorplan. After reading this post from pixelbreaker, I was inspired to implement this in the Floorplanner which was, in fact, very easy. I decided to only use the JavaScript class of pixelbreaker, which sends the mousewheel events to the Flash Player (on the Mac). In the Floorplanner ActionScript this event is handled by our own internal Event management system, which sends the Event to the reponsible part of the code. So thumbs up for pixelbreaker, for making this really easy to implement!

I’m currently working on a JSON export from the Floorplanner and I’m glad I found the excelent JSON Validator made by arc90 lab. They made the debugging process a lot easier. Thanks guys!

In college I followed a course in numerical analysis. The main point of the course was to be careful with floating point arithmetic, because it is vulnerable to rounding errors that can significantly influence the result of complex computations. Until yesterday I never had encountered such a problem. Now that I have lost my innocence in this matter, I would like to share my tale of nasty debugging and frustration.

After receiving some bug reports of Floorplanner designs that failed to save properly, we dove into the code to see what was going wrong. After some time, we found that the errors were caused by the script that loads the design after it has been saved with a unique name. This unique name is passed to the script to be able to find the design. We used the current timestamp as a unique name for the design. The current timestamp simply is the number of seconds passed since January 1, 1970 and looks something like this: 1206712028. As a design name, this number was passed to different scripts, both client-side and server-side. However, at some point in this chain of scripts, the number was changed slightly to 1206712030 and because of this the associated design could not be found, resulting in an error.

At first, we investigated the possibility that the stored timestamp was overwritten by a newer timestamp, as this could explain the slight increase in the number. However, we were not able to find this anywhere in the code and sometimes, the number was decreased a bit instead of being increased.

Finally, we monitored the data being sent between the different scripts, and we found that ActionScript automatically converted the numeric design name into a number in scientific notation. In our case, this would be 0.1206712028 x 10^10. Unfortunately, this number was rounded to 0.120671203 x 10^10 because computers use floating point arithmetic to store numbers in scientific notation. This number would eventually be converted back to normal notation, but it was now 1206712030 because of the rounding error.

We fixed it by putting an ‘a’ in front of the timestamp, preventing the automatic conversion to a number. Not very elegant, but it works!

Last week we wanted to see if we could speed up the loading of the Floorplanner Flash app. The Flash app (AS2) consists of 1 main app that loads several swf forms (the windows you see, like the library). The library itself holds a lot of furniture elements, which are separate swf files that are loaded one by one.

When a user creates a floor plan and adds furniture to it, it’s not strange that the design holds more than 50 furniture elements. Though all elements are small swf files, it takes a lot of time to handle all resource requests on our server. We thought it would be nice if we didn’t have to load all the elements one by one, but that we could bundle them into one big swf file. Then the generated bundle-swf is loaded into the flash app and the furniture elements are loaded from the bundle-swf.

We looked at Swfmill and Ming, and we did manage to create a setup that could dynamically bundle the furniture elements into one big swf. The problem was that it didn’t work for all our furniture elements. Almost 10% failed.

In the Flash app we also experienced some unexpected issues. You can only add mc’s (furniture elements) from the library to the stage by using attachMovie(). That means that all elements must have the same parent mc (AS2). So you can only use one bundle-swf, because if you load another, your attached mc’s will be removed.

With all the issues we encountered we decided to keep things as they are right now, and tackle this issue when we’re upgrading to AS3.

In my previous post I thought that swfobject was causing the wmode=transparent problem in IE. However, I was wrong. Folkert told me that swfobject only passes the parameter to the Flash Player, swfobject is only the messenger.

Instead of wmode=transparent I also tried wmode=opaque as Jorrit suggested, but it didn’t make a difference. I set up three wmode sample pages to test the issue:

• regular
• transparent
• opaque

When you’re viewing the transparent and the opaque page in Internet Explorer you can see that editing the walls is quite difficult. You can also see that panning the design results in a strange elastic movement. I hope to find a solution soon….

Update
I’ve been reading this post and it looks like it’s something we have to live with…

SWFs using wmode actually perform slightly different from SWFs that have a default wmode. The difference is that when you are running as transparent or opaque, events are delayed until an onEnterFrame. If you are running at a slow frame rate and drive your movie with setInterval or use any number of other events, you are back to your slow frame rate. The real kicker is that SWFs in IE have this bug. SWFs in Firefox are just fine.

Last week we accidentally introduced a nasty bug into the Floorplanner Flash app. Well, actually it wasn’t the Flash app that caused the problem. It appeared to be a weird issue in swfobject.

We wanted to layer some html content over the Flash app, so we added this line to the JavaScript:

swfObject.addParam( "wmode", "transparent" );

By doing that, the Flash app started acting really strange in Internet Explorer (6&7). I removed the line today and all seems fine again…

Setup

• SWF A is on server 1
• SWF B is on server 2
• SWF’s C…Z are also on server 2

I got multiple Sandbox security errors when I tried to load SWF B (the one from the different server) into SWF A. SWF B loads SWF’s C..Z and I thought that that caused the problem. Only I knew that SWF B already contained the line:

System.security.allowDomain( "*" );

so that couldn’t be it.

When SWF B has loaded it reads a couple of _root variables (normally set by Javascript) to setup its configuration. Because SWF A now loads SWF B instead of Javascript I set the _root vars in SWF A. After a while of debugging this seems to be the problem. SWF B is -by default- not allowed to access _root vars of SWF A. So I added the same line to SWF A et voila!

System.security.allowDomain( "*" );

Our Floorplanner is gaining momentum! Since the release last April more than 200.000 users have registered and every day more and more new users are signing up.

And consumers are not the only ones interested. A lot of companies have found their way to us with requests for custom work. Various internet portals, broadcasting firms and real estate agents are just a few of the interested parties. They all are looking for a custom version of the Floorplanner with things like custom furniture libraries, a different look & feel or advertising opportunities.

To keep up with the demand, and to create all the other stuff we can think of, we want to expand our development team. So if you are a Flash guru, a PHP or Ruby on Rails super star and you want to work at a highly innovative and creative internet startup in Rotterdam, the Netherlands drop me a line!

For the project V-Factor we integrated a couple of Floorplanner widgets into their site. We used iframes to embed the widgets into the pages. You can click on the link next to the widget to get a better view of the floor plan. A new window with a full screen Floorplanner is opened.

On Firefox and Safari everything runned like a charm, but when we tested it on Internet Explorer it sometimes crashed. And it crashed hard, IE shuts down completly (after it alerts that Flash9d.ocx is to blame). Stange that the Flash Player can crash IE…

Anyway, we still havn’t figured out the exact cause. We have two theories. The first is that IE doesn’t like embeded Flash content via an iframe in multiple windows. The other theory is that IE doesn’t like different ways of embedding Flash content in multiple windows. The page contains more Flash content then our widgets. It has a banner and some animated buttons. We use SWFObject but the banner and the buttons are using the old skool object-tag.

Phew… we kind of solved the problem by opening the full screen floor plan in the same window as the widgets. That way we don’t have multiple windows open with flash content. But it’s not a real solution of course.

To be continued…

Papervision3D training is coming to Europe!
The 2 day workshop will be in Amsterdam, The Netherlands on October 8th and 9th, and will be hosted by Ralph Hauwert.

Read more here.