Bugs

VisualStudio.Bugs History

Hide minor edits - Show changes to output

February 19, 2010, at 04:33 AM by 136.159.48.59 -
Changed lines 41-44 from:
!!InputHitTest not work properly with a Panel
A panel class (Grid, DockPanel, and etc) calls InputHitTest will not detect the first depth search child of this panel. If the method takes a coordinate on its first, deepest child, it will return null rather than the child expected.

Workaround: use panel.InputHitTest(point) || firstchild
.InputHitTest(point)
to:
!!InputHitTest not work properly with a Panel that has or is a first, depth search child of another Panel
A panel class (Grid, DockPanel, and etc) calls InputHitTest will not detect the first depth search child of this panel. If the method takes a coordinate on its first, deepest child, it will return null rather than the child expected
. If the panel is a first, deepest child of another panel, calling InputHitTest on this panel will always return null.

Workaround: use panel.InputHitTest
(point) || firstchild.CoverPoint(point) where CoverPoint is a manual check of coordination.
February 19, 2010, at 04:13 AM by 136.159.48.59 -
Changed line 36 from:
!!Popup Windows loses data context
to:
!!Popup Windows lose data context
Added lines 40-45:

!!InputHitTest not work properly with a Panel
A panel class (Grid, DockPanel, and etc) calls InputHitTest will not detect the first depth search child of this panel. If the method takes a coordinate on its first, deepest child, it will return null rather than the child expected.

Workaround: use panel.InputHitTest(point) || firstchild.InputHitTest(point)
Changed lines 1-2 from:
I think I need to write this blog on a number of critical bugs in MS .Net Framework. These bugs are stale and MS never bothers to fix them.
to:
Yibo writes this blog on a number of critical bugs in MS .Net Framework. These bugs are stale and MS never bothers to fix them.
Changed lines 34-39 from:
Workaround: call UIObject.dataContext = null followed by UIObject.dataContext = dataObject will force a re-binding.
to:
Workaround: call UIObject.dataContext = null followed by UIObject.dataContext = dataObject will force a re-binding.

!!Popup Windows loses data context
A popup windows (Popup class) will inherit the data context from its parent control (where it is popped up from). The data context will be lost if the focus moves to another control when the popup is still open. This is ok. But the data context is not restored next time the popup is shown.

Workaround: manually restore the datacontext object in a event handler (e.g. ContextMenuOpening)
.
Added lines 31-34:
!!WPF Databinding DataContext update breaks binding
Sometimes, you changed a variabe (not a property but affecting other properties bound) in a data object and WPF won't update the UI. This makes sense because WPF only knows when properties are changed. So you just do a UIObject.dataContext = dataObject (you called this same statement somewhere before). This does not update the UI but destroys the binding compeleted. This makes no sense.

Workaround: call UIObject.dataContext = null followed by UIObject.dataContext = dataObject will force a re-binding.
November 22, 2009, at 06:49 AM by 136.159.48.59 -
Changed lines 27-28 from:
Sometimes a simple control's width is larger than the actualwidth by a small margin (1-5, random to my observation) for no apparent reason. In other words, if you set control.width = value, the control is sized to value with the actualwidth being value; however, control.with may actually jumps to a slightly larger value at certain point.
to:
Sometimes a simple control's width is larger than the actualwidth by a small margin (1-5, random to my observation) for no apparent reason. In other words, if you set control.width = value, the control is sized to value with the actualwidth being value; however, control.width may actually jump to a slightly larger value at certain point (although this happens really rarely).
November 22, 2009, at 06:48 AM by 136.159.48.59 -
Changed lines 24-30 from:
Workaround: check the count before the loop. Sounds retarded but works.
to:
Workaround: check the count before the loop. Sounds retarded but works.

!!Width/ActualWidth difference
Sometimes a simple control's width is larger than the actualwidth by a small margin (1-5, random to my observation) for no apparent reason. In other words, if you set control.width = value, the control is sized to value with the actualwidth being value; however, control.with may actually jumps to a slightly larger value at certain point.

Workaround: always use actualwith if possible.
Changed lines 18-24 from:
No Workaround found.
to:
No Workaround found.

!!foreach loop null reference
foreach (string aString in stringList) will throw a null reference exception, where stringList is an ObservableCollection<string> holding 0 elements.
Sounds ridiculous but it happens.

Workaround: check the count before the loop. Sounds retarded but works
.
June 11, 2009, at 06:35 PM by 136.159.7.41 -
Added line 17:
June 11, 2009, at 06:35 PM by 136.159.7.41 -
Changed lines 15-16 from:
Sometimes resources are indeed compiled into assemblies but they still won't load. In this case, the program may or may not throw an exception which can be either a IOException:Cannot locate resource or a DirectoryNotFoundException if you put your resources in a folder (like images/image.png). I can't figure out what's going on; Rebuilding without changing any code could fix it sometimes but not always. If rebuilds won't fix it, try alternative syntax: I just switch between new Uri("images/image.png", UriKind.Relative) and new Uri("pack://application:,,,/images/image.png"). Combine rebuilding and alternative syntax(both syntax should work the in the same way in theory).
to:
Sometimes resources are indeed compiled into assemblies but they still won't load. In this case, the program may or may not throw an exception which can be either a IOException:Cannot locate resource or a DirectoryNotFoundException if you put your resources in a folder (like images/image.png). I can't figure out what's going on; Rebuilding without changing any code could fix it sometimes but not always. If rebuilds won't fix it, try alternative syntax: I just switch between new Uri("images/image.png", UriKind.Relative) and new Uri("pack://application:,,,/images/image.png") back and forth. Combine rebuilding and alternative syntax(both syntax should work the in the same way in theory) will eventually fix it.
I know you will be pretty mad; me too.
June 11, 2009, at 06:23 PM by 136.159.7.41 -
Changed lines 13-14 from:
This really gave me enough headache. The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times.
to:
This really gave me enough headache. The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times. Before you swear, double check if you mark your resources as "Resources" instead of "Content". If you don't specify the resources to be "resources", you can't blame MS.
June 11, 2009, at 06:20 PM by 136.159.7.41 -
Changed lines 13-17 from:
The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times.
to:
This really gave me enough headache. The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times.

Sometimes resources are indeed compiled into assemblies but they still won't load. In this case, the program may or may not throw an exception which can be either a IOException:Cannot locate resource or a DirectoryNotFoundException if you put your resources in a folder (like images/image.png). I can't figure out what's going on; Rebuilding without changing any code could fix it sometimes but not always. If rebuilds won't fix it, try alternative syntax: I just switch between new Uri("images/image.png", UriKind.Relative) and new Uri("pack://application:,,,/images/image.png"). Combine rebuilding and alternative syntax(both syntax should work the in the same way in theory).

No Workaround found
.
June 11, 2009, at 06:12 PM by 136.159.7.41 -
Added lines 10-13:

!!WPF Resource

The Visual Studio Compiler sometimes just won't compile resources into assembly properly for no reason. If you resource won't load, just right click on the project and do rebuild for a hundred times.
June 11, 2009, at 06:11 PM by 136.159.7.41 -
Added lines 3-4:
!!Deserialization in Dll
June 04, 2009, at 04:11 AM by 136.159.7.41 -
Added lines 1-7:
I think I need to write this blog on a number of critical bugs in MS .Net Framework. These bugs are stale and MS never bothers to fix them.

You can't deserialize an object from a dll. Why? This is the way how the deserializer works. In the serilization stream, the serializer BinaryFormatter.serilize() write along the info of the assembly in which the serializable class is defined. On the other end, the deserilizer BinaryFormatter.serilize() will try to load the assembly whose info is retrieved from the stream; if the serializable class definition is in your executing exe, it works fine; if the serializable class definition is in an external dll which is located in the same directory in your file system, it works fine too; it will not work if the serializable class definition is in an external dll which is located in the same directory in which the executing exe is in.

Therefore, don't use serializable class in a dll which is not located in the executing directory even though it is located in a sub directory.

Workaround: put all dlls in one directory; try to find something in the .net framework to substitute your serializable class even thought this is hacky.