Migrate Legacy WinForms Changes onto master (based on v8.0.3) via Cherry-Pick#4
Open
alamin0313 wants to merge 73 commits intomasterfrom
Open
Migrate Legacy WinForms Changes onto master (based on v8.0.3) via Cherry-Pick#4alamin0313 wants to merge 73 commits intomasterfrom
alamin0313 wants to merge 73 commits intomasterfrom
Conversation
… not found. This could be the case when a node is being added or deleted from the Nodes collection Fixes dotnet#10876
…eLabelEditEventArgs.Node with a null-check because these arguments could be created during node insertion according to this comment on NodeFromHandle
Bump Nugetpackaging version
…lishing.props (dotnet#10953) add ProducesDotNetReleaseShippingAssets property Co-authored-by: MilenaHristova <mhristova@microsoft.com>
…nabled=false` and `Multiselect = true` (dotnet#10867) cherry pick 91f648b
Duplicate azure-pipelines.yml Co-authored-by: Loni Tra <lonitra@microsoft.com>
duplicate build yml
[release/8.0] Update dependencies from dotnet/arcade
… added demo project and supressed some analyzer warnings/errors and bug fixes around DataGrid
…l after modifying the old creation method to basically skip a check for whether a handle has been created or not
…trols in the Demo form
… to not have the ilproj file as part of the solution
WI00745513 - Port remaining Menu tests to .net 8 (PR 8) add 3 menu related winform tests to project. <img width="330" alt="image" src="https://github.com/WiseTechGlobal/CargoWise.Controls.WinForms.Legacy/assets/166356437/408de456-d34a-4f80-b43d-1b6e7001fabc">
WI00745297 - Port_WinForms_ToolBar_tests to .net8 (PR 10) Added ToolBar tests
WI00745589 - Resolve UI scaling issues (PR 12) Change DPI mode, add comments
…clude the project references in the package, rather than the default of having them as further package references. (dotnet#11) WI00745744 - Manually publish CargoWise.Controls.WinForms.Legacy as a package in Proget (PR 11) See WI00745744 Goal of this PR is to enable package generation for WTG.System.Windows.Forms. The package is currently being manually pushed to the internal Proget server.
…em.Windows.Forms.dll (dotnet#13) WI00756869 - Change CargoWise.Controls.WinForms.Legacy to output System.Windows.Forms.dll (PR 13) WI00756869 - Change CargoWise.Controls.WinForms.Legacy to output System.Windows.Forms.dll
…-> 8.0.0.0) (dotnet#14) WI00768976 - 0.0.8-dev.final: change version of System.Drawing.Common.dll (4.0.0.0… (PR 14)
WI00775636 - Set version to 8 for all libraries. (PR 15)
WI00798235: remove obsoletion warning message (PR 16) remove this warning message: WFDEV001: Casting to/from IntPtr is unsafe, use WParamInternal
…otnet#18) <!-- Please read CONTRIBUTING.md before submitting a pull request --> Fixes # ## Proposed changes - Resolve an issue when trying to instantiate a ZBindingContext. - TextRenderer flag issue (Need help with that one see comment) <!-- We are in TELL-MODE the following section must be completed --> ## Customer Impact - None ## Regression? - Yes (following migration to NET8) ## Risk - None <!-- end TELL-MODE --> ## Test methodology <!-- How did you ensure quality? --> - Created a project with a ZForm and a ZGrid. Before change: cast issue. After change, Form is displayed. ## Test environment(s) <!-- Remove any that don't apply --> - Used WiseTechGlobal/ModernPlatform.Tools#129 <!-- Mention language, UI scaling, or anything else that might be relevant -->
<!-- Please read CONTRIBUTING.md before submitting a pull request --> Fixes # - ContextMenu for TreeView and TreeNode ## Proposed changes - Add back ContextMenu for TreeView and TreeNode, along with other required ContextMenu functionality copied back from WinForms prior to Core 3.1 release. <!-- We are in TELL-MODE the following section must be completed --> ## Customer Impact - - ## Regression? - No ## Risk - <!-- end TELL-MODE --> ## Test methodology <!-- How did you ensure quality? --> - I added unit tests to cover some of the basics, but also one that simulates right clicking a tree node to open the context menu. - Additionally, I updated the demo app to have a treeview with nodes and context menus. ## Test environment(s) <!-- Remove any that don't apply --> - <!-- use `dotnet --info` -->
…Forms (dotnet#22) Addresses #WI00756959. Nuget package does not include all required WTG ported assemblies for WTG.System.Windows.Forms. ## Proposed changes - As an intermediate measure use a stand alone .nuspec to create the Nuget package. As it stands a stand alone specification is not any less elegant than manual entries in the .csproj that require complex logic. This could be readdressed in future, but given the highly specific nature of the ported assemblies this may also be the most transparent approach. - Added an automated script at the project root to create the Nuget package using the stand alone .nuspec. ## Customer Impact - Correct Nuget package assembly composition. ## Regression? - No ## Risk - Potentially incorrect versions due to the version number being supplied manually by the .nuspec. ## Test methodology - Inspected Nuget package internals. - Applied Nuget assemblies to WTG.System.Windows.Forms POC.
…rms (dotnet#24) [WI00857973 - Comment out Debug.Fail in PaintEventArgs in forked WinForms](https://svc-ediprod.wtg.zone/Services/link/ShowEditForm/WorkItem/fecad7df-5c60-4a4b-8df5-c61838c7d30a?lang=en-gb)
…rms using release conf (dotnet#25) [WI00876922 - Create nuget package release of forked System.Windows.Forms using release conf](https://svc-ediprod.wtg.zone/Services/link/ShowEditForm/WorkItem/b9131798-0c48-4fb6-bf67-ac25a8b0cffc?lang=en-gb) Creates v0.0.14-dev.final, which uses assemblies built in Release mode. This will avoid tripping on Microsoft's internal debug assertions
[WI00892988 - Remove need for forked System.Drawing.Common](https://svc-ediprod.wtg.zone/Services/link/ShowEditForm/WorkItem/1136cd26-7ad6-4bc5-9e78-39fc7b3efcbf?lang=en-gb), workflow "1. Update forked WinForms" Remove need to distribute a forked System.Drawing.Common. I found a substitute for the only line in `MenuItem` that relied on it, allowing us to use the public package listed on nuget instead.
<!-- Please read CONTRIBUTING.md before submitting a pull request --> Fixes # - primarily to fix shortcut key for Save (Ctrl+S), however as suspected all menu shortcut keys are failing <!-- We are in TELL-MODE the following section must be completed --> - provide the intuitive capabilities which menu shortcut keys provide. - reduce the need for clicking the relevant menus to access the functionality of the menu - No - Any unexpected behaviour triggered by the functionality. I believe the fix is very concise and should not have any side effects <!-- end TELL-MODE --> - Ideally I would have added Unit tests, however at this juncture, unit tests are not available for this project
Change WebBrowser references in WebBrowserSiteBase and WebBrowserEvent to a WeakReference. Temporary fix while waiting for dotnet#13769
…745744 (dotnet#31) In future this could be improved, but for now this is better than manually running packaging steps on developer PC. Diff vs. the manually published package: <img width="1901" height="1072" alt="image" src="https://github.com/user-attachments/assets/8d76bf3f-e63e-4e67-84df-3c38caf9fdfc" /> <img width="1882" height="342" alt="image" src="https://github.com/user-attachments/assets/6da8b7bf-334a-4536-902a-307a3738c160" />
Form and MainMenu are tightly coupled in Winforms for .NET 4.8. When we ported MainMenu to .NET 8 we missed some places in Form that also needed to be ported. Form is responsible for keeping track of the menus on the form and passing on the relevant windows messages to the menu. Without this, popup events on the menu weren't firing. This PR copies in the relevant code from the older version of Winforms before MainMenu was removed.
* Reinstate HasMenu on Form * Reinstate HasMenu on Control * Review everywhere that calls AdjustWindowRectEx* and compare with the 3.0 equivalent. If the 3.0 equivalent passed in HasMenu for the bMenu parameter, then pass it in here. If the 3.0 equivalent passed in a constant false, then continue to pass false. Fixes forms being too small by the height of the menu bar. AI generated tests.
…et#36) When Menu property changes before handle creation, form size doesn't update immediately. We had a variable name inconsistency: - In `SetClientSizeCore`: we set `_formState[FormStateSetClientSize] = 1;` - In `Menu` setter: we were checking `formState[FormStateSetClientSize] == 1` (wrong variable) Fixed the variable name to use `_formState[FormStateSetClientSize] == 1` consistently. - **Official .NET WinForms:** - [Form.SetClientSizeCore](https://github.com/dotnet/winforms/blob/6c74471e6d174da251e7c170647b0b0b35149b8e/src/System.Windows.Forms/src/System/Windows/Forms/Form.cs#L5574) - [Form.Menu setter](https://github.com/dotnet/winforms/blob/6c74471e6d174da251e7c170647b0b0b35149b8e/src/System.Windows.Forms/src/System/Windows/Forms/Form.cs#L1564) - **Our Implementation:** - [Form.SetClientSizeCore](https://github.com/WiseTechGlobal/CargoWise.Controls.WinForms.Legacy/blob/0940df29d664bd43d52738fa2e45a176517b9c65/src/System.Windows.Forms/src/System/Windows/Forms/Form.cs#L5501) - [Form.Menu setter (fixed)](https://github.com/WiseTechGlobal/CargoWise.Controls.WinForms.Legacy/blob/0940df29d664bd43d52738fa2e45a176517b9c65/src/System.Windows.Forms/src/System/Windows/Forms/Form.cs#L760)
…d of DAT dependency (dotnet#39) This PR replaces the DAT dependency mechanism with a direct NuGet package reference for CargoWiseCloudDeployment, configured as a build-time dependency. ## Changes Made - **Removed DAT dependency from Build.xml** - Eliminated the `<Dependencies>` section that referenced `CargoWiseCloud.Shared/Deployment` repository - **Added CargoWiseCloudDeployment as build-time dependency** - Added `CargoWiseCloudDeployment` version 1.0.0.4 as a package reference in `Directory.Build.targets` with `PrivateAssets="all"`
…ps appear/Fix porting bug in CargoWise.Controls.WinForms.Legacy (dotnet#41) [WI00951596 - NET8 - ZRichTextBoxToolBar disappears when button tooltips appear](https://ediprod.cw.wisetechglobal.com/link/ShowEditForm/WorkItem/3a97f399-ad3f-476e-be56-0613dc9b4d2d?lang=en-gb), workflow "Fix porting bug in CargoWise.Controls.WinForms.Legacy" Fix bug introduced during porting of the ToolBar control in #3 ([WI00743644 - WinForms ToolBar control in Net8](https://ediprod.cw.wisetechglobal.com/link/ShowEditForm/WorkItem/4e0c475b-c2ba-46dd-889a-a2d1c35da1ec?lang=en-gb)) New tests before fix: <img width="1994" height="466" alt="Screenshot 2025-09-04 140607" src="https://github.com/user-attachments/assets/bd943304-65a9-4b25-b55d-90fc7ebd1d77" /> New tests after fix: <img width="428" height="210" alt="image" src="https://github.com/user-attachments/assets/c7f3d496-ba4d-430c-b197-657e839c31b1" />
…trols.WinForms.Legacy (dotnet#44) [WI00960762 - Update CargoWiseCloudDeployment package in CargoWise.Controls.WinForms.Legacy](https://ediprod.cw.wisetechglobal.com/link/ShowEditForm/WorkItem/05457ed6-e55a-449b-a34a-53da24161495?lang=en-gb) Update the `CargoWiseCloudDeployment` package to use the latest version, to fix deployment issue. See [Teams](https://teams.microsoft.com/l/message/19:5389c798f144428e9b9b1df20661e308@thread.tacv2/1757045159168?tenantId=8b493985-e1b4-4b95-ade6-98acafdbdb01&groupId=75b1866b-4460-4231-9c98-fd2580072cb4&parentMessageId=1757045159168&teamName=CW%20Modernization&channelName=CW%20.Net8%20Squad&createdTime=1757045159168) for background.
The related discussion thread is [here](https://teams.microsoft.com/l/message/19:5389c798f144428e9b9b1df20661e308@thread.tacv2/1756976234417?tenantId=8b493985-e1b4-4b95-ade6-98acafdbdb01&groupId=75b1866b-4460-4231-9c98-fd2580072cb4&parentMessageId=1756431640602&teamName=CW%20Modernization&channelName=CW%20.Net8%20Squad&createdTime=1756976234417). Upon further investigation, the root cause of the issue mentioned on WI is related to the different DPI handling between .NET 8 and .NET Framework. `EnableAnchorLayoutHighDpiImprovements` is an opt-in flag in .NET Framework that attempts to support high DPI (as we know that the .NET Framework version of WinForms doesn't work well with high DPI). We don't enable this flag in CW, so it is always false. In .NET 8, `EnableAnchorLayoutHighDpiImprovements` no longer exists. (I guess Microsoft has invested effort in improving the DPI handling in WinForms for .NET Core.) Instead, we now have the `IsScalingRequirementMet` property that determines whether we can use the same logic as in .NET Framework. For .NET 8, a hacky approach is to simply remove these two lines to achieve the same behavior as .NET Framework (avoiding the `if` clause). [https://github.com/dotnet/winforms/blob/aed0d424317a77521626fb0a9dcfae50bbfb8c67/src/System.Windows…](https://github.com/dotnet/winforms/blob/aed0d424317a77521626fb0a9dcfae50bbfb8c67/src/System.Windows.Forms/src/System/Windows/Forms/Layout/DefaultLayout.cs#L793) [https://github.com/dotnet/winforms/blob/aed0d424317a77521626fb0a9dcfae50bbfb8c67/src/System.Windows…](https://github.com/dotnet/winforms/blob/aed0d424317a77521626fb0a9dcfae50bbfb8c67/src/System.Windows.Forms/src/System/Windows/Forms/Layout/DefaultLayout.cs#L821)
Call stack: <img width="1235" height="357" alt="image" src="https://github.com/user-attachments/assets/0fad3548-822d-4917-871e-75ee82954f7e" /> After this change and replacing System.Windows.Forms.dll in `CargoWise/bin/net8.0`, I've test and could see Universal Copy menu item in net8 version.
…ion MISC Tab (dotnet#47) This fix was incorporated in WinForms .NET8 in this [PR](https://github.com/dotnet/winforms/pull/12683/files) Corresponding GitHub [issue](dotnet#12661)
### [WI01012522 - Upgrade Deployment Projects To Net Core](https://ediprod.cw.wisetechglobal.com/link/ShowEditForm/WorkItem/68ab5a57-7722-4e51-97dd-b8ccc03de75f?lang=en-gb) ---- ### Description Update DeploymentSetup.ps1 for net core deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Migrate Legacy WinForms Changes onto master (based on v8.0.3) via Cherry-Pick
Summary
This PR migrates all WiseTech legacy changes from
CargoWise.Controls.WinForms.Legacyonto themasterbranch of the WinForms fork.The
masterbranch was reset to upstream tagv8.0.3, and all WiseTech-specific commits were cherry-picked on top to preserve commit history and ensure a clean fork alignment.What Was Done
1. Reset Base to Upstream
WiseTechGlobal/winformsrepositorymasterfrom upstream tag:This ensures the fork is aligned cleanly with upstream before applying any WiseTech changes.
2. Added Legacy Repository as Remote
This allowed access to all legacy commits.
3. Identified WiseTech-Specific Commits
Where:
bd280bb= upstreamv8.0.3tag commitlegacy/master= latest legacy branchThis filtered:
4. Created Migration Branch
Branch created from clean
master(v8.0.3 base).5. Cherry-Picked Legacy Commits
All non-merge WiseTech commits were cherry-picked in order:
This:
Result
masternow represents:v8.0.3