You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the additions or enhancements you'd like
Since most functions are declared in static classes,
in order to expand the capabilities of Vanara, and greater compliance with the Net extensibility ideology,
there is a proposal to add "this" modifer before the first argument for most static functions turning them into extensions.
This can be done even with extern WinAPI functions.
I did this with a few of the functions and found that it breaks IntelliSense when trying to use the method as a non-extended method. Have you seen the same?
There are some problems with IntelliSense with inheritance and inplicit/explicit operators, for example if you make an Extension for HDC that has a direct conversion to IntPtr, then IntelliSense does not show the extended function in the list of IntPtr.
I’m ready to check if you indicate where you encountered errors!
Perhaps, as a starting point, we could try extend the functions for specialized Vanara-types like an HWND / HINSTANCE / SafeHandle, etc., without affecting the standard unmanaged int / string / bool and test the stability of the changes.
Describe the additions or enhancements you'd like
Since most functions are declared in static classes,
in order to expand the capabilities of Vanara, and greater compliance with the Net extensibility ideology,
there is a proposal to add "this" modifer before the first argument for most static functions turning them into extensions.
This can be done even with extern WinAPI functions.
Thus, these functions can be used in two ways:
I think this can be done for 85-90% of Vanara lib.
The text was updated successfully, but these errors were encountered: