Using GuiMouseEventCtrl (See my last post for results)

[Kyuande]

How do you use this correctly?
I see in the default game, onMouseEnter/onMouseLeave/etc don't exist. Is there a better way to implement it without a loop or do I have to use a loop?

[Ad Bot]

[Gytyyhgfffff]

its really loving strange, it seems half broken because it doesn't seem to call yourGuiControl::onMouseWhatever(), it just only calls GuiMouseEventCtrl::onMouseWhatever(). i fixed it by packaging the actual GuiMouseEventCtrl::onMouseUp and added this:

Code: [Select]

function GuiMouseEventCtrl::onMouseUp(%this, %control, %eventModifier, %xy, %numMouseClicks)
{
Parent::onMouseUp(%this, %control, %eventModifier, %xy, %numMouseClicks);

if(%this == yourMouseControl.getId())
{
whatever
}
}that seemed to work, but idk if it's the best way to do it

[Kyuande]

Yeah, doesn't work with no add-ons, it looks like RTB does something with it, but I wonder how the loop is even starting.

[Zeblote]

its really loving strange, it seems half broken because it doesn't seem to call yourGuiControl::onMouseWhatever()

What? It does for me

How do you use this correctly?
I see in the default game, onMouseEnter/onMouseLeave/etc don't exist.

They are callback functions. You have to implement them for your control, and the engine will call them

[Shift Kitty]

Tested this, made a GuiMouseEventCtrl object named tester, and gave it it's own ::onMouseDown function.
The game did not ever attempt to call it. It would only call the parent, GuiMouseEventCtrl::onMouseDown.
If there's any case where this actually works, it's probably due to an add-on. I've tested this after removing any add-on that packages the function.

Alright guys listen up, there are a lot of weird things you are going to encounter with guiMouseEventCtrl and I only discovered all of this by using them extensively for the last couple of years.

Bug 1: guiControl::setName() does not automatically associate a guiMouseEventCtrl with the various ::onMoulove() functions that you would expect to be called.  This means that if you create a guiMouseEventCtrl in the gui editor, and then name it "mymousecontrol" or whatever, it will not call mymousecontrol::onMoulove() for that mouse control.  You can fix this by doing a cut-paste of the mouse control in place.  That way it is created already with a name, and will work correctly.

Bug 2: guiMouseEventCtrl::onMouseMove() and the drag functions are only called on one axis at a time.  This means that if you move your mouse on a diagonal, you will get two calls for ::onMouseMove() in a row.  One of them will be for the change in x, one for the change in y.  This means that if you try to make a paint program or something, the user will see something that looks like steps when they try to draw a diagonal line.

There are also a lot of subtle ways the mouse controls handle entering and leaving that may or may not be considered bugs but are extremely complex.

Edited to prevent misinformation.

[Zeblote]

That doesn't sound good at all, I'll have to test this again

[Nexus]

Alright guys listen up, there are a lot of weird things you are going to encounter with guiMouseEventCtrl and I only discovered all of this by using them extensively for the last couple of years.

Bug 1: guiControl::setName() does not automatically associate a guiMouseEventCtrl with the various ::onMoulove() functions that you would expect to be called.  This means that if you create a guiMouseEventCtrl in the gui editor, and then name it "mymousecontrol" or whatever, it will not call mymousecontrol::onMoulove() for that mouse control.  You can fix this by doing a cut-paste of the mouse control in place.  That way it is created already with a name, and will work correctly.

Bug 2: guiMouseEventCtrl::onMouseMove() and the drag functions are only called on one axis at a time.  This means that if you move your mouse on a diagonal, you will get two calls for ::onMouseMove() in a row.  One of them will be for the change in x, one for the change in y.  This means that if you try to make a paint program or something, the user will see something that looks like steps when they try to draw a diagonal line.

There are also a lot of subtle ways the mouse controls handle entering and leaving that may or may not be considered bugs but are extremely complex.

[Kyuande]

Hm, currently just doing 50ms schedules per loop and packaging GuiMouseEventCtrl::onWake so it replays the loop; the loop will end when the mouse control isn't awake. This only works for onMouseEnter and onMouseLeave.

Every single one of them is broken, not sure why.

Nevermind, got it working now. I tried this in general.

Code: [Select]

function GuiMouseEventCtrl::onMouseLeave(%this,%modifier,%mousePoint,%mouseClickCount)
{
echo("Working");
}

[Gytyyhgfffff]

Code: [Select]

function GuiMouseEventCtrl::onMouseLeave(%this,%modifier,%mousePoint,%mouseClickCount)
{
echo("Working");
}

don't forget to parent it, other mods probably will use it too

[Kyuande]

What's even more weird is that it works on GuiBitmapButtonCtrl too. Here's my released add-on that includes a support file I made. There's a chance it might work with almost any type of GuiControl.
<Nope>

[Shift Kitty]

Alright guys listen up, there are a lot of weird things you are going to encounter with guiMouseEventCtrl and I only discovered all of this by using them extensively for the last couple of years.

Bug 1: guiControl::setName() does not automatically associate a guiMouseEventCtrl with the various ::onMoulove() functions that you would expect to be called.  This means that if you create a guiMouseEventCtrl in the gui editor, and then name it "mymousecontrol" or whatever, it will not call mymousecontrol::onMoulove() for that mouse control.  You can fix this by doing a cut-paste of the mouse control in place.  That way it is created already with a name, and will work correctly.

Bug 2: guiMouseEventCtrl::onMouseMove() and the drag functions are only called on one axis at a time.  This means that if you move your mouse on a diagonal, you will get two calls for ::onMouseMove() in a row.  One of them will be for the change in x, one for the change in y.  This means that if you try to make a paint program or something, the user will see something that looks like steps when they try to draw a diagonal line.

There are also a lot of subtle ways the mouse controls handle entering and leaving that may or may not be considered bugs but are extremely complex.

Oh, I kind of forgot about the possibility of ::setname screwing things. That's nice to know.

[Nexus]

Hm, currently just doing 50ms schedules per loop and packaging GuiMouseEventCtrl::onWake so it replays the loop; the loop will end when the mouse control isn't awake. This only works for onMouseEnter and onMouseLeave.

Every single one of them is broken, not sure why.

Nevermind, got it working now. I tried this in general.

Code: [Select]

function GuiMouseEventCtrl::onMouseLeave(%this,%modifier,%mousePoint,%mouseClickCount)
{
echo("Working");
}

You should not use the general class GuiMouseEventCtrl, just create your mouse control with a name and use yourname::onMouseEtc().  Remember that creating a mouse control and then naming it after you have created it will not work due to a bug.

[Kyuande]

Okay, since the add-on was already made, I locked the topic; but, I still want to discuss here about it too.

I'll just put object names for mouse function types, since I'm doing pretty much the same thing in support code I made