Gammon Forum : MUSHclient : Bug reports : Hotspot mousedown callback not being executed

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Bug reports

Hotspot mousedown callback not being executed

Hotspot mousedown callback not being executed

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #15 on Tue 24 Nov 2009 04:53 AM (UTC)

Message

Quote:

I wasn't sure whether I could access error_code and the others without importing constants.lua first (which is really wrapped by XML). Now I see error_code is an entirely separate table, and it seems that I can access it, so thank you for letting me know!

It is loaded into the script space automagically.

Quote:

It's so much easier to just recreate and redraw ...

"For every problem there is a solution: neat, simple, wrong!"

The ability to recreate windows was really intended for the situation where you needed to load in a font first, and then calculate its size (eg. where its depth is 5 lines deep, depending on the font, and 80 characters wide, depending on the font), and then remake it the right size. Recreating the window between a mouse-down and mouse-up, or mouse-over, and end-mouse-over, was not really part of the design plan.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,257 posts)

Date

Reply #16 on Tue 24 Nov 2009 05:23 AM (UTC)

Message

Nick Gammon said:

"For every problem there is a solution: neat, simple, wrong!"

The ability to recreate windows was really intended for the situation where you needed to load in a font first, and then calculate its size (eg. where its depth is 5 lines deep, depending on the font, and 80 characters wide, depending on the font), and then remake it the right size. Recreating the window between a mouse-down and mouse-up, or mouse-over, and end-mouse-over, was not really part of the design plan.

Yep, Window.new() creates a dummy window specifically for the purposes you described. I think WillFa and I have worked most of the WindowCreate() issues out now. The only problem is that hotspot management has become more complex, but I'm sure it won't be too much of an issue.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Twisol USA (2,257 posts)

Date

Reply #17 on Tue 24 Nov 2009 05:36 AM (UTC)

Message

Nick, would it be possible to add functionality to change a hotspot's mouse handlers after it's been created? It's already there for the drag-related handlers, though I realize that's probably because they were added after the fact.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #18 on Tue 24 Nov 2009 07:10 PM (UTC)

Message

Just make a generic "stub" routine and then redirect the call into that to where you want. In other words, a handler could look up in your table to see which function (if any) to really call, when it is called.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,257 posts)

Date

Reply #19 on Tue 24 Nov 2009 07:22 PM (UTC)

Amended on Tue 24 Nov 2009 07:23 PM (UTC) by Twisol

Message

That could work, actually, thanks. I'm trying not to litter the user's script-space with anything more than the types he's directly require()ing, but I'll try this and see how it goes.

(Also, I'm trying to save MUSHclient from having to call each and every script callback when it doesn't have to. XD)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Twisol USA (2,257 posts)

Date

Reply #20 on Tue 24 Nov 2009 07:41 PM (UTC)

Amended on Tue 24 Nov 2009 07:47 PM (UTC) by Twisol

Message

Wait, how do I tell from a stub routine, theoretically used in every handler slot, what it's supposed to be handling? The only parameters are flags and id.

EDIT: Oh, a stub per handler slot. That seems like a lot of bloat, and a fair amount of litter in the script space. If Drag/Move/ReleaseHandler can be changed, why can't the others? It seems simple to do, from the cursory glance I gave to the implementations of CMUSHclientDoc::WindowDragHandler() and CMiniWindow::DragHandler().

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #21 on Tue 24 Nov 2009 08:24 PM (UTC)

Message

Why do you want to do this exactly? You already have cell.hotspot.mouseup etc. for every hotspot, right? All I am saying is, you create those functions on window creation, even if the function contents are replaced later on.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,257 posts)

Date

Reply #22 on Tue 24 Nov 2009 08:58 PM (UTC)

Message

Nick Gammon said:

Why do you want to do this exactly? You already have cell.hotspot.mouseup etc. for every hotspot, right? All I am saying is, you create those functions on window creation, even if the function contents are replaced later on.

Because the widget framework can't control what the user does with the hotspot callbacks. If cell.hotspot.mouseup is nil, there's no callback there to use. Creating the functions unconditionally on window creation, from the framework code, litters the user's script space, and restricts how it can be used. If the dummy-functions are placed in _G, each window would need hopefully-unique names for its handlers. If the dummy-functions are placed in the cell or the grid tables, then the cell/grid must be global to the script space. But if you can change the hotspot callbacks any time you want, you have more control over how and when they're called, even up to the point of swapping out different handlers depending on the current state of your plugin. All without specifically recreating the hotspots and potentially interrupting their own state.

Allowing the callbacks to be set after the fact also means that MUSHclient wouldn't have to bother with calling a dummy callback that's only there to fill space, if it's never going to be used in the specific application at hand. And again, it allows the widget framework to keep the script space clean, and also keep its design clean.

I don't think this is a feature that would only benefit the widget framework, either. I'm simply using hotspots enough to have noticed what appears to me to be a drawback.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

WillFa USA (525 posts)

Date

Reply #23 on Tue 24 Nov 2009 09:35 PM (UTC)

Message

Hotspots only work in plugins, which are fairly static once they're coded. Placing the burden on the plugin author not to screw up his own variable and function names doesn't seem like a stretch.

Posted by

Twisol USA (2,257 posts)

Date

Reply #24 on Tue 24 Nov 2009 09:46 PM (UTC)

Amended on Tue 24 Nov 2009 09:47 PM (UTC) by Twisol

Message

No, however if I have to give each handler a unique global name, then the plugin owner will have to set each global handler. Even if they'll all refer to the same function, you'd still have to set each generated name to point to it. And since you could have an arbitrary amount of windows/hotspots, that could be very... very annoying.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

WillFa USA (525 posts)

Date

Reply #25 on Tue 24 Nov 2009 09:58 PM (UTC)

Message

what's hard about?

cell.hotspot.mouseover or ""

If a plugin author doesn't want em, he don't get em. If he sets hotspot somewhere up the inheritance cascade, so be it, that works.
The only real limitation is that an author would need to set the 5 values in the hotspot table (or tables) before Draw is called and a hotspot is created, or Resize the window after declaring a new handler so all hotspots are nuked and recreated.

In 99% of cases, the implemented design is fine. In the 1% fringe case, it's simple enough to fix in the case of hotspots.

...
Plugin Callbacks in general though can be a pain in the butt. You can dynamically create a function for OnPluginWorldResized (for example) but if its not there when compiled, MC doesn't hook into it.

Posted by

Twisol USA (2,257 posts)

Date

Reply #26 on Tue 24 Nov 2009 10:30 PM (UTC)

Amended on Tue 24 Nov 2009 10:32 PM (UTC) by Twisol

Message

The problem with that particular approach is that it doesn't allow you to unhook functions or add new ones. The approach I assume Nick was speaking of, however, was creating a blank 'default' handler, which the user could override. I enumerated the drawbacks I could see in my previous couple posts.

I could solve this on the scripting side of things, but it would come with drawbacks no matter how you look at it. I am still wondering why we're so against allowing the handlers to be changed after the fact, when the drag-related handlers already support it, and it appears quite simple to do. It won't add any complexity that's not already there, and would simplify things as well.

EDIT:

WillFa said:

In 99% of cases, the implemented design is fine.

The design -is- fine. Hotspots work beatifully. I just want to be able to set certain aspects after they've already been created. That doesn't change the design, just how you utilize it.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by Nick Gammon Australia (22,982 posts) bio Forum Administrator

Date Reply #27 on Thu 26 Nov 2009 08:21 PM (UTC)

Message

My suggestion here is, since you are doing a framework anyway, to not store in your table that you already have, the *names* of the functions you want called (as they have to be in global namespace somewhere) but the functions themselves.

That was the approach I took in the movewindow.lua. When doing the AddHotspot, each action was given a callback in the unique table for that window (there has to be *one* thing in global space) eg.


mw_UNIQUE_NAME_movewindow_info.mousedown
mw_UNIQUE_NAME_movewindow_info.cancelmousedown
mw_UNIQUE_NAME_movewindow_info.mouseup
mw_UNIQUE_NAME_movewindow_info.mouseover
mw_UNIQUE_NAME_movewindow_info.cancelmouseover

This uses one thing in the global address space: mw_UNIQUE_NAME_movewindow_info.

Now in those table entries are not the names of what functions you want to call, they are the functions themselves. This means you don't have to invent lots of extra names for the functions.

Also, as in movewindow.lua the functions are created by a function-generating function which creates the functions with an upvalue, which is the table with all the other info in it, so the functions are self-contained.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Twisol USA (2,257 posts) bio

Date Reply #28 on Fri 27 Nov 2009 06:39 AM (UTC)

Message

Thanks! I've adapted that approach slightly, so the strings look like this instead:


MWidget.Window.hotspot_handlers.mouseover
MWidget.Window.hotspot_handlers.cancelmouseover
MWidget.Window.hotspot_handlers.mousedown
MWidget.Window.hotspot_handlers.cancelmousedown
MWidget.Window.hotspot_handlers.mouseup
MWidget.Window.hotspot_handlers.dragmove
MWidget.Window.hotspot_handlers.dragrelease

Each hotspot ID looks something like this (taking an example from a CharacterGrid hotspot):


w1_37859615f6c4f74b6872f8e6-h(1,1)

Everything before the -h is the hotspot's window's ID, so the constant handlers mentioned above can figure out which window table to use. It then goes into that table's list of hotspots, grabs the specific hotspot's details, and executes its callback (if it exists).

I think I'm content now *laughs*. It would be nice if I could change a hotspot's cursor after-the-fact, though, like the tooltip can be.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

56,059 views.

This is page 2, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )