Flash image gallery



  • I have a tendency to end up in interesting jobs with horrible side tasks, such as fixing legacy programs. I thought the wall-sized (they had it printed!) LabView program at my previous job was bad, but this Flash-based image gallery beats it 10-0.

     The purpose is simply to present a bunch of images, and associated text when clicked. The solution (by an intern)  was to copy-paste 100 lines per code per every single image, across dozens of files. Not only that, but the code happens to be buggy, causing Flash to hang every few minutes of use. Apparently ActionScript 3 has changed the behaviour of garbage collection, causing Tweens (animations) to be garbage collected before they end. One can only wonder why Flash would do that, it can't be that hard to just automatically keep a reference to running objects.

    I have been fixing the bugs with an automatic Python program. But the real bastard is the Flash IDE which locks your code inside, so no script can automatically process it. I ended up monitoring the clipboard from python and going through the scripts in a ctrl-a ctrl-c ctrl-v sequence.

     Now just to invent some reasons to rewrite the thing in HTML and JavaScript and some excuses for why it wouldn't play in IE...



  • @jpa said:

    Now just to invent some reasons to rewrite the thing in HTML and JavaScript and some excuses for why it wouldn't play in IE...

    Why wouldn't it play in IE? Unless you're thinking about HTML5 there isn't anything that wouldn't work in IE.

    There are differences between IE and anything else though, you just have to know them.



  • Next you are going to complain that it's not possible to read word documents without winword.exe

    But at least Flash changed the fileformat in c5, it is now xml based.



  • @henke37 said:

    Next you are going to complain that it's not possible to read word documents without winword.exe

    But at least Flash changed the fileformat in c5, it is now xml based.

    Word documents are presentation data though, actionscript is a programming language. Every other programming language uses text files, so why isn't flash?



  • @Lingerance said:

    [...]Every other programming language uses text files, so why isn't flash?
     

    Piet does not!



  • @morbiusreader said:

    Piet does not!
     

    The Pi calculator from the examples page is exceedingly awesome.

    Naturally, a more accurate value can be obtained by using a bigger program.



  • @dhromed said:

    @morbiusreader said:

    Piet does not!
     

    The Pi calculator from the examples page is exceedingly awesome.

    Naturally, a more accurate value can be obtained by using a bigger program.

    An impressive piece of work, yes. "World Hello World" is nice too.

    Meanwhile, should I ask for an explanation of your current signature? Please don't say "I like turtles"...



  • Because the guy who wrote the code was too stupid to use classes? Classes in actionscript are not stored in the fla, but in separate text files.



  • @Zecc said:

    Meanwhile, should I ask for an explanation of your current signature? Please don't say "I like turtles"...
     

    El_Heffe posted a captcha with the words "disapproving turtle", and represented this malcontent reptile with his mouse in Photoshop. I found this amusing enough to signify.



  • @SlyEcho said:

    @jpa said:
    Now just to invent some reasons to rewrite the thing in HTML and JavaScript and some excuses for why it wouldn't play in IE...

    Why wouldn't it play in IE? Unless you're thinking about HTML5 there isn't anything that wouldn't work in IE.

    Because he's not insane enough to "fix" his perfectly good code to work in a broken browser.


  •  In a short while I'm going to investigate why jQuery's fadeOut() won't do anything in IE8.

    It's probably a conflict with some other thing, but hey, one has to know.



  • @SlyEcho said:

    Why wouldn't it play in IE? Unless you're thinking about HTML5 there isn't anything that wouldn't work in IE.
     

     Hahaha, funniest joke of the week.



  • @henke37 said:

    Because the guy who wrote the code was too stupid to use classes? Classes in actionscript are not stored in the fla, but in separate text files.

    Unless the code is bound to Flash objects (and sadly, it probably is as that would up the WTF factor), you could just trivially copy the code out of the FLA and into some AS classes. You only need like 3-4 lines of wrapper to make FLA code "portable."

    The Real WTF, of course, is using Flash as an IDE at all. It's like they go out of the way to make things as difficult as possible. There's not even such a thing as a "project file", so there's no way to tell Flash, "hey, save these three AS classes if they have changes before compiling the movie-- thanks!" It's like going back in time to 1998.

    Until Adobe bought Flash, I thought that Macromedia's Flash 8 couldn't possibly get any worse. Oh man was I wrong.



  • oops, i misread the subject as "Flesh Image Gallery".  Moving along now.



  • @henke37 said:

    Next you are going to complain that it's not possible to read word documents without winword.exe

    But is it possible to edit word documents without randomly breaking some formatting somewhere?

    Good to hear that the new versions use XML.



  • @Medezark said:

    oops, i misread the subject as "Flesh Image Gallery".  Moving along now.

     

    It could still be that.

    Be patient.



  • Actually, word documents are also xml based these days. Just like the new flas. They are both a ziped bunch of xml files.



  • @Lingerance said:

    Every other programming language uses text files, so why isn't flash?
     

    Old versions of Visual Basic used to use some compressed binary format for storing source code.  GW-BASIC used to save in binary format by default but you could ask it to save in text format if you wanted.  See also Source Code in Database.  Anybody have any other examples?



  • @jpa said:

    Good to hear that the new versions use XML.
    Don't worry, it's just a direct XML translation of the old binary format.



  • @ender said:

    Don't worry, it's just a direct XML translation of the old binary format.
     

    Like, <flash_file><[CDATA[ %binary shit% ]]></flash_file> ?

     

    That would be an awesome wtf.



  • @dhromed said:

    @ender said:

    Don't worry, it's just a direct XML translation of the old binary format.
     

    Like, <flash_file><[CDATA[ %binary shit% ]]></flash_file> ?

     

    That would be an awesome wtf.

     

     That is actually how Office 2007 sometimes worked, and the mail reason OpenXML wasn't accepted at first (and Office 2007 doesn't implement the OpenXML standard, 2010 only half does).

    If something wasn't ported to the new format or the software couldn't figure out  they just embedded the binary old format in the zip file and referenced it in the XML format. I read a blog post once that showed it very well, but unfortunately I can't find it anymore.



  • @dtech said:

    That is actually how Office 2007 sometimes worked, and the mail reason OpenXML wasn't accepted at first
    They didn't actually do that, but they did basically just translate all of their binary codes to XML properties - including stuff like "render like Word 97". The ISO OOXML standard is much closer to ODF, however there is currently no program that implements it (I remember reading somewhere that Microsoft promises that Office 15 will support it).



  • @jnz said:

    @Lingerance said:

    Every other programming language uses text files, so why isn't flash?
     

    Old versions of Visual Basic used to use some compressed binary format for storing source code.  GW-BASIC used to save in binary format by default but you could ask it to save in text format if you wanted.  See also Source Code in Database.  Anybody have any other examples?

    There's good ol' HyperCard, of course!

    And pretty much every non-computer device that allows programming. For example, a TI-BASIC program isn't stored in a text file, since TI calculators don't (or didn't, when I worked with them) have a filesystem. It was just a long-ass string variable.



  • @dtech said:

    @dhromed said:

    @ender said:

    Don't worry, it's just a direct XML translation of the old binary format.
     

    Like, <flash_file><[CDATA[ %binary shit% ]]></flash_file> ?

     

    That would be an awesome wtf.

     

     That is actually how Office 2007 sometimes worked, and the mail reason OpenXML wasn't accepted at first (and Office 2007 doesn't implement the OpenXML standard, 2010 only half does).

    If something wasn't ported to the new format or the software couldn't figure out  they just embedded the binary old format in the zip file and referenced it in the XML format. I read a blog post once that showed it very well, but unfortunately I can't find it anymore.

    You can't have 100% compatibility without 100% feature parity, and right now no product has 100% feature parity with Office. Until something does, coming up with a standard office document format is a waste of time... coming up with a least-common-denominator format (like a better RTF) might make sense, but that's not what the open standards camp was howling for, they wanted Office's default format to be the woefully inadequate ODF.

    I mean, there are philosophical arguments up, down, left, and right but when push comes to shove, Office pretty much either had to:
    1) Completely abuse an existing format, basically doubling (or more) the constructs to store the data Office requires
    2) Butchered their own suite by removing features

    When you consider how the open format people would have reacted to option 1, and customers to option 2... well, the situation pretty much defines "between a rock and a hard place."

    It also didn't help that the ODF format, at the time this all went down, was completely useless-- it didn't even define a standard set of spreadsheet formula functions!



  • @blakeyrat said:

    For example, a TI-BASIC program isn't stored in a text file, since TI calculators don't (or didn't, when I worked with them) have a filesystem.
     

    So it's... and embedded.. device...

    that does...

     

    does not have...

     

    a..

     

    a..

     

    ....filesystem



  • @jpa said:

    But the real bastard is the Flash IDE which locks your code inside, so no script can automatically process it.

    You just need to use the right script. Try JSFL:

    http://livedocs.adobe.com/flash/9.0/main/flash_cs3_extending.pdf

    That is the way to fully script the IDE and do stuff like pull out tons of crappy code from movieclips.



  • @dhromed said:

    @blakeyrat said:

    For example, a TI-BASIC program isn't stored in a text file, since TI calculators don't (or didn't, when I worked with them) have a filesystem.
     

    So it's... and embedded.. device...

    that does...

     

    does not have...

     

    a..

     

    a..

     

    ....filesystem

     

    Well, fuck.



  • @blakeyrat said:

    I mean, there are philosophical arguments up, down, left, and right but when push comes to shove, Office pretty much either had to:

    1) Completely abuse an existing format, basically doubling (or more) the constructs to store the data Office requires

    2) Butchered their own suite by removing features
    Why?  They don't have to do either to save to RTF format.   (Well, they kind of do 1, but that's their own issue.)  Just strip out all the extra junk when saving to the lower format, it makes for a much more portable file.



  • @Xyro said:

    @blakeyrat said:

    I mean, there are philosophical arguments up, down, left, and right but when push comes to shove, Office pretty much either had to:

    1) Completely abuse an existing format, basically doubling (or more) the constructs to store the data Office requires

    2) Butchered their own suite by removing features
    Why?  They don't have to do either to save to RTF format.   (Well, they kind of do 1, but that's their own issue.)  Just strip out all the extra junk when saving to the lower format, it makes for a much more portable file.

    Well:

    As I mentioned, the activists (and potentially the EU government, when this issue comes up next) wouldn't be satisfied until the *default* file format was an open format. Office can already export to ODF, but (as you implied) it has the potential of shaving off a lot of content from the document. (It's not "junk" you know, it's genuine features that ODF doesn't have a way of describing.)

    The real issue though is that the file format is 95% of the program specification. Unless programs A and B have feature parity, they can't possibly share a single file format without one of them stripping out features used by the other. (Or, more likely, both of them stripping out features used by the other.) This isn't a big deal in the open source world, because the chosen format, ODF, was created using the feature-set of the most feature-ful open source office suite, OpenOffice.

    Of course, even then, it limits what features other office suites can implement-- want to add a new feature that needs to be saved in the file? Well, spend 3 years arguing for it in front of a standards committee and you might be lucky enough to get permission, or you break the format and the other editors blacklist you. And 3 years is assuming the ODF committee is fast-- if they're like the Java committee, or the W3C, then you're fucked. That amounts to "no new features, ever."



  • @jnz said:

    Anybody have any other examples?
     

    I think Visual Foxpro (Dbase) used its own database files to store the sourcecode. I think I even wrote some selfreferencing code using that "feature". Eek.

    @dhromed said:

    Naturally, a more accurate value can be obtained by using a bigger program.

    That is the awesomest quote I've seen all year.



  • @blakeyrat said:

    The real issue though is that the file format is 95% of the program specification. Unless programs A and B have feature parity, they can't possibly share a single file format without one of them stripping out features used by the other. (Or, more likely, both of them stripping out features used by the other.)
     

    Actually, that's not really true.  Example: Software A has spellcheck; Software B doesn't.  There's no feature parity, but they can still exchange document formats without data loss. 

    Shared document formats require parity of content features, or at least that each editor fails gracefully on and doesn't delete content that it doesn't support (sort of the way that web browsers are supposed to simply ignore HTML attributes and tags that they don't support without dying messily, and a good HTML editor won't strip out your PHP tags even when the client's secretary edits a file in WYSIWYG mode.)

    On the flip side, content manipulation features (spell check, auto-sorting of lines or table rows, etc) don't have to match in any way across editors in order for them to share a file format.



  • @sprained said:

    Actually, that's not really true.  Example: Software A has spellcheck; Software B doesn't.  There's no feature parity, but they can still exchange document formats without data loss. 

    Right up until the user hits "hide spelling errors in this document". Now the editor without spell-check will probably overwrite that setting when it saves the file, oops, data loss. Sure, losing that setting is not going to shake the Earth to its foundations, but data loss is data loss. (I'm actually pretty sure Office can keep document-specific dictionaries, also. Which would be a lot more annoying to lose.)

    @sprained said:

    (sort of the way that web browsers are supposed to simply ignore HTML attributes and tags that they don't support without dying messily, and a good HTML editor won't strip out your PHP tags even when the client's secretary edits a file in WYSIWYG mode.)

    The parser in HTML (generally) never has to re-save the parsed version, so that's something of a special case that doesn't apply to office documents.

    But let's take your example, let's say you're using a WYSIWYG editor on a HTML file with embedded PHP code. The editor doesn't know about the PHP code, so it ignores it-- so good so far.

    Now you grab an item in the HTML, say a table, and you copy it and you paste it elsewhere. Now the editor's in a pickle... in front of and behind the table was a <?php SortThisTable();> tag, and it doesn't know what the hell to do with it... does it copy unknown tags both before and after a selection? Does it copy just the ones before? Or maybe just the ones after? Should it copy the unknown tags in the center of the selection, or leave them in-place? It has no idea!

    So now your secretary pastes the table in the new location, and blam, it's busted. The PHP just spits out parser errors.

    @sprained said:

    On the flip side, content manipulation features (spell check, auto-sorting of lines or table rows, etc) don't have to match in any way across editors in order for them to share a file format.

    But they kind of do. Otherwise, next time when I open the file and insert a new table row, it won't get resorted correctly. And the fucking thing keeps underlining words, even though I told it not to spell-check this document already. etc. And now the printer settings are all screwy, look at that, it's not printing back-to-front anymore.

    As a user, this stuff is all *completely broken* to me, and I have no idea why-- after all, all I did it edit it in another program for a couple minutes, it looked fine!



  • @blakeyrat said:

    As a user, this stuff is all completely broken to me, and I have no idea why-- after all, all I did it edit it in another program for a couple minutes, it looked fine!
     

    Welcome to Microsoft Word. (I assume "another program" means "another computer" - DOC files seem to break when edited on different computers (probably due to fonts, printer settings, alignment of the planets and the compentence of the original creator) even when both have the same Office suite version installed)

    @blakeyrat said:

    @sprained said:
    Actually, that's not really true.  Example: Software A has spellcheck; Software B doesn't.  There's no feature parity, but they can still exchange document formats without data loss. 

    Right up until the user hits "hide spelling errors in this document".

    The document needs to store the language settings used too. Once we got a document from a client with some paragraphs set to "Spanish (Nicaragua)" some "English (US)" and others "English (Australian)". No idea why, since it was an Australian company and all the words were in English. The formatting was broken too, with random page breaks and text off the edge of the page.



  • Honestly, the new fla format has a folder called "bin". In there you can find .swf, .swc and .dat files, all with useful names like "1.swf" and "1.dat". It's mostly uninteresting stuff. Component caches and what not. But yeah, it's still a complete disaster trying to figure out what the files does.



  • @blakeyrat said:

    Right up until the user hits "hide spelling errors in this document". Now the editor without spell-check will probably overwrite that setting when it saves the file, oops, data loss.
     

    I dunno if you want to use that as an example.  It would be absolutely trivial to create a document format spec that allows for arbitrary document-level (or anything-level, really) properties that are defined not to be changed if they are unknown.  It would be up to the implementor not to screw it up and abuse it, but that's always true of specs.  Rather than an analogy of HTML with embedded PHP (or is it PHP with embedded HTML?), think of an HTML document with a separate CSS file.  Each CSS statement can be thought of as an independent property of the selected elements, and adding, moving, removing, or ignoring the statements is pretty straight-forward.

    The real tricky part with features-vs-ways-to-save-them would be with increasingly ridiculous features that are pretty questionable in a word processing or spreadsheet document anyway, such as embedded interactive OLE links to embedded Access forms containing embedded IE windows or some such mishmash.  But hey, if it's possible to do cleanly in proper HTML, it should be able to be done cleanly in a proper document spec.

    In any case, I would argue that plain and simple documents are the common case, and should be supported in a plain and simple way.  If the crazy feature stuff is necessary, then save it back in a proprietary binary format. Such a compromise wouldn't necessarily be the best solution, but it would take care of a lot of the headaches induced by portability concerns. 



  • @Xyro said:

    @blakeyrat said:

    Right up until the user hits "hide spelling errors in this document". Now the editor without spell-check will probably overwrite that setting when it saves the file, oops, data loss.
     

    I dunno if you want to use that as an example.

    If there's one thing I've said about 90 krajillion times on this forum, it's: "don't pay attention to the example, pay attention to the point of the post." If it's a bad example, then fine, ignore it, and think about what I was actually saying.

    @Xyro said:

    Rather than an analogy of HTML with embedded PHP (or is it PHP with embedded HTML?), think of an HTML document with a separate CSS file.  Each CSS statement can be thought of as an independent property of the selected elements, and adding, moving, removing, or ignoring the statements is pretty straight-forward.

    Except the embedded PHP example is more pertinent. The point is that some documents need markers in the document itself, and a naive editor won't have any clue what to do with markers it doesn't understand when you copy/paste/move/duplicate text.

    @Xyro said:

    The real tricky part with features-vs-ways-to-save-them would be with increasingly ridiculous features that are pretty questionable in a word processing or spreadsheet document anyway, such as embedded interactive OLE links to embedded Access forms containing embedded IE windows or some such mishmash.

    Just because you don't use the feature doesn't make them ridiculous. Also, just because the feature isn't popular (presuming it isn't) doesn't make it acceptable for Office 2010 to have fewer features than Office 2007, all to make some file format-obsessed nutcases happy.

    @Xyro said:

    But hey, if it's possible to do cleanly in proper HTML, it should be able to be done cleanly in a proper document spec.

    Possibly, but at the rate the W3C moves, it'll be 50 years before everything Word/Excel/PowerPoint does will be able to be done cleanly in HTML. They're nowhere even remotely close now.

    @Xyro said:

    In any case, I would argue that plain and simple documents are the common case, and should be supported in a plain and simple way.  If the crazy feature stuff is necessary, then save it back in a proprietary binary format. Such a compromise wouldn't necessarily be the best solution, but it would take care of a lot of the headaches induced by portability concerns. 

    That's good, and that's what exists now. (Although admittedly the interchange formats like RTF and CSV all really really suck.)

    But you're not the one I'm really talking about. I'm talking about the bozos who were campaigning the EU to force Microsoft to adopt a standard file format or face fines.



  • Why are you trying to edit the fla file directly? As I already mentioned in between all the off topic office file format ramblings, Flash has a perfectly good scripting feature (straight javascript, not proprietary crap) built into the application. There is no reason to directly mess with the fla.



    Use the right tool for the job.



  • @filet0fish said:

    Why are you trying to edit the fla file directly? As I already mentioned in between all the off topic office file format ramblings, Flash has a perfectly good scripting feature (straight javascript, not proprietary crap) built into the application. There is no reason to directly mess with the fla.



    Use the right tool for the job.
    Because the IDE sucks like you wouldn't imagine, and it gets worse with every release.

    Several years ago, I did a lot of Flash programming just for fun; it was one of the last reasons I kept a Windows computer around.  That fun ran out pretty quick when they started replacing all the native/semi-native GUI controls with Flash abominations that could barely keep up with my mouse.  Ugh.

    Oh, also, read the OP.



  • @filet0fish said:

    Why are you trying to edit the fla file directly? As I already mentioned in between all the off topic office file format ramblings, Flash has a perfectly good scripting feature (straight javascript, not proprietary crap) built into the application. There is no reason to directly mess with the fla.



    Use the right tool for the job.

    I'm sure you're a Super-1337 Rockstar Uber Master Ninja, but normal people don't like learning entirely new languages to perform a simple one-time-only task. And even if it was "straight JavaScript" (which it's fucking not) you still have to learn the layout of the local DOM or equivalent.

    The right tool for the job in this case is a 18" or larger pipe wrench. Find the retard who programmed the original and apply it vigorously to the top of his head.



  • @filet0fish said:

    Why are you trying to edit the fla file directly? As I already mentioned in between all the off topic office file format ramblings, Flash has a perfectly good scripting feature (straight javascript, not proprietary crap) built into the application. There is no reason to directly mess with the fla.



    Use the right tool for the job.

    Suppose I was working for a construction company, and they had given me these threaded nails that for some reason cost hundreds of times as much as normal nails (or screws, for that matter). They're made by a company called Plaster, say. But my boss wanted to use them because they were a "Building 2.0" shop. So I haul the Dremel out and start grooving the heads of threaded nails, trying to get them to interface with a drill bit. All the while, I'm bitching about these idiot-nail-screw-things, about how everything Plaster makes is worthless shit.

    Also the threads are real tacky somehow (materials science ftw), so they drive very slowly and waste a lot of power, heating up the drill and shortening its life. If you try using it with any decent sort of wood (say, that of the Linux trees, or god forbid, 64-bit wood of any kind), it's even worse. Structurally, the building is shit and also the build search engine companies can't grok it, so good luck finding studs once the drywall is up.

    In this situation, I would quit after grooving first few dozen screw-nails, assuming I even made it that far. (For some reason, there is often big money in this sort of work.)

    However, you, apparently, would smack me upside the head for dremeling them, say "use the right tool for the job", and start hammering the screw-nails into the wood, and then, presumably filling the holes with caulk to hold them in place.



  • @Joeyg said:

    @filet0fish said:
    Why are you trying to edit the fla file directly? As I already mentioned in between all the off topic office file format ramblings, Flash has a perfectly good scripting feature (straight javascript, not proprietary crap) built into the application. There is no reason to directly mess with the fla.



    Use the right tool for the job.

    Suppose I was working for a construction company, and they had given me these threaded nails that for some reason cost hundreds of times as much as normal nails (or screws, for that matter). They're made by a company called Plaster, say. But my boss wanted to use them because they were a "Building 2.0" shop. So I haul the Dremel out and start grooving the heads of threaded nails, trying to get them to interface with a drill bit. All the while, I'm bitching about these idiot-nail-screw-things, about how everything Plaster makes is worthless shit.

    Also the threads are real tacky somehow (materials science ftw), so they drive very slowly and waste a lot of power, heating up the drill and shortening its life. If you try using it with any decent sort of wood (say, that of the Linux trees, or god forbid, 64-bit wood of any kind), it's even worse. Structurally, the building is shit and also the build search engine companies can't grok it, so good luck finding studs once the drywall is up.

    In this situation, I would quit after grooving first few dozen screw-nails, assuming I even made it that far. (For some reason, there is often big money in this sort of work.)

    However, you, apparently, would smack me upside the head for dremeling them, say "use the right tool for the job", and start hammering the screw-nails into the wood, and then, presumably filling the holes with caulk to hold them in place.

    Suppose I were working for a construction company that made bad analogies...

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.