-
Notifications
You must be signed in to change notification settings - Fork 86
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
Reconsider taking SafeHandle-derived types as input parameters #125
Comments
|
Yes, the type-specificity is valuable, I agree. And we may bring it back, when we get the majority of the APIs "correct" and can circle back to bring back the niceties. We can leave this issue open to track considering bringing those back. |
I would also like overloads generated to generate overloads for |
@AraHaan: |
They are also used in the runtime itself (if I remember right they are used a lot in the winforms repository, maybe also the wpf repository in the dotnet org). Possibly used inside of This is where my code uses it: https://github.com/Elskom/Els_kom_new/search?q=HandleRef&type=code (it seems to not show every usage of it for some reason in my NativeMethods.cs file.) Got 616 results for it as well too https://github.com/search?q=org%3Adotnet+HandleRef&type=code, a lot of commits, and issues regarding it as well. |
HandleRef is useful for when you don't own the handle, but you do have a managed object (e.g. Form) that owns the handle, and you need to keep that object from being collected and freeing the handle concurrently during the native call. The alternative is to call Since HandleRef is a struct, it won't ever introduce an overload resolution ambiguity when passing the argument |
Alright. I guess it may be worth considering |
I think generating An idea for this to for example pretend that
However if they wanted to use both for example
That way we keep the cleanliness of not source generating to much code (only generate what is really used), as well as allow the user to opt in to only what they need based on their type of application or code. |
@AraHaan I tend to disagree since most APIs that produce handles expect the caller to close those handles, and .NET has a very strong precedent for using |
One issue with declaring input parameters with specific |
No semantically correct SafeHandle type is provided by CsWin32 when using GetCursorInfo with GetIconInfo and DrawIconEx, now that all handle parameters are
SafeHandle
:Prior to everything becoming abstract SafeHandle, the following code worked. It's not as ergonomic as passing
HCURSOR
, but it is nicer than the two new options:I'm also not a fan of throwing away the parameter type information in this way.
GetObject
has parameterSafeHandle h
now, for instance. A parameter like that doesn't instantly tell you what kinds of handle you can pass or how to obtain them.The text was updated successfully, but these errors were encountered: