Specify direction of popup for WindowMenu()

Posted by Worstje on Tue 24 Jan 2017 05:10 PM — 16 posts, 69,682 views.

Worstje Netherlands Tue 24 Jan 2017 05:10 PM #0

I am currently dusting off some old scripts (the MU*-ing bug never leaves a person) and came across a slight annoyance that I am pretty sure is rather simple to amend / implement on your end.

For this particular script, it is really annoying that the popup menu pops downwards. From my experiences with the Windows API, I know there are TPM_*ALIGN flags that control the behaviour of the TrackPopupMenu() api call with regards to the specified X and Y coordinate. (For whatever wacky reason, it even supports centering in both horizontal and vertical directions.. o.O)

I'd dig through the source code and offer a patch, but I suspect that I'll get lost in the rabbit hole for the Lua/misc scripting trying to add said parameter, only to end up implementing it in a way you'd rather see done different. :-)

See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms648002(v=vs.85).aspx

P.S.: A belated best wishes for this year!

Worstje Netherlands Tue 31 Jan 2017 07:56 PM #1

Since I notice Nick has responded to quite a few topics but this one seemed to have escaped his attention...

Bump.

Nick Gammon Australia Forum Administrator Tue 31 Jan 2017 10:22 PM #2

I saw it, but adding another argument to WindowMenu looked hard. I'll see if I can do it another way.

Nick Gammon Australia Forum Administrator Tue 31 Jan 2017 10:33 PM #3

What do you want to have happen anyway? Pop upwards? Pop to the left? Pop in the middle?

Worstje Netherlands Tue 31 Jan 2017 11:35 PM #4

Ah, apologies for my impatience in that case. :-)

In this particular instance, I am not sure if I prefer popping up to the left or right is preferable. I do know I need it to pop upwards because the information to put the options into context for the user appear in the miniwindow that the popup likes to cover up. Whilst testing, I've found myself dismissing the popup, read the information, and bringing it back up only to find the most suitable option I have available.

Given my _current_ usecase, I think the top-right direction is what I'll go with. But I can't say for sure whether another direction isn't useful. I have a limited skinning feature for this particular plugin which allows the look and positioning to be changed, which would probably also affect how you'd want the popup to behave. Then again, that's hardly relevant for me ATM.

What's the problem with implementing the sort of flags parameter like you've done for other functions in the past? Defaulting to nil and such? Is it the WSH part of the implementation?

Nick Gammon Australia Forum Administrator Wed 01 Feb 2017 03:07 AM #5

I've added the code to do that in as language-neutral way as I could.

The documentation has been updated here:

http://www.gammon.com.au/scripts/doc.php?function=WindowMenu

The relevant changes are:

Quote:

If the first character of the entire Items string is the "~" character, then the menu alignment is specified by the next two characters. The "~xx" characters are then removed and the rest of the string treated in the usual way (so you could then start a submenu, for example).

The two characters following the "~" are the horizontal and vertical alignments, as follows:

Horizontal: L, C or R (left, centre, right)
Vertical: T, C or B (top, centre, bottom)

Default is top left (so the menu aligns to the specified point and appears on the right and underneath). That is, top left is where the menu starts. The letters are not case-sensitive. Anything other than those letters will be ignored.

For example:


Items = "~RB Take | Drop" -- align cursor on right and bottom of point.

If you want to use both "!" and "~" then use "!" first as that is checked for and then removed from the string. Then it checks for "~" next. After that the normal menu processing takes place.

If you want to test it you can grab the latest executable as automatically built with Fiendish's system, here:

http://www.gammon.com.au/forum/?id=13903

Worstje Netherlands Wed 01 Feb 2017 05:00 AM #6

I haven't gotten around to downloading and testing (I will at some point tonight), but I do have a suggestion for improving the documentation.

The directions (Left, Right, Top, Bottom) apply not in the direction the menu expands from the cursor, but apply to the relative position the given coordinates (usually the mouse cursor!) are on the popup menu when it pops up.

Thus, TL (Top Left) means the mouse cursor will be at the Top Left corner of the menu... which means it expands downwards and to the right. Similarly, BR (Bottom Right) means the cursor will be in the bottom right of the menu, meaning the menu itself expands towards the top left!

You do say this in far less words when you read carefully and know what to look for, but since I assume most people are not familiar with the way Windows implements menus, they might well interpret it differently in a to them far more sensible manner.

Think along the lines of someone going "How do I make it pop up to the top right? Oh. '~RT'. There we go!"

Nick Gammon Australia Forum Administrator Wed 01 Feb 2017 05:04 AM #7

Yes, I know it's confusing. My mind boggled a few times when I wrote the help. However that's how Microsoft documents it. When they say "top left" they mean the menu drops down to the bottom and on the right of the cursor.

I think the number of people that use this feature will be so small that they will soon get the hang of it by trial and error.

Worstje Netherlands Wed 01 Feb 2017 06:27 AM #8

Yeah, fair enough. I tend to be a stickler for little UI usability things though, so when I ran into it I just had to bug you with it. :-)

Anyway. I tested out the functionality. Long story short: the new directional functionality works. It took me a while to properly test it, because pre-releases didn't exist back when I wrote this plugin, but it has a bunch of now-fixed version checks that make it so it ought to still run with minimal inconveniences back on v4.38. xD

Thank you Nick. :-)

Oh, and since I might as well throw in my new-and-improved version checking:

-- Get the most recent MUSHclient version in numeric form.
--   "4.11" -> 411
--   "5.05-pre" -> 505
function GetVersionAsInteger(version_string)
  -- A fancier version of:    tonumber(GetInfo(72))*100
  -- because that one does not handle '-pre' at the end.
  -- Also avoid potential decimal separator differences
  -- while we're rewriting this stuff anyway.

  version_string = version_string or GetInfo(72)
  local major, minor = version_string:match("^(%d+)\.(%d%d)")

  -- Failure?
  if (major == nil) then
    return nil   -- Failure.
  end

  -- Calculate.
  return (tonumber(major)*100 + tonumber(minor, 10))
end

... which is used like ...

-- If v5.05 or higher, specify direction of popup.
if (GetVersionAsInteger() >= 505) then
  menu_items = "~LB" .. menu_items
end

Worstje Netherlands Wed 01 Feb 2017 08:11 AM #9

I just bugged my games admins because of a bug with the 5.05 prerelease I downloaded. Stupid me, should have tested MUSHclient before bugging them.

Not sure what exactly changed (5.04 works just fine, 5.05 became unusable). At first I blamed the game, then the script I was testing for somehow triggering some other bug (even though it doesn't have any triggers; only aliases), then my own colouring triggers.. even with all that stuff gone, it still happened. Reverting to 5.04 is the only thing that made the program usable once more.

Symptom:

Text stops coming in. Some stuff does show.

Details I have noticed:

1) Initially logging in works fine.
2) I don't seem to get any incoming packets after I send a command.
3) For some weird reason, some other stuff did come in. (A watch command did give me output. Someone telling me something did work. But me telling them something never comes in.)
4) A Debug Packets execution only showed my sent commands, as well as a 2 byte incoming packet FF F1 (IAC NOP).

Ruled out:

1) My only plugin was removed.
2) My triggers were disabled. (Only had coloring ones anyway).
3) Rebooted client once, too.

So I have no clue what caused it. Since the WindowMenu change doesn't affect output whatsoever, the only other change would be the one Fiendish suggested involving style runs at the end of a line [commit ab71be2]. Could this somehow triggers an edge condition somewhere that has been missed thus far? I can't imagine how, but I'm not sure what it could be instead.

Fiendish USA Global Moderator Wed 01 Feb 2017 11:59 AM #10

Since you're using the -pre build, there are also some additional compiler optimizations added. That shouldn't do anything (why would MUSHclient rely on extremely high precision FP math, for instance?) but that's another thing changed. I definitely need the end of line style runs though, so please don't revert that! ^_^

If you quit and restart mushclient does the problem happen every time or just sometimes? Are you using autologin?

Worstje Netherlands Wed 01 Feb 2017 12:19 PM #11

PM me your e-mail and I'll toss you the packet debug I did whilst trying to figure out who was to blame. There's honestly not much to see; I do see what I assume are two 1-byte MXP-purpose packets but it's hard to judge.

I do use autologin.

I closed and re-opened the world once (I assumed something got stuck from my triggerless plugin and tried to reset as much as possible just in case), and later on also tried restarting it once or twice (Making sure all plugins were gone, triggers disabled, etc) before finally reverting versions, yet it always happened.

Edit: E-mail has been sent.

Nick Gammon Australia Forum Administrator Wed 01 Feb 2017 09:02 PM #12

Either:

The pre-release build is different in some way (it is done with a more modern version of the compiler); or
One of the recent changes has introduced a bug

I'll recompile using my own compiler shortly and upload that for you to test. That way we can rule in or out one of those cases.

BTW I haven't got your email. Put "Worstje" somewhere in the subject line to help me find it, if it ended up in the spam folder.

Nick Gammon Australia Forum Administrator Wed 01 Feb 2017 10:00 PM #13

Try this:

http://gammon.com.au/files/mushclient/MUSHclient_5.05-pre.zip

Nick Gammon Australia Forum Administrator Wed 01 Feb 2017 10:47 PM #14

Bug re data not arriving now discussed here:

http://www.gammon.com.au/forum/?id=13917

Fiendish USA Global Moderator Wed 01 Feb 2017 11:22 PM #15

Nick Gammon said:

BTW I haven't got your email. Put "Worstje" somewhere in the subject line to help me find it, if it ended up in the spam folder.

I just forwarded it to you.