When will I learn this: Whenever anything turns out to be undefined (except the getBounds-object, which tracelines as undefined even when it's not, in line with Macromedia's no-logic-policy), be sure to put it in a setInterval, even if all bytes are loaded, and even if it displays correctly. setInterval should always be the first option. Final lesson learned in this respect involves the ScrollPane component. The method to access the content of the ScrollPane in Flash 8 is simply
scrollPaneInstance.contentThis works like a charm in the fla in which it resides, but when called from outside, content is undefined although scrollPaneInstance is very defined. I created a separate method for changing a property of the content, called it with setInterval, and everything works again perfectly. I do realise that the content isn't necessarily loaded even if the ScrollPane is, however, when bytesLoaded equals bytesTotal, it really wouldn't be way off if that meant everything was loaded, including the content. Further, can it possibly be necessary that absolutely everything is completely asynchronous? Maintaining code-readability in this framework is a job on its own.
Dette er en julekake. Lypsylen ved siden av illustrerer strørrelsesforholdet. Det er nemlig ikke småkaker det er snakk om når italienere gir hverandre julekaker. Alle må gi en slik kake til alle de har et høflighetsforhold til. Som innvandrer er ikke jeg like rammet, men jeg fikk for eksempel en av husvertinnen, og har selv tenkt å gi en til yndlingsnaboene.
Det skal ikke mye fantasi til for å se for seg at når julaften kommer, sitter alle på et lite lager av disse kakene. Som bildet illustrerer, kan det bli ganske mange kilo kake. Selv ikke et eks-snopefantom som meg klarer å forestille seg at det er mulig å spise opp så mye kake. Det innrømmes riktignok at det hender kakene ender opp med å gå på rundgang, for å redusere oppsamlingsvolumet noe. Allikevel. Jeg mistenker at det ligger en forholdsvis stor mengde kake i søppeldunkene rundtomkring når julen nærmer seg slutten, og at det sitter noen fornøyde, søkkrike kakeprodusenter og gliser fra øre til øre.
My collegue and I are convinced that Flash 8 (and previous versions) contains severe bugs that delay our work quite significantly. Today for example, I had updated the class Task by adding a method called setState(newState:Number). The method was called from elsewhere in the application. I sent my collegue (Nils Magnus) the updated files, but he kept getting an error message saying that setState-method does not exist. The following is an abbreviated version of the subsequent conversation we had on msn:
Nils Magnus @ Bergen sier:
nope. Still error.
Laila sier:
huh??
Nils Magnus @ Bergen sier:
yep. I even restarted Flash this time
Laila sier:
but... open Task.as. Do you see the method setState there?
Nils Magnus @ Bergen sier:
yes
Laila sier:
well, that's the one...
Nils Magnus @ Bergen sier:
yes...
Laila sier:
It's got to be Flash that's messing up...
Nils Magnus @ Bergen sier:
I dunno...
Laila sier:
The method's there. And the error message says it's not. And I don't get the error.
Nils Magnus @ Bergen sier:
But is it being included? Task.as?
Laila sier:
But it's a class. Shouldn't have to be included if it's on the classpath.
Nils Magnus @ Bergen sier:
true. I don't understand a thing...
Nils Magnus @ Bergen sier:
are you sure you don't keep it under "classes" in docs and settings at your place?
Laila sier:
but if it can't find the class, you should get a million errors. But no, I didn't put it there. It's all in the same folder.
Laila sier:
what if you remove the line that calls setState and see if it compiles.
Nils Magnus @ Bergen sier:
k
Nils Magnus @ Bergen sier:
yep, compiles now
Laila sier:
try to call setState from Task's constructor... To make it realise that the method is there somehow...
Nils Magnus @ Bergen sier:
ok
Nils Magnus @ Bergen sier:
no error message now, when I called it from the constructor
Laila sier:
try to add the code in the original place again.. maybe it has cleared out its cache or something now...
Nils Magnus @ Bergen sier:
ok
Nils Magnus @ Bergen sier:
flash #%¤#%"
Laila sier:
it sucks
Nils Magnus @ Bergen sier:
we should create a hate-list and send it to Macromedia
Laila sier:
and demand they pay us for lost work time
Nils Magnus @ Bergen sier:
and blog it.
Laila sier:
yea.
Nils Magnus @ Bergen sier:
guess what.
Laila sier:
still not working...?
Nils Magnus @ Bergen sier:
nope, now it works.
Nils Magnus @ Bergen sier:
!"¤#"!!"#
Nils Magnus @ Bergen sier:
(inappropriate expression)
Laila sier:
jesus. It's like we need to trick Flash into actually *reading* the code.
Nils Magnus @ Bergen sier:
I can't believe it!! I even restarted Flash!
Laila sier:
pathetic.
And guess what, it's not the first time we've had this kind of experience. I've commented out, cut away, deleted code, and witnessed how it's still being compiled and run. This causes predominantly two kinds of problems:
- Like the above conversation reveals, we believe Flash might have a point, and start looking for the error, thus spending time looking for an error that's not there.
- When our code is in fact buggy, we (at least I) tend to blame Flash, and keep restarting apps and computers and try to trick Flash like in the above conversation, in the hope that the error will go away. Obviously it doesn't, and time has again been wasted.
The ComboBox component in Flash does not behave as expected if used in a movieclip loaded by loadMovie or attachMovie. What happens is that the ComboBox won't open, as if it doesn't react to events. The problem
has been discussed, and I managed to find the following suggestions:
- Drag an instance of the component onto the stage of the movieclip that's loading the movieclip containing the ComboBox. It can then be deleted, the point is that the loading movieclip has the component in its library. This appeared to solve the problem for a lot of people.
- Use loadMovieNum instead of loadMovie
- Attach the ComboBox with ActionScript instead of placing it in a movieclip
- Randomly rename the combo, movieclip, file etc until it mysteriously starts to work (worked for one guy, though may not be the most robust solution)
I tried all of these without luck, the damned ComboBox wouldn't open. In the end, I noticed by coincidence that the Combo did in fact open, just that the drop-down dropped down
behind anything else on the stage. Thus, if I had no background images or other assets on stage, the ComboBox worked as expected. This wasn't an acceptable solution, and I ended up placing the whole Combo-scenario on its own frame on the main timeline, thus avoiding the loadMovie-problem - fortunately the nature of the application made that a possible solution.
From what I understand though, this is a bug in the ComboBox/loadMovie-features, and it puzzles me that Macromedia didn't fix it in the newly released Flash 8. From the newsgroups it seems that the problem has been around for a while, and in the cases that it doesn't work placing the Combo in the library of the main clip, there seems to be no workarounds. I don't know what I would have done if I hadn't been able to place it on a frame on the main timeline.
