This morning I was looking forward to making some progress on a Specsavers application that I’m working on. I had been thinking about some of the finer details of how it was going to work last night and was ready to blast through the code and have a good portion of it written by the end of the day.
It was not to be.
I had an application class, and this application class would instantiate different child classes that were responsible for different “screens” depending on which “screen” the user had selected. This is an approach that I have used a thousand times before, so it really didn’t take much time to have all the code in place. However, when I published the application I found that it didn’t work. The first screen would load fine, but when trying to load the second screen I found that the application would just remain blank. What was going on? The file was compiling without any errors and all I was doing was instantiating different classes depending on a string ID. For all intents and purposes, the class that was failing to work was identical to the one that was working.
This was weird!
As I was using a method that I had used countless times before, I thought that perhaps the third-party wrapper that I was using was interfering with it so I stripped out its code. Nope, still didn’t work. I stripped out my recently-edited button manager class… nope, still didn’t work.
After stripping out everything apart from the absolute bare essentials and STILL ending up with only the first screen, I made a simple test file from scratch using different smiley faces as screens. Again, an application class called two other classes depending on which button I pressed, and each of these classes attached a different movie clip to the stage. It worked fine, as it had done so many times in the past.
So, what the hell was different between that and my non-functioning Specsavers app?!
I traced out the object variable that was being linked to the different screen classes and for the first screen it came back as [object object] as expected, but for the second screen it was coming back as undefined. I put a “wtf?” trace above and below the line that instantiated the second screen’s class and yep, they popped out in my trace so the line WAS being executed – it just wasn’t doing anything.
I went about transplanting the smiley faces code into my Specsavers app line by line and when finished, it worked. I then tried it again with the original class and once again I was met with a blank screen as once again it failed to work for me.
What the HELL was going on here?! My time was being consumed by a problem with attaching a movie clip to the stage! Was I missing something? Had I accidentally smoked a vast amount of weed before starting work that day?
In the end I had two classes – my original Specsavers class and my smiley face class – identical apart from one small detail. The Specsavers class was located within a subdirectory and was being imported at the top of the application class. The smiley face one was located within the same directory as my SWF and so did not need to be specifically imported at the top of the application class. The smiley face one worked while the Specsavers one did not.
I put the smiley face one inside the sub-directory and imported it – right there, it stopped working. I took the Specsavers one out of the sub-directory and put it into the same directory as the SWF and deleted the import line and yeah, it worked.
There was nothing special about the name of the sub-directory. It’s not a system name or a reserved name or anything like that.
So, to summarise, there is some kind of weird quirk that – for some reason – means that Flash treats classes that are imported slightly differently to those that aren’t. I’ve never come across this before and I have no idea if I’ll come across it again, but while searching for potential reasons for my non-functioning class on Google today only to find absolutely no clues at all, I hope this post might prove useful to someone else.
Recent Comments