winforms
winforms copied to clipboard
[Tracking] CsWin32 API Change/Add Requests
In the effort to start using CsWin32 (#7445), there may be APIs we'd like changed or added in cswin32 due to missing typedefs, conveniency, etc. This is a tracking issue to help keep a list of these adds/changes we would like.
CombineRgnmethod missingRegionTypereturn type (https://github.com/microsoft/win32metadata/issues/1024)RECT(https://github.com/microsoft/CsWin32/issues/626)- Implicit converter from
RECT->Rectangle WidthandHeightproperties forRECT- Convenient constructors e.g.
RECT(int left, int top, int right, int bottom)
- Implicit converter from
- SafeHandle usage prevents us from using convenience overloads (https://github.com/microsoft/CsWin32/issues/605)
- Null value has to be explicitly cast to HINSTANCE (https://github.com/microsoft/CsWin32/issues/639)
- Enum type for
GetROP2/SetROP2https://github.com/microsoft/win32metadata/issues/1045 - Enum type for
GetTextAlign/SetTextAlignhttps://github.com/microsoft/win32metadata/issues/1036 COLORREFreturn type forGetTextColor,GetBkColorhttps://github.com/microsoft/win32metadata/issues/1035SHACFenum missing https://github.com/microsoft/win32metadata/issues/1027- Enum for IME constants https://github.com/microsoft/win32metadata/issues/1028
- Mapping for
XFORM>Matrix3x2 - Enum type for
LOGFONTWmembers/LF_FACESIZEhttps://github.com/microsoft/win32metadata/issues/1060 - UXTheme APIs don't have an HTHEME struct https://github.com/microsoft/win32metadata/issues/1273
This would be helpful for SHAutoComplete method.
https://github.com/microsoft/win32metadata/issues/1027
This is blocking ImmGetConversionStatus:
https://github.com/microsoft/win32metadata/issues/1028
Just to explain what I have been doing. I have been using ILSpy to check the win32metadata for everything in each of the interop folders. I am doing this so win32metadata is ahead of the winforms team on any differences, making the conversion easier. I am working bottom to top.
I am creating the issues first and then I will submit PRs based on feedback in the issues. This way the team has known progress to reduce project risk.
Anyone else wanting to do this is welcome. You can find steps in https://github.com/microsoft/win32metadata/blob/main/CONTRIBUTING.md
Remaining Interop folders to check:
- Ole32
- Mso (Not in win32metadata)
- Mshtml (Not in win32metadata)
- ~Imm32~
- Hhctrl (.ocx, probably not apart of win32metadata?)
- ~Gdi32~
- ~Comdlg32~
- ComCtl32
- User32
What do we do with the following interop libraries?
- Mso (Not in win32metadata)
- Mshtml (Not in win32metadata)
- Hhctrl (.ocx, probably not apart of win32metadata?)
What do we do with the following interop libraries?
Looping in @JeremyKuhne for further thoughts on this when he's back. For now, we'll proceed with conversions for the other folders.
I know it sounds a bit silly, but I can't remember if I compared user32 to Win32Metadata. So I just have these to compare and raise issues:
- Ole32
- ComCtl32
- User32
I should be able to look into it later this week. After that, I will begin work on the PRs.
For the issues already raised in win32metadata some of them might not be valid. So if the team could verify them, that would be great. It will help reduce any wasted time on PRs that won't be merged.
For the issues already raised in win32metadata some of them might not be valid.
Could you clarify what you mean when you say that they might not be valid?
For the issues already raised in win32metadata some of them might not be valid.
Could you clarify what you mean when you say that they might not be valid?
I have done my best to find where the signatures of methods don't match. In some instances like NTSTATUS, an enum was turned down for static fields instead.
I expect the win32metadata team might turn down a few others.
Great job @elachlan! Thank you.
Adding win32metadata issues for User32 is "done". I may have missed a few, but we can pick them up when converting.
I am done! I have done my best to make sure I have covered everything, but I may have missed something.
We are going to have difficulties in ComCtl32 because lots of the enums defined in there are not defined in Win32Metadata and might not be added.
Ole32 has a lot of interface updates. But the conversion doesn't seem as bad.
The metadata team and winforms team will need to review and discuss the issues I have linked here.
CC: @sotteson1 and @mikebattista sorry for the issue spam.
Fortunately most of your issues are just with friendly enums which are easy to add.
The biggest problem winforms will face is the messaging constants. Metadata doesn't group them into enums. Which makes it harder for winforms to consume them. There is a lot to be said for constants though. Since if you only use two of them, then you just import two of them via CsWin32. So the amount of generated code is less.
@JeremyKuhne is there anything pending from windows on this?
There are still a few open issues, and we are probably missing a couple. We'll do another run through to ensure we have all of the open ones tracked.