Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement WM_ContextMenu #53

Merged
merged 6 commits into from
Apr 22, 2021
Merged

Conversation

AliveDevil
Copy link
Contributor

Needed this functionality as a user requested it once. Would appreciate that this is taken upstream, instead of relying on our private fork, from 2016.

@AliveDevil AliveDevil changed the title Wm contextmenu Implement WM_ContextMenu Apr 20, 2021
@Lakritzator
Copy link
Collaborator

Definitively a useful addition, I planed this initially (this is why there was a placeholder) but somehow it never got in.

I will make a small code review, because there is something I don't see as very useful.

@@ -87,5 +87,15 @@ internal static class WinApi

[DllImport(User32, SetLastError = true)]
public static extern bool GetCursorPos(ref Point lpPoint);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm all for clean code and reuse, but somethings we should not over engineer code.

I actually don't see any re-use for this, unless there is no need for this elsewhere I would suggest to just have this inside the switch statement with the WindowsMessages.WM_CONTEXTMENU

@@ -132,6 +132,7 @@ public TaskbarIcon()

// register event listeners
messageSink.MouseEventReceived += OnMouseEvent;
messageSink.ContextMenuReceived += OnContextMenuEvent;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if the added redirect via the OnContextMenuEvent adds anything to clear up the code, maybe we just do the following?
messageSink.ContextMenuReceived += ShowContextMenu;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know whether DPI has any effect on the wParam-Position, so I just added another method here.

@@ -242,8 +248,11 @@ private void ProcessWindowMessage(uint msg, IntPtr wParam, IntPtr lParam)
switch (message)
{
case WindowsMessages.WM_CONTEXTMENU:
// TODO: Handle WM_CONTEXTMENU, see https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw
Debug.WriteLine("Unhandled WM_CONTEXTMENU");
ContextMenuReceived?.Invoke(new Point()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the other comment, why not place the code to do the low / high bit logic directly here, as it's probably not used elsewhere.

@Lakritzator
Copy link
Collaborator

Is there any chance you can also check the other TODOs in the WindowMessageSink?
They are NIN_SELECT & NIN_KEYSELECT as described here: https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyiconw

@AliveDevil
Copy link
Contributor Author

I think it would be beneficial to add those aswell.
Already found that Space and Enter don‘t activate the context menu. Eventually I can drop that casting and shifting around by adapting GET_X_LPARAM and GET_Y_LPARAM. According to documentation those macros should enable multi monitor scenarios. I‘ll convert the PR to a draft until I‘m finished and verified correct function.

@AliveDevil AliveDevil marked this pull request as draft April 20, 2021 16:25
@AliveDevil AliveDevil marked this pull request as ready for review April 21, 2021 08:35
@AliveDevil
Copy link
Contributor Author

Checked and implemented NIN_SELECT and NIN_KEYSELECT - implementation is equal to WM_CONTEXTMENU.
Removed the event handler for contextmenu, and used the ShowContextMenu-implementation.

@Lakritzator
Copy link
Collaborator

Looks great from a code perspective, I will have a quick try later.

@Lakritzator
Copy link
Collaborator

@punker76 @hardcodet this PR solves some of the small TODOs that were still open for keyboard usage.
I've approved the changes, I also had a quick test, looks good.
But as we forgot to discuss how we move forward with the branches, I don't like to merge this right away.
Also we might need to talk about how to move forward with next versions.

@punker76
Copy link
Collaborator

@Lakritzator IMO we should work on the develop branch until we want to release a new version which will be merged to the master and a new branch like release/x.x.x.

@Lakritzator
Copy link
Collaborator

@punker76 I should have added my suggestion... yes, work in develop, and branch out. The 1.1 hasn't been branched out, I will do so, so I can merge this.

@punker76
Copy link
Collaborator

@Lakritzator The missing branch was a mistake by me

@Lakritzator
Copy link
Collaborator

@Lakritzator The missing branch was a mistake by me

Okay, push it

@punker76
Copy link
Collaborator

@Lakritzator done

@Lakritzator Lakritzator merged commit ec2e870 into hardcodet:develop Apr 22, 2021
@Lakritzator
Copy link
Collaborator

@AliveDevil thank you for your work.

I currently can't tell when this is released, keep an eye out on the project.

@AliveDevil AliveDevil deleted the wm-contextmenu branch January 11, 2023 11:09
@punker76 punker76 added the Enhancement New feature or request label Jun 11, 2024
@punker76 punker76 added this to the 2.0.0 milestone Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants