Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

(long and probably inflammatory -- you've been warned)

I'm trying to use Flash to create dynamic web content. I expected it to be more straightforward than it turns out to be (e.g., not throw away 400 years of Cartesian geometry -- for instance, was there something about the (0,0) coordinates being, you know, the center, that needed to be improved upon?) but I'm in pretty deep now...

I've been working with the SWF::Builder module, and beyond some early success at generating .swf files whose content can in fact be viewed in a Flash player, it's been rough going trying to get that content to look exactly the way I want it to look. (They tell me that people actually develop web sites using Flash but frankly I don't see how that's possible.)

As for the obvious question: why don't I just use XHTML and CSS? Well, it just has to be done in Flash. It doesn't matter why, it just does.

All I want to do is create a box with a header, text and an image, and have the text flow around the image:

----------------- |i'm a headline | |i am some text | | ___ | ||img| i'm text | ||___|thatwraps | |and i'm regular| |text text text | -----------------
The problem is that moving or resizing the box seems to automatically change the size of the content in the box -- and I have to do a lot of moving and resizing because there's no way to create a box of fixed size and fixed location. Change the box size and the box moves to another location and vice versa. I suppose this is unavoidable given that Flash sets the (0,0) coordinates to an arbitrarily moving point, but hey, I don't make the rules around here. Black = white? OK, no problem. Up = down? Fine, got it. 1 = 0? Whatever, I really don't care, just tell me what I have to do to make it work and I'll do it.

Meanwhile, lines of text don't wrap! They don't wrap around images, and they don't even wrap at the box boundaries. The text just forms a single line that flows ever rightward and eventually disappears, regardless of what dimensions the box is set to. I have to manually insert line breaks like some Ben Franklin-era typesetter, but even Ben Franklin didn't have to deal with a box that keeps moving and resizing itself! So now every time the box resizes itself I have to go in and manually change all the line breaks! And I have to do this for three separate blocks of text: the headline, the part of the text that should (but doesn't) "wrap" the image, and the part that doesn't/shouldn't wrap. Hang on, I think I have an X-acto knife and a jar of glue around here somewhere...

But there is an AutoSize property which I theorize I could set to "false" or "0" and hopefully make this autosizing behavior go away. And also a WordWrap and a Multiline property, either one of which may help getting the text to flow (à la PageMaker, c. 1985). The question is how to access it?

The docs are riddled with typos and nearly incoherent at some parts, but I gather that I need to use a SWF::Builder::Character::EditText object for my text, and the docs say:

$etext = $mc->new_edit_text( [$font, $text] ) returns a new basic dynamic editable text object. It has interfaces to + raw DefineEditText tag.
"It has interfaces." Good to know. Further down:
$etext->box_size( $width, $height ) sets the bounding box of the text and stops auto-sizing the box. When +either $width or $height is undef, it is unchanged. Fixing bounding b +ox may cause unexpected text clipping. You should set DefineEditText +flag Multiline and/or WordWrap. See SWF::Element.
"You should set..." Oh, should I? OK, I'll keep that in mind. No doubt when I "see SWF::Element" I'll find your detailed and lucid explanation of just how I should do that. Cool. I'm looking forward to it.

And

$etext->methos for SWF::Element::Tag::DefineEditText You can control details of the texts to call methods for DefineEditTex +t tag. See SWF::Element
"methos"??? This is gibberish, right? And by the way, that thing about "stops auto-sizing the box"? Well, no, it actually doesn't.

But no time to worry about that now, as the clues are pointing me toward SWF::Element, where I find a few things that seem relevant, but hardly anything that looks like perl. What, for instance, am I to make of this:

Tag::DefineEditText Type: Text field class lookahead CharacterID ID * Bounds RECT Flags $ WordWrap (Flags) Multiline (Flags) Password (Flags) ReadOnly (Flags) - HasTextColor (Flags) - HasMaxLength (Flags) - HasFont (Flags) AutoSize (Flags) - HasLayout (Flags) NoSelect (Flags) Border (Flags) HTML (Flags) UseOutlines (Flags) FontID ID FontHeight $ TextColor RGBA MaxLength $ Align $ LeftMargin $ RightMargin $ Indent $ Leading $ VariableName STRING InitialText STRING
The examples shown are pretty stingy with what they reveal:
$rect=SWF::Element::RECT->new;
and
$rect->configure(Xmin=>0, Ymin=>0, Xmax=>100, Ymax=>100); $element=SWF::Element::* ->new([parameters]);
Thanks, but I'm not in the mood for obfuscated code right now, I'm here to find out how to "set DefineEditText flag Multiline and/or WordWrap," as you indicated I should do, and I also recall reading
$etext->methos for SWF::Element::Tag::DefineEditText You can control details of the texts to call methods for DefineEditTex +t tag. See SWF::Element
and
$etext = $mc->new_edit_text( [$font, $text] ) returns a new basic dynamic editable text object. It has interfaces to + raw DefineEditText tag.
So now it's time to avail myself of these "interfaces," such as they are.

So, um... what interfaces??? I'm beginning to think this is some elaborate practical joke, along the lines of

package DWIM; # How to use this module is left as an exercise to the reader. 1;
But if not, it does beg the question: should I be attempting something along the lines of
$etext->Tag::DefineEditText->configure(AutoSize=>0,WordWrap=>1);
which mercifully does NOT work, because that would just be too ghastly. But what else am I supposed to conclude?

In closing, I'm convinced that there is some important information either missing, obscured or badly misstated, to the point where relying on the docs alone is pretty much a lost cause. I do have a couple of friends who possess psychic powers, but before I go that route, I was hoping one of you might be able to supply or explain what's missing.

Thanks. And I mean no disrespect by any of my comments. I'm frustrated, but trying to be good-humored about it. It's obvious the module's author is not a native speaker of English and I cannot fault him/her/you for that. Nevertheless, as written, the docs don't make sense and thus aren't useful. Sorry, but it's true.

Replies are listed 'Best First'.
Re: help deciphering SWF::Builder docs
by Anonymous Monk on Aug 28, 2007 at 01:52 UTC
      I will never understand the need some people have to be actively unhelpful. If you have nothing to offer, kindly just move along.

      To be clear: a link to the README explaining how to install the package is not helpful. I was not asking for help installing the package.

      And while I agree, and it is a given, that I need to "learn more", I positively defy you, Anonymous Monk, whoever you are, to explain what the author means by:

      "You should set DefineEditText flag Multiline and/or WordWrap"

      and explain exactly how to do it.

      Or, if you just want to be a smart-alecky link-poster, post a link to the part of the SWF::Element pod, to which the author refers, that explains it.