addEventListener

[Robin]

Like in javascript, subscribe to events using code.

PHP Code:

  function onCreated() {
    this.addEventListener("this.onWeaponfired", function() {
      player.chat = "Hi!";
    });
    showGUI();
  }
  function showGUI() {
    new GuiBitmapBorderCtrl("this.radiogui") {
      profile = GuiBitmapBorderProfile;
      canmove = false;
      canresize = false;
      height = 50;
      width = 385;
      x = screenwidth - width - 20;
      y = -50;
      visible = true;
      new GuiButtonCtrl("PlayButton") {
        x = 25;
        y = 5;
        alpha = 1;
        width = 50;
        height = 20;
        text = "Play";
      }
      new GuiButtonCtrl("MuteButton") {
        x = 25;
        y = 25;
        alpha = 1;
        width = 50;
        height = 20;
        text = "Mute";
      }
    }
    this.addEventListener("MuteButton.onMouseDown", function(MouseEvent) {
      echo(@MouseEvent.mousescreenx);
    });
  } 


etc. What say thee Stefan?

[Skyld]

Use function prototyping:

PHP Code:

MuteButton.onMouseDown = function ()
{
  //
}; 


PHP Code:

function onCreated()
{
  this.onWeaponFired = function ()
  {
    //
  }
}; 


Or even standard function definition:

PHP Code:

function MuteButton.onMouseDown()
{
  //
} 


[Robin]

So ECMAScript standards + gs2 =

[cbk1994]

Like Skyld said, it can be replicated easily. However, I guess it would be nice to have.

[Robin]

It's just that ECMAScript is a standard definition and It would be easier for new scripters to start if they didn't have to comb the wiki for information :P

[Inverness]

I've been scripting for quite awhile and I don't know what the *bleep* ECMAScript is. I doubt anyone knew to coding would either.

I even dislike the syntax of the example you provided. I think catchevent() works just fine and should be expanded to work with scripted events with a function throwevent() or so.

Script A:

PHP Code:

function doSomething() {
  //stuff
  throwevent(this.name, "DidSomething", params...);
} 


Script B:

PHP Code:

function onCreated() {
  this.catchevent("System", "DidSomething", "SystemDidSomething");
}
function onSystemDidSomething(params...) {
  //stuff
} 


[cbk1994]

I agree with Inverness, catchevent would work fine, just needs to be "fixed".

[Inverness]

I dislike how catchevent() requires the "on" part to be specified in the event name. Events already start with "on" by default so such a thing should be assumed I believe.

[cbk1994]

Originally Posted by Inverness

I dislike how catchevent() requires the "on" part to be specified in the event name. Events already start with "on" by default so such a thing should be assumed I believe.

But if it was expanded to dynamic events, then why should we be forced to start them with on?

[Inverness]

Originally Posted by cbkbud

But if it was expanded to dynamic events, then why should we be forced to start them with on?

I'm just pointing out how at the moment you would do something like:
this.catchevent("GraalControl", "onResize", "onGraalControlResize");
instead of:
this.catchevent("GraalControl", "Resize", "GraalControlResize");

Things like scheduleevent() and trigger() always prefix the event name with "on" to show that its an event so catchevent() should reflect that Graal event function names always start with "on"

I believe that should be fixed by Stefan and he should give people a warning ahead of time so they can fix their scripts.

[cbk1994]

Originally Posted by Inverness

I'm just pointing out how at the moment you would do something like:
this.catchevent("GraalControl", "onResize", "onGraalControlResize");
instead of:
this.catchevent("GraalControl", "Resize", "GraalControlResize");

I know what you're saying, but if it was expanded to dynamic, we could just have something that watches for another thing, but the other function also does stuff. For example,

PHP Code:

function onCreated()
{
  this.catchevent( ... );
}
function messWithStuff()
{
  do something lol();
} 


While messWithStuff() is still functional, we don't need to change it's name.

[Inverness]

Blah, all events should start with "on" in all cases. Anything handling event names shouldn't need the "on" in all cases.

It sounds to me like you're being lazy. Standards are something that should be practiced in coding.

[Robin]

Originally Posted by Inverness

I've been scripting for quite awhile and I don't know what the *bleep* ECMAScript is. I doubt anyone knew to coding would either.

ECMAScript is the standard that:

• JavaScript
• JScript (IE)
• JScript.NET
• ActionScript

Are based on.

Are you trying to say you've never come across any of these technologies?

That anyone knew to coding has not either?

Also @ Skyld:

function prototyping doesn't seem to work with gui events, but the rest of your examples do. Strange.

[Inverness]

Originally Posted by Robin

Are you trying to say you've never come across any of these technologies?

Heard of them, and thats it, never used them. However, that doesn't actually matter (IMO) because we could do what you're suggesting by adding a throwevent() function to work with the existing catchevent() without changing the format that its used in.

[cbk1994]

Originally Posted by Inverness

Blah, all events should start with "on" in all cases. Anything handling event names shouldn't need the "on" in all cases.

It sounds to me like you're being lazy. Standards are something that should be practiced in coding.

That's just personal preference. I think it's silly to have something like onBlowUpCar()