Conceptually, this kind of applications should have entities that supplies data (data provider) and links visuals to the data.

In your case data is questions/answers while visuals are TextField instances.

I would strongly advise against using dynamic classes (that allows for adding properties dynamically at runtime via associative array notation), especially in this kind of cases. While utilizing dynamic features sometimes is useful, in the majority of cases it present major headaches down the road and is very inefficient from performance standpoint.

Below is a fully functional class that accomplishes what you are looking for. Role of data provider is accomplished by the questions array. This is an array of objects that accomplish the linkages between questions, answers and TextFields at both configuration and user interaction phases. Read comments.

All features are dynamic except I use name “checkButton” for the submit button.

Theoretically this application asks for at least two more classes but, because you stated that you are new to AS3 – this is a sufficient beginning.

At last, you should get into a habit to declare as few variables as possible and NEVER declare variables in the loops. Declaring variables inside loop bodies is a pretty bad practice.

While waiting for Godot, I decided to show a more OOP approach to your application. It may be a bit difficult to digest at first, but if you have time and desire – look into what is happening and how things work together in the classes below.

To test – just put all the classes into the same directory as you FLA and make MainQuestions the document class.

I split functionality into 5 different classes. One of the OOP principals are to make objects very specialized. This approach presents with much better scalability.

Some of the highlights:

Document class became very small and it does only two things – places visuals on display list and monitors how user interacts with the button. Technically even these two aspects shouldbe delegated to another class but from illustration standpoint it is not very relvant.

Data is separated into a special class QuestionsData. It may not be apparent at first but this way you can get data different ways and not change a bit of other code that uses this data. For example, in the future you may want to decide to load data at runtime as XML. Still – your application will function the same way despite the fact that data acquisition, parsing and storage change.

I introduced shuffling capabilities in the QuestionsData class to randomize questions – it feels more natural for quizzes.

QuestionLine class is a display object that contains all visuals that pertain to a single question. Note how data is used. Also this class takes care of user entry validation.

Note that because of QuestionLine class, QuestionsContainer class doesn’t have to deal with specifics of question related visuals in depth. QuestionsContainer just creates QuestionLine instances and redistributes data. See init() method of QuestionsContainer.

QuestionTextFiled class. It feels a touch as an overkill but this class allows for unification of some shared functionality between TextFields that are used in QuestionLine. As a result – there is less coding on QuestionLine level.

There are some other tricks of the trade in the code but they are secondary.

As far as the original class goes - below is one of the ways to implement what you asked about.

I don't have time to do the same in the multiple classes implementation though. I trust you can do it yourself.

One piece of advice.

Conventionally, Classes are named starting with Upper case. It is prudent to name all variables and methods starting with lower case - this improves code readability. In your instance variable "Score" should be "score."