One good practice is not to litter the timeline inside movieclips with code. When you want to go find some code to adjust something you may have to traverse movieclips several levels deep to get at the code in some frame. It becomes unweildly very quickly.

If you want to use the timeline, I would register the event listeners and also set the text of the button from the root timeline. I also would not use "frame labels" as they're very antiquated although usable.

To make your buttons I would make a movieclip (setting the base class of the clip to flash.display.Sprite for optimization) and include 3 layers. layer 1 background, layer 2 roll, layer 3 text. I don't see any "on" state mentioned in your code so I left that out. The roll or 'selected' and 'textfield' layers should have instance names so you can access them. For instance I'd name the selected state graphic to selected_mc and the TextField to text_txt.

If your button was named as you said back_btn then the code would look like this, remembering that the event passes a target property:

back_btn.addEventListener(MouseEvent.MOUSE_OVER, buttonRollOver);

back_btn.addEventListener(MouseEvent.MOUSE_OUT, buttonRollOut);

back_btn.addEventListener(MouseEvent.CLICK, buttonClick);

Sprite(back_btn.getChildByName('selected_mc')).visible = false; // make sure the initial selected state is invisible

TextField(back_btn.getChildByName('text_txt')).text = 'start text'; // change to the starting text of the button

The display list returns DisplayObject and DisplayObjectContainer so you always need to wrap things with the 'type' they are to access them properly. That's why I have Sprite() and TextField() wrapped around specific things. Doing that gives you access to their settings.

I'm not quite sure I follow but are you saying that you don't want the button to show up but it is? The roll is setting the visible property on the selected state so that will fire off every time you roll over it.

If the buttons are not supposed to show you should just initially set the .visible property of the entire button to false to assure it won't show up. You should also set the mouseEnabled property to false (and perhaps useHandCursor to false) so the user can't click it until you desire them to.

How you keep your references is completely up to you. If you never made a reference to the textfield or the movieclip (as a class variable or directly in a timeline script or such) then you'll have trouble accessing it.

This is AS2, it no longer works in as3: _root

I presume you're doing this in a frame script. I also presume you put a_mc and a_field in a frame manually by dragging it out of the library and onto the timeline.

First thing to do is make sure you have an instance name specified. You mtnioned you set up a_mc and a_field. Those need to be instance names and not the name of them in the library. Whatever you name them in the library is meaningless. Once you drag them into your timeline, click it and look at your properties panel. The first textbox is the instance name. Those must be set properly for this to work.

Here, I just keep re-using this screenshot I made to point out instance name which has nothing to do with your project but you get the idea:

Make absolutely sure you gave them names.

Then you need to always "type cast" which is a pain in the *** but is necessary. So for example you added correct instance names. You can literally:

If you do not put something on the timeline with the "Instance Name" (refer to graphic) as a_mc, then yes it will need to be created before you can use it. Otherwise no, you can directly use it if you put it on the timline. e.g. you clicked in a frame, clicked on the text tool, set it to dynamic text and had drawn a text box. Afterwards you named the text box instance something. You can then use that instance name directly in actionscript code.

However you did say a_mc and referred to it as a movieclip. So if that movieclip contained a dynamic text field, you'd need to go in a_mc and make sure the textfield had an instance name as well.

So lets say you have a movieclip on your timeline with the INSTANCE NAME of a_mc. Lets say inside that clip you had a textfield with the INSTANCE NAME of a_field. You could do this to dump the XML into it:

And you can just paste code in here really, although sometimes it comes out as tables and other weird stuff. Most of us actualy use the "HTML" button in the upper right and add in something like <pre> or <blockquote> or other tags to help make the code easier to read.

Do note the reason I put TextField() around the code above is because any time you request to get a child by its instance name (getChildByName()) it returns a generic "DisplayObject". It's really annoying that the method doesn't sense the original type of the object it returns and generically returns a "DisplayObject" but that is what it does. So by putting TextField() around it I "cast" it back into what I know it should be, a TextField class. Therefore the .text() method will be available. Just a side note...

The function fileLoaded is called by your XML loader telling it that it successfully parsed the XML. Once that happens, all the data in the XML is included in the event, which has the variable name of 'e'. So e.target refers directly to the loader that loaded the XML in the first place. So it's exactly like saying loader_ur.data to say e.target.data. You don't really need to keep a reference to loader_ur because the data is sent in the event.

This is typically why people use the e.target.data approach. You create a loader in the middle of a function. You know at the end of that functions life the variable is garbage collected. However until the listener fires off, it still exists. Once the listener fires off after successfully loading the document people don't typically have a global variable (like loader_ur) to reference at all. They just refer to e.target to access it. So they access the loaders XML using e.target.data. After that the loader is removed in the next garbage collection sweep. You never really needed to keep loader_ur around at all. It just takes up extra memory.

I think I already posted in that link (I don't have the URL to atm). I mentioned to show the PDF in a StageWebView instance and then it was made clear there was some acrobat scripting syntax that I wasn't familiar with. There were links mentioned that deconstruct PDFs and let you access things inside them but displaying a PDF and accessing data from it at the same time is another level of difficulty. Most APIs either just let you display the PDF or let you read its guts and reconstruct it. Reconstructing is what you appear to want so I'd go that route. It's a lot of work but it lets you convert an input from a PDF into an actionscript input that looks identical (when styled to do so) so you can access the data that way.

Otherwise this is not at all someone new to actionscript should be approaching. It's not "easy".

Reading the PDF and reconstructing it is no simple task, that's for sure. When I say reconstruct I mean literally reading all the contents on a particular page and rebuilding that in flash using what flash has. Text in TextFields, images in Loaders, etc etc. Then all that content needs to be position. Inputs will need to be TextFields with the .type property set to be an input. It's a ton of work.

Perhaps you could utilize a PDF to SWF converter?

Have a look at this article below to see some useful information on PDFs and Flash: