Yes.
Take the entire definition that starts:
LzText.prototype.construct = function ( parent, args ) {
add your code to that, and put it in a <script> block so that it
replaces the LFC definition.
On the assumption that there may yet be one last 3.x release, you
might get the svn masters to allow you to check in your change to
trunk also.
On 2007-06-27, at 14:19 EDT, Benjamin Shine wrote:
When you say "patch the LzText.prototype.construct method" do you
mean "override the LzText.prototype.construct method with a
modified version of what LzText.prototype.construct used to be"?
Again, may I please have more details on the pattern you are
suggesting?
On Jun 27, 2007, at 9:46 AM, P T Withington wrote:
You have described something akin to what we would _like_ our API
to be. :)
But, you can't really do what you want this way because you really
need to affect the initialization of each instance of an LzText
object. That is, you really need the event sender to be the
instance that is being inited, and you can't know that.
I think the best approach would be to "patch" the
LzText.prototype.construct method and send that out as a script
block. It would have to be the first thing that happened in any app.
On 2007-06-27, at 12:23 EDT, Benjamin Shine wrote:
In 3.3 and 3.4, how do I add an oninit handler to LzText? I want
to make the special font setup foo available to users of 3.3 and
3.4 without needing to re-release or re-compile the LFC.
Something like...
<script>
LzText.addDelegate( "oninit", function()
{ this.__LZtextclip.antiAliasType = "advanced" } );
</script>
...but I'm sure I don't have quite the right syntax. Please advise.
-ben
