Windows Forms Run-Time Breaking Changes

  • Article
 
Short Description Addition of missing values to the KnownColors enum in order to support new System Colors
Affected APIs System.Drawing.Color: public KnownColor ToKnownColor() public static Color FromKnownColor(KnownColor color) public bool IsKnownColor { get ;} Outside the scope of a "breaking change": Addition of static member variables to SystemColors, SystemBrushes, SystemPens for these colors Severity Low Compat Switch Available No
Description Addition of missing values to the KnownColors enum to support new System Colors. ButtonFace ButtonHighlight ButtonShadow GradientActiveCaption GradientInactiveCaption MenuBar MenuHighlight. These are required to (1) support new System colors, (2) to support new controls. If we don't add these values design time persistence will persist these colors as RGB values making the app that uses them not respect user system color change.
User Scenario It is highly unlikely that user code will ever use these values directly—they will consume SystemColors.ButtonFace or SystemPens.ButtonFace. Beyond color translation at design time we are literally one or two places where this class is referenced across the whole of Windows Forms—we use SystemColors and SystemPens. KnownColors is an artifact of the way we create the System* set of static classes. It is also used for design time serialization support. Except for the Color API to translate to and from KnownColors there are no APIs that take KnownColor.
Work Around Use Color.FromKnownColor, ToKnownColor and IsKnownColor
 

 

 
Short Description TabControl Enter and Leave events are raised for Tabs being clicked in addition to when focus leaves a TabPage
Affected APIs empty Severity Low Compat Switch Available No
Description See description
User Scenario If a user had (interop) code to track the selection or deselection of a TabPage based on tab clicks, and they had the same code in TabPage.Enter and Leave their code might run too often.
Work Around Make sure that the Enter and Leave event handlers are robust enough to be called more often
 

 

 
Short Description Mouse Enter and Leave events are now raised for for scrollbars on ScrollableControl
Affected APIs none Severity Low Compat Switch Available No
Description We added the RaiseMouseEnterLeaveEventsForScrollBars property but now can't think of a scenario that would be broken if we ripped this property and always behaved as if it were set to true.
User Scenario The customer had hooked enter/leave events for all controls on the form (and controls underneath those, recursively). They were tracking which control the mouse was over by using these events—if the last of these was a leave event, they weren't on a control. If the last was an enter event, they knew which control they were on. They were getting unexpected results when they went to a Panel's scrollbar: they got a leave event, and didn't think they should be on a control.
Work Around n/a
 

 

 
Short Description Calling TreeNode.Bounds.Location in the Form's Load event returns 0,0
Affected APIs TreeNode.Bounds.Location Severity Low Compat Switch Available No
Description If a user was checking the Location of a TreeNode in the Form's Load event, it would return the proper x, y coordinate. Now it returns 0,0 until the Handle is fully created.
User Scenario If a user was checking the Location of a TreeNode in the Form's Load event, it would return the proper x, y coordinate. Now it returns 0,0 until the Handle is fully created.
Work Around Wait until the handle is fully created before accessing the Location property of a TreeNode.
 

 

 
Short Description The first RadioButton in a group doesn't become checked when the first RadioButton in that group gets focus
Affected APIs RadioButton Severity Low Compat Switch Available No
Description When a user sets up a Form with a RadioButton group and no radio is selected, the first radio in the group would become selected in previous versions. Now we only select an item if the user presses space or one of the arrow keys when focus is in the radio button group.
User Scenario Data entry form.
Work Around n/a
 

 

 
Short Description no KeyPress event for (Char)127 + different handling comparing to v1.x.
Affected APIs SendKeys.SendWait Severity Low Compat Switch Available No
Description Bug fix to correctly handle "DEL" when sent via SendKeys.
User Scenario SendKeys.SendWait("{DEL}") works correctly. Rolling back this change, will break that scenario.
Work Around empty
 

 

 
Short Description ComboBox.PreferredHeight does not return the correct value as expected
Affected APIs ComboBox.PreferredHeight Severity Low Compat Switch Available No
Description ComboBox.PreferredHeight was changed to return the correct value. This change was made as part of the layout work.
User Scenario Any measurement painting code
Work Around None
 

 

 
Short Description BindingContextChanged event fires less number of times when LB is added/removed to a form.
Affected APIs None Severity Low Compat Switch Available No
Description Side effect of fixing a bug in ListBox control creation. In V1.1 we we're re-creating the ListBox 2 on parent changes and on initial creation. This resulted in BindingContextChanged firing too many times.
User Scenario Only affects a user that is counting BindingContextChanged events.
Work Around None
 

 

 
Short Description January PAG blocks are broken on v2.0.
Affected APIs IDictionaryService Severity Low Compat Switch Available No
Description The customer is providing a global implementation of IDictionaryService. The proper documented useage is to provide one implementation per Site. Our v1.1 docs clearly state that this interface should be provided on a per site basis. If a user somehow got away with violating this usage, it might work in some cases, but they would likely experience some errors in v1.1. For example, any 3rd party library can add values to the IDictionaryService—and expect those values to be per control. Making this service global breaks them. https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcomponentmodeldesignidictionaryserviceclasstopic.asp "Provides a basic, component site-specific, ... " This team is providing this service globally and not following msdn docs.
User Scenario End user consuming the Janurary PAG blocks sees imcomoplete data in the property grid.
Work Around Provide the IDictionary service per Site.
 

 

 
Short Description Layout events occur more frequently and earlier in v2.0 than in v1.1.
Affected APIs Layout event Severity Medium Compat Switch Available No
Description The user app sets the Form's font before the the call to InitializeComponent. Setting the Font didn't raise a Layout event in v1.1 but now does in v2.0. In the user app's Layout event handler they are accessing a control on the form. Since this code is now running before InitializeComponent, the control is null and the crashes with an exception
User Scenario Setting the Form's Font or RightToLeft before InitializeComponent is called, then trying to access a control on the form.
Work Around Recompile the app to move the call to set the Form's control.
 

 

 
Short Description The Cursor property is now respected for the ComboBox Text area.
Affected APIs ComboBox.Cursor Severity Medium Compat Switch Available No
Description The Cursor property is now respected for the ComboBox Text area. In v1.1, the cursor would always stay as the arrow, regradless of the Cursor property.
User Scenario N/A
Work Around N/A
 

 

 
Short Description Windows Forms will now throw an IllegalCrossThreadException when a debugger is attached and a property of a control is accessed from a thread it wasn't created on.
Affected APIs Control Severity Medium Compat Switch Available No
Description Windows Forms controls are not guaranteed to work if modified from a thread they weren't created on. This will work 90% of the time, but will fail spuriously and provide little information why. To enforce this, we throw an InvalidOperationException if a control is accessed across threads. This exception is only thrown if a debugger is attached. To disable this exception, you can set the static Control.CheckForIllegalCrossThreadCalls property to false. If you're getting this exception, you can use the new BackgroundWorker component to marshal information from the background thread to the UI thread. You can then modify controls based on the information returned.
User Scenario N/A
Work Around Use the new BackgroundWorker component for threadding.
 

 

 
Short Description Backgrounds that were transparent in v1.1 are showing up as grey in v2.0
Affected APIs N/A Severity Medium Compat Switch Available No
Description In v1.1 a top level Form with it's BackgroundImage set to an Image with a transparent color would be drawn with the transparent area transparent to the desktop on the first paint.
User Scenario Splash screen
Work Around Use Region proeprty or TransparencyKey proeprty on form.
 

 

 
Short Description Setting the ImageList.Stream property to null now clears the images in the list.
Affected APIs ImageList Severity Medium Compat Switch Available No
Description In v1.1 setting the ImageStream property on ImageList to null had no affect. In v2.0, the property now nulls out the underlying image stream and clears the image list.
User Scenario N/A
Work Around N/A
 

 

 
Short Description Controls with a FlatStyle property now render using VisualStyles with FlatStyle.Standard set.
Affected APIs Button, CheckBox, RadioButton, GroupBox. Severity Medium Compat Switch Available No
Description In order to prevent users from having to set the FlatStyle property on all their controls to FlatStyle.System, and to provide the extra functionality that FlatStyle.Standard controls have with visual styles, the rendering path for these controls was modified to use visual styles when available.
User Scenario N/A
Work Around Disable visual styles on your application or use FlatStyle.Popup or FlatStyle.Flat.
 

 

 
Short Description Accessibility changes completed in v2.0 may affect users using an accessibility reader.
Affected APIs AccessibleObject and its subclasses. Control.AccessibilityObject. Control.CreateAccessibilityInstance Severity Medium Compat Switch Available No
Description There have been considerable amounts of fixes to improve how accessible Windows Forms is. These changes enable us to meet accessibility 508 guidelines. Unfortunitely most changes will break someone who is using accessibility objects to automate their applications in 1.0/1.1. Examples of breaking change categories: 1) Raising accessibility events that either didn't exist before or raising events in different order or with different information. 2) Changing the role of a control/element. 3) Changing the behavior/return value of a Acc object function such as HitTest or Select. 4) Changing the order of accessibility children for an object. 5) Changing the default action for an object.
User Scenario User is using an accessibility reader.
Work Around No workaround for end user. Developer would have to wrap each control and re-implement accessibility code (e.g. ControlAccessibleObject) to revert the behavior.
 

 

 
Short Description Windows Forms parameters have had some name changes.
Affected APIs See description Severity Medium Compat Switch Available No
Description System.Windows.Forms.GridColumnStylesCollection () protected void OnCollectionChanged (CollectionChangeEventArgs ccevent) (parameter name changed from ccevent to e) System.Windows.Forms.Help() public static void ShowHelp (Control parent, string url, HelpNavigator command, object param) parameter names changed from param to parameter System.Windows.Forms TabControl () protected void UpdateTabSelection (bool uiselected) parameter name changed from uiselected to updateFocus System.Windows.Forms.ScrollableControl protected virtual void OnPaintBackground (PaintEventArgs pevent) parameter name changed from pevent to e
User Scenario Only affects late bound scenarios that depended on exact parameter names.
Work Around None