-
Notifications
You must be signed in to change notification settings - Fork 961
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
Remove deprecated controls #2091
Comments
Fixes dotnet#2091 - Remove the following API because they have been obsolete since .NET 2.0: * `Menu` * `MainMenu` * `ContextMenu` * `MenuItem` * `IMenuEditorService` * `ToolBar` * `ToolBarAppearance` * `ToolBarButton` * `ToolBarButtonClickEventArgs` * `ToolBarButtonClickEventHandler` * `ToolBarButtonStyle` * `ToolBarTextAlign` * `DataGrid` * `DataGridAddNewRow` * `DataGridBoolColumn` * `DataGridCaption` * `DataGridCell` * `DataGridColumnCollection` * `DataGridColumnStyle` * `DataGridDefaultColumnWidthTypeConverter` * `DataGridLineStyle` * `DataGridParentRows` * `DataGridParentRowsLabel` * `DataGridRelationshipRow` * `DataGridRow` * `DataGridState` * `DataGridTableCollection` * `DataGridTableStyle` * `DataGridTextBox` * `DataGridTextBoxColumn` * `DataGridToolTip` * `GridTablesFactory` * `IDataGridEditingService` - Remove the following members in `AxHost` type: * `ContextMenu ContextMenu { get; set; }` * `event EventHandler ContextMenuChanged` - Remove the following members in `Control` type: * `ContextMenu ContextMenu { get; set; }` * `event EventHandler ContextMenuChanged` * `void OnContextMenuChanged(EventArgs e)` - Remove the following members in `Form` type: * `MainMenu Menu { get; set; }` * `MainMenu MergedMenu { get; }` * `void Control.OnContextMenuChanged(EventArgs e)` - Remove the following members in `NotifyIcon` type: * `ContextMenu ContextMenu { get; set; }` - Remove the following members in `PrintPreviewDialog` type: * `MainMenu Menu { get; set; }` * `ContextMenu ContextMenu { get; set; }` * `event EventHandler ContextMenuChanged` - Remove the following members in `ToolStripDropDown` type: * `ContextMenu ContextMenu { get; set; }` * `event EventHandler ContextMenuChanged` - Remove the following members in `TreeNode` type: * `ContextMenu ContextMenu { get; set; }` - Remove the following members in `UpDownBase` type: * `ContextMenu ContextMenu { get; set; }`
Are we knowingly breaking source compatibility with .NET? |
Yes. These controls technically have been deprecated since .NET 2.0 (circa 2005) and have been removed from the VS Designer Toolbox. |
Have the controls intended to replace these ever reached the look & feel of native Windows controls? I specifically use |
You're welcome to raise a new issue about making controls look Windows native. An associated PR will also be appreciated. |
@chylex I'm interested to know what the differences are in the newer OSes that make the -Strip controls look completely out of place? What OS are your apps targeting? There may be some improvement possibilities there. File and issue with screen grabs and I'm happy to have the team take a look. |
Alright, is there no way .NET Core can be backwards compatible? While testing this, I installed 3.1.0 by accident, which crashed because of the missing controls, which I suppose is expected, but then it wouldn't even let me install 3.0.0 without uninstalling 3.1.0 first. If I have to tell people they must uninstall 3.1.0 and install 3.0.0 to use my app, and then reinstall 3.1.0 again if they want to use other new apps, I might as well revert back to .NET Framework for stability. |
Filed #2476 @merriemcgaw, thanks for looking into it. |
It is possible to create self-contained apps, so your users will be able to run your apps without needing to install anything other than your app. You can find more info: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#compiledeploy |
@merriemcgaw The old Fundamentally, it’s not because that Having to use In your post, you asked how the WinForms team can make |
This breaks the Telerik UI for WinForms library, which is still using Edit: Telerik confirmed that their 2020 library release will be 3.1 compatible and use Although .NET Core 3.0 is (accidentally!) compatible, it is not an LTS release and will be out of support in the next 3 months. This would also be a concern for a self-contained deployment. |
I'm not sure what "technically deprecated" means, but the documentation for .NET Framework 4.8's ContextMenu clearly states: Although ContextMenuStrip replaces and adds functionality to the ContextMenu control of previous versions, ContextMenu is retained for both backward compatibility and future use if you choose. MainMenu, DataGrid, and the others all say the same thing, and have since .NET 2.0. I'm personally upset about this change; I've always hated MenuStrip and its ilk and never stopped using the originals. Now I've got 20 years of apps that can't be ported to .NET Core without redesigning all of the menus, toolbars, and context menus. |
I note that the linked MSDN article also states:
Since the information on this page no longer applies to .NET Core 3.1, should a documentation issue be raised? I was confused earlier today, as I found the MSDN article before finding this issue. |
The docs have been updated. |
@RussKie I can't understand how this removal benefits your customers at all. WinForms is already a legacy API to begin with. Wasn't the whole point of porting it to .NET Core so that customers could quickly port legacy apps away from .NET Framework? How exactly does removing the lesser-used components accomplish this? |
What makes you think that?
No, not quite. As far as the removal of outdated controls - there were few reasons, e.g.:
To put in perspective, if you as a developer not using accessible controls are you providing a good service to your customers? |
Because it's been in "maintenance mode" since at least 2014 (Microsoft's words, not mine) and Microsoft has stated that there are no plans to add new features.
Are there plans to remove these controls from .NET Framework as well because they do not meet your legal requirements?
I don't think using these components prevented us from providing good service to our customers. There is neither a legal requirement nor a moral obligation to use accessible controls when the customer does not require it. |
- Remove the following API because they have been obsolete since .NET 2.0: * `StatusBar` * `StatusBarDrawItemEventArgs` * `StatusBarDrawItemEventHandler` * `StatusBarPanel` * `StatusBarPanelAutoSize` * `StatusBarPanelBorderStyle` * `StatusBarPanelClickEventArgs` * `StatusBarPanelClickEventHandler` * `StatusBarPanelStyle` Relates to #2091
- Remove the following API because they have been obsolete since .NET 2.0: * `StatusBar` * `StatusBarDrawItemEventArgs` * `StatusBarDrawItemEventHandler` * `StatusBarPanel` * `StatusBarPanelAutoSize` * `StatusBarPanelBorderStyle` * `StatusBarPanelClickEventArgs` * `StatusBarPanelClickEventHandler` * `StatusBarPanelStyle` Relates to #2091
With the deprecation and removal of `MainMenu` control in dotnet#2091 one of MDI scenarios got broken where both parent and child forms don't have `MainMenuStrip` property set nor have `MainMenuStrip` instance added to their respective `Controls` collection. The fix restores setting an MDI menu via `WM_MDISETMENU` message to the parent form. Fixes dotnet#3029
With the deprecation and removal of `MainMenu` control in dotnet#2091 one of MDI scenarios got broken where both parent and child forms don't have `MainMenuStrip` property set nor have `MainMenuStrip` instance added to their respective `Controls` collection. The fix restores setting an MDI menu via `WM_MDISETMENU` message to the parent form. Fixes dotnet#3029 (cherry picked from commit 8d9b1e6)
Problem description:
The following types have been deprecated in .NET Framework:
However this fact was overlooked during the migration, and the types were brought into .NET Core 3.0.
Expected behavior:
The types are not available to consumers via intellisense.
The text was updated successfully, but these errors were encountered: