search

dotnet / pinvoke

A library containing all P/Invoke code so you don't have to import it every time. Maintained and updated to support the latest Windows OS.
MIT License
2.12k stars 222 forks source link

Refactoring on WindowHook functions #270

Closed arlm closed 1 year ago

arlm commented 8 years ago

I would love to use PInvoke project on a managed library to do many kinds of WindowsHooks. Right now our implementation is bound to a very generic callback function. Windows Hooks come in many types and flavors and they specialize the types returned by LPARAM, WPARAM and have different meaning for the code param. It would be great to have all the callback specializations.

What I don't know if it is something we want on the project. This is the basic very low-level implementation and to have the specializations one could use the IntPtr overload to pass on their on specialized but still API compatible callback specializations. The other approach is that we could have a bunch of overloads, one for each specialized callback delegate.

What do you think about it guys? By the way, the second approach will break backward compatibility.

AArnott commented 8 years ago

I recall having a similar discussion before. What we came to is there are literally an unbounded number of specializations, many of them domain-specific. So that exceeds the scope of the project. So your first option, where someone else offers a bunch of 'overloads' that forward to the PInvoke method by casting the delegate to IntPtr seems to make the most sense.

arlm commented 8 years ago

OK. It makes sense and this is the main reason why I cam creating the WinApi project. Take a look on what I have done with the WM_GETTEXT message from one of my first PRs and that we have had this kind of discussion by that time. I understand the scope, but this issue we are discussing now was just to be sure on where and how I could make the changes to start using this API. It is somewhat blurry to me on when it is too much specialization and extrapolation of the original API and it does get out of scope, and when it does not.

I guess, for me, what makes it blurry are the extensions and helpers we already have. I remember, for example talking about macros like Make(W|L)Param and Get(Hi|Lo)Word and as far as I can remember (I can be wrong though) I understood it was out of scope, so I put my implementation of these on WinApi.Core@CoreExtensions.cs and some PInvoke.RECT to System.Drawing.Rectangle extensions on WinApi.Core@SystemDrawingExtensions.cs.

I think it makes sense for me to create a WinApi.WindowHooks package to implement the extensions, helpers and simplified/specialized overloads. I am using as practice to create packages for the base APIs by DLL when it is basic support and creating a per API-set package for related functions like WinApi.HighDpi, WinApi.DisplayApi, WinApi.Console, WinApi.WindowStationApi and those have PInvoke packages as dependencies.

I am open to suggestions and improvements and if you like this kind of splitting, feel free to refer the project for out-of-scope PRs that would make sense on a higher level API mapping, which is one of the first objectives of the project.

For the, the hard thing, is getting to understand the internals and ways of doing unsafe/pointer operations properly and also the memory management/resource lifecycle quirks and tricks. It seems that you and @vbfox are very used and knowledgeable on that are, it have been a great opportunity to learn form our PR discussions and code reviews (thank you, both, for that and the patience, by the way). So I may take a quick longer to get those things right on that project. For example, I have no idea on how to implement the WindowHook callback using IntPtr, so that I could point to a specialized callback delegate, but there lies a great opportunity to learn and research.