Undolog.com

When "triggered" an event of an object context, which is the parent object that represents the scope of all variables, becomes the object itself. This feature, characteristic of Object Oriented programming, can be disorienting causing errors and bugs in the code. Moreover, in certain situations, can prevent access to some variables "before" available.

First of all we see a feature of ActionScript related to context management which, if included, will save us a few hours of unnecessary tests. When we have to do with graphics or simply MovieClips nested within each other, the property _parent , problem-solving context. For example, if the MovieClip padre_mc contiente figlio_mc another MovieClip and use the following code:

Risalisre the "father", then, is clear and immediate.

With pure classes, code-only, or extension of the MovieClip property _parent is not available and could complicate things! Immaginiiamo to have a class MyClass :

, ovvero il puntatore alla classe MyClass . The context of MyMethod() is, of course, this , that is the pointer to the class MyClass . . The variable num , for example, has a cycle of life enclosed within the method MyMethod() . It is therefore only visible within the method and will be destroyed on exit. . Same thing for the variable myObject that however initializes an event, in this case onLoad . lasciandoci, apparentemente, senza il puntatore alla classe madre myClass . When triggered onLoad() context will become myObject leaving, apparently, without the pointer to the parent class myClass . , ha lo stesso contesto della variabile myObject ! A closer look at the code we see that the variable cp , defined in the method myMethod() , has the same context of the variable myObject ! dell'oggetto myObject in quanto condivide con esso lo stesso contesto. In fact the variable cp (class pointer) will be visible within the method onLoad object myObject as it shares the same context. ha necessità di “vivere” più al lungo del previsto visto che ha “allocato” un evento (di tutto questo se ne occupa Flash a nostra “insaputa”). In fact the method myMethod() not just because the object is deallocated myObject has the need to "live" over the longer than expected because it has "allocated" an event (all of this is dealing with Flash at our "unknown").

Advice

For events associated with buttons or MovieClips a good habit would be to use the form:

In place of the more rapid and immediate:

The advantage of using an external function is to have a neutral context and the possibility to access the function regardless of the MovieClip that controls it. In the second case, for example, if I wanted to force the execution of the code linked to the "click" of the MovieClip should I use a code of this type:

In practice I call the event as if it were a method. However, I have - in fact - to have the MovieClip my_mc . Either way, however, I can run the code directly calling myOnRelease() . Obviously, as shown in the examples, eye to contexts. . In the first case the context of myOnRelease() is that of the object mother where it is written, for example _root . In the second case, instead, the context is always the MovieClip my_mc !

Forcing a different context

We conclude with a tricks useful in many circumstances. in grado di forzare un contesto di un metodo o funzione. Flash provides a library, mx.utils with an object Delegate can force a context of a method or function. Its use is very simple:

The event onPress my_btn the button points to a "new" function created precisely with the context my_mc. When you click on the button my_btn, the code executed in myFunction() will have as context my_mc!

This article was useful to you?:

Loading ...

• 

• Tweet