@ Head : Bug

String.IsNullOrEmpty : update on that nasty null reference exception

bill — Tue, 10 Mar 2009 12:08:26 GMT

Back in April 2006, I blogged about a nasty JIT compiler optimisation that would cause String.IsNullOrEmpty to throw a null reference exception; ironic really given that is the very thing you’d use the IsNullOrEmpty method to check against. Well since then, due to popular demand on the connect site, this bug has been fixed in .NET 2.0 SP1 (which implies .NET 3.0 and 3.5)

940900 (http://support.microsoft.com/kb/940900/ ) FIX: You receive the NullReferenceException exception when you call the String.IsNullOrEmpty function in an application that is built on the .NET Framework 2.0

Work around for MsChart 6.1.89.12 and 6.1.89.13 bug

bill — Fri, 23 Jan 2009 03:06:01 GMT

Last month (December 2008), Microsoft released some security updates for VB6 components such as the MS Chart control

The first update http://support.microsoft.com/kb/932349 updates MS Chart to 6.1.98.12.
The second update http://support.microsoft.com/kb/957924 updates MSChart to 6.1.98.13.

Both these versions have a serious bug that will crash the application or cause instability, the chart not to draw or display garbage strings on the screen.

The problem occurs if you display a DataPointLabel, eg:

Dim dpl As DataPointLabel
Set dpl = MSChart1.Plot.SeriesCollection.Item(1).DataPoints.Item(-1).DataPointLabel

dpl.LocationType = VtChLabelLocationTypeAbovePoint
dpl.ValueFormat = "0.00"

To work around this, add a manifest to your VB6 application, and copy the manifest and an earlier version of MSChart alongside your exe. The manifest contents needed are:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

   <assemblyIdentity name="Project1" version="1.0.0.0"

                     processorArchitecture="X86" type="win32" />

   <file name="mschrt20.ocx">

      <comClass clsid="{3A2B370C-BA0A-11D1-B137-0000F8753F5D}"

                       tlbid="{65E121D4-0C60-11D2-A9FC-0000F8754DA1}"

                       progid="MSChart20Lib.MSChart.2"

                       description="Microsoft Chart Control 6.0 (OLEDB)" />

   </file>

</assembly>

Save that with a .manifest extension, e.g. Project1.exe.manifest. Make sure you replace the name and version attributes in the assemblyIdentity node with your application’s name and version.

Hopefully there will be a fix to fix the fix soon, but in the meanwhile use side-by-side (SxS) COM and an old version of the mschrt20.ocx to work around this new bug.

VB.Net and splash screens

bill — Tue, 20 Jan 2009 00:27:39 GMT

One of the nice things about the My application framework in VB.NET is the ability to easily show splash screens. The splash screen is displayed using a separate thread and by default will close when your main form’s Load event is called. There is however a quirk with it sometimes.

Whilst testing, if I launched the application from Explorer, the splash screen would appear in front of the explorer window but the main form behind it. When the splash screen closed, the main form didn’t come to the foreground. This behaviour would depend on the system being tested and seems to only consistently show up when run from a VPC. The fix for this is reasonably simple: you just need to call Activate in your main form’s Load event

   Private Sub Me_Load(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Load
      Me.Activate()
   End Sub

Kudos to the VB team for the fix :)

When the VB team suggested this fix to me, I could have sworn I had already tried that. I had also looked into the my application framework code and saw it called Activate in it’s handler of the Load. So my first thoughts on it was it was a race condition, and hence I set up a single shot timer to call Activate, the timer being set to trigger a couple of hundred milliseconds after the load event. At first I thought that fixed it, but that was the “sometimes” effect tricking me <g>

Kevin from the VB team suggested I try Activate in the Load event, and sure enough it seems to work *ALL* the time. But this was even more puzzling as to why didn’t my timer approach work. So I tried overriding the OnLoad method :

   Protected Overrides Sub OnLoad(ByVal e As EventArgs)
      MyBase.OnLoad(e)
      Me.Activate()
   End Sub

That actually fails ( yes “sometimes”). But if you change that to:

 
  Protected Overrides Sub OnLoad(ByVal e As EventArgs)
      Me.Activate()
      MyBase.OnLoad(e)
   End Sub

Then it works. So the key is that Activate has to be called before the call to OnLoad completes. Suddenly the pieces of the puzzle all fit together.

What I think is happening is this: The my application framework hooks into the Load event and uses that to dispose of the splash screen. The problem occurs when the splash screen which has the UI input is closed before the call to Activate is made. Because the calling thread doesn’t have the UI Input, SetForeGround window doesn’t work. Based on this hypothesis, I suggested a fix to the WindowsFormsApplicationBase. Currently is has this method in it:

        '''************************************************************************** 
        ''' ;HideSplashScreen
        ''' <summary> 
        ''' Hide the splash screeen.  The splash screen was created on another thread so marshal 
        ''' the call over to it.
        ''' </summary> 
        ''' <remarks></remarks>
        <EditorBrowsable(EditorBrowsableState.Advanced)> Protected Sub HideSplashScreen()
            SyncLock m_SplashLock 'We can get called from two threads at once
               If m_SplashScreen IsNot Nothing AndAlso Not m_SplashScreen.IsDisposed Then 
                    Dim TheBigGoodbye As New DisposeDelegate(AddressOf m_SplashScreen.Dispose)
                    m_SplashScreen.Invoke(TheBigGoodbye) 
                    m_SplashScreen = Nothing 
               End If
               If Me.MainForm IsNot Nothing Then 
                    Call New System.Security.Permissions.UIPermission(UIPermissionWindow.AllWindows).Assert()
                    Me.MainForm.Activate()
                    System.Security.PermissionSet.RevertAssert() 'CLR also reverts if we throw or when we return from this function
               End If 
            End SyncLock
        End Sub 

My suggestion is to activate the main form before disposing of the splash screen :

          <EditorBrowsable(EditorBrowsableState.Advanced)> ProtectedSub HideSplashScreen()    
SyncLock m_SplashLock 'We can get called from two threads at once
IfMe.MainForm IsNotNothingThen     
CallNew System.Security.Permissions.UIPermission(UIPermissionWindow.AllWindows).Assert()                        Me.MainForm.Activate()
                    System.Security.PermissionSet.RevertAssert() 'CLR also reverts if we throw or when we return from this function
               End If
               If m_SplashScreen IsNot Nothing AndAlso Not m_SplashScreen.IsDisposed Then 
                    Dim TheBigGoodbye As New DisposeDelegate(AddressOf m_SplashScreen.Dispose)
                    m_SplashScreen.Invoke(TheBigGoodbye) 
                    m_SplashScreen = Nothing 
               End If
            End SyncLock
        End Sub 

Hopefully that will fix this issue completely.

In the meanwhile, simply call Activate in your main form’s Load event :)

Fixing explorer in Vista

bill — Sat, 16 Feb 2008 01:55:32 GMT

One of the most annoying things I have found about Vista is the file explorer. It constantly changes the views of folders and way too often sets the columns in a folder as if the folder contains photos when it doesn't. To me that is really disappointing and undermines any confidence I could have in Microsoft producing a stable safe OS... the fundamental tasks an OS must do is work with hardware and manage files. If they can't surface that with a stable UI then something seriously is wrong there. I had hoped SP1 would fix the issue, alas it did not. But thanks to some MVPs I saw a link to a site that suggested a registry tweak to fix the problem.. and it did :)

The fix is to add this registry key:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell]
"FolderType"="NotSpecified"

More on XML Namespaces in VB....

bill — Sun, 09 Dec 2007 13:20:24 GMT

A couple of weeks ago I wrote about XML Namespace issues in VB: one in particular was to do with namespace declarations being repeated in the output XML. In those cases we only looked at common namespaces for the entire document.

However the example of creating a word document I posted earlier today raises a similar issue, but this time it's with namespaces that are used in child elements not in the root element. Previously, one suggested workaround was to Import namespaces, and use expression placeholders, but as the word document shows, this does not produce what is often the desirable outcome.

The following simplified example demonstrates this:

- the goal of this exercise is to output the following XML:

<?xml version="1.0"?>
<a:root xmlns:a="url:a" xmlns:b="url:b">
    <b:x></b:x>
    <b:y></b:y>
</a:root>

The constraint is we want to create the x and y elements separately and insert them into the root element. .eg:

Imports <xmlns:a="url:a">
Imports <xmlns:b="url:b">
 
..... 
   Dim el1 = <b:x></b:x>
   Dim el2 = <b:y></b:y>
 
   Dim doc = <?xml version="1.0"?>
             <a:root>
                <%= el1 %>
                <%= el2 %>
             </a:root>

However that doesn't work. The output for that repeats the namespace of the b.

<a:root xmlns:a="url:a">
   <b:x xmlns:b="url:b"></b:x>
   <b:y xmlns:b="url:b"></b:y>
</a:root>

So I thought I would try declaring the b namespace in the root element:

      Dim doc = <?xml version="1.0"?>
               <a:root xmlns:b="url:b">
                  <%= el1 %>
                  <%= el2 %>
               </a:root>

Now that works. That gives the correct output of :

<a:root xmlns:a="url:a" xmlns:b="url:b">

<b:x></b:x>

<b:y></b:y>

</a:root>

But what is going on here you may ask ? Why does this work ? Well VB removes xmlns attributes from the added elements for any declarations that are used in the containing node. So the minimal fix to get my word document have the namespace declarations at the start requires the correct injection of namespaces to the parent they are added to. For example :

Dim thirdParagraph = <w:p

xmlns:dm="http://schemas.openxmlformats.org/drawingml/2006/main"

xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing"

xmlns:dp="http://schemas.openxmlformats.org/drawingml/2006/picture"

xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">

<w:r><%= drawing %></w:r>

</w:p>

I also had to re-declare 2 xml namespaces in the drawing variables; for the document I had to add 5. And that is in just a simple example. What's really annoying is those namespaces were Imported at the module level in the first place. It would have been nice to write that XML literal using the imported namespaces, e.g:

Dim thirdParagraph = <w:p <%= dm %><%= wp %><%= dp %><%= r %>>

<w:r><%= drawing %></w:r>

</w:p>

Alas that doesn't work. Nor does and combination of GetXMLNamespace that I could think of.

In the need I decided it was a lot easier to just add the namespaces once to the root document and remove all of them from added elements, using a modified extension method.

 <Runtime.CompilerServices.Extension()> _
 Function RemoveAllNS(ByVal el As XElement, Optional ByVal includeChildNodes As Boolean = False) As XElement
      Dim current = el.LastAttribute
      Do While current IsNot Nothing
         Dim temp = current.PreviousAttribute
         If current.IsNamespaceDeclaration Then
            current.Remove()
         End If
         current = temp
      Loop
      If includeChildNodes Then
         For Each child In el.Descendants
            RemoveAllNS(child)
         Next
      End If
      Return el
   End Function

It's a shame this doesn't work easier than this :(

Don't "p" on your XAttributes..

bill — Mon, 26 Nov 2007 10:26:43 GMT

If you programmatically add attributes with namespaces to an XElement, when the XElement is written out it will give each attribute a namespace prefix and then define a xmlns for that prefix. The way XElement does this is first it examines the namespaces already active and also those defined in the element for a match. If it doesn't find a match, it then creates a new prefix based on the count of the current namespaces in scope, e.g p1, p2, p3,....pn.

Now sadly, although it did first scan for namespaces, it appears it doesn't scan for prefixes in the current element *after* the current attribute. It does scan for previous declared prefixes, and will use one if the namespace matches. If the namespace doesn't match but a prefix clashes with the proposed prefix, the prefix is added a 0, e.g p10, p20, ... pn0. If that one also clashes then the number will be increased e.g p11, p21, ... pn1. And so forth.

The problem is it doesn't check for clashes inside the element it arbitrarily adds a namespace to. This code causes an exception due to the same attribute being named twice.

  
   Dim books = New XElement("books")
   books.Add(New XAttribute("{abc}attrib1", "one"))
   books.Add(New XAttribute(XNamespace.Xmlns.GetName("p1"), "zzz"))

The moral of the story is don't use "pn" for your namespace prefixes. (where n is any integer). You end up potentially "p"ing on your code ;)

XML namespace prefix 'xmlns' is not defined

bill — Sat, 24 Nov 2007 14:58:27 GMT

When working with VB9 you may get this cryptic error :
XML namespace prefix 'xmlns' is not defined

If you are using only default namespaces you can fix this by including a definition for the xmlns as an Import statement or as an xmlns attribute on the XML literal. But if you are using prefixed namespaces imported at file level, then you must add an imports at project level via the project properties reference tab.

You have two choices:

Import System.Xml.Linq for the entire project, or
Import a namespace for the entire project

If you decide to import a namespace it can be any namespace at all. I named one _do_not_use. Problem is it will show up in XML axis properties in intellisense, but with a name like _do_not_use, that isn't really a big problem. Of course you could add one that you might want to use.

You may prefer to simply import System.Xml.Linq, but I thought I'd at least throw all the alternatives out there for you to decide what suits you best.

hopefully this is another bug that will make it into 2008 SP1 ;)

Cleaning up your XML literal namespaces

bill — Sat, 24 Nov 2007 05:16:00 GMT

If you use XML literals in your code, adding one to another:

Dim e1 = <a:books></a:books>
dim e2 = <a:book></a:book>
e1.Add(e2)

You will have the xmlns declaration repeated in each of the elements, when really it is only needed once per the document or outer element. The problem is caused by VB adding a xmlns declaration as an attribute to the root element. It can get a bit more complex if you have duplicate namespace declarations with different prefixes. So I decided to write a CleanUpNS extension, that keeps the xml written clean by removing un-necessary namespace declarations. To use it, simply add a call to CleanUpNS to the end of your literals, e.g:

Dim e1 = <a:books></a:books>.CleanUpNS
dim e2 = <a:book></a:book>.CleanUpNS
e1.Add(e2)

   <Runtime.CompilerServices.Extension()> _
 Function CleanUpNS(ByVal el As XElement) As XElement
      Dim current = el.LastAttribute
      Do While current IsNot Nothing
         Dim temp = current.PreviousAttribute
         If current.IsNamespaceDeclaration AndAlso el.Name.NamespaceName = current.Value Then
            current.Remove()
         End If
         current = temp
      Loop
      Return el
   End Function

I go into more details about how this works and how the XML is stored and emitted in my January On VB article in Visual Studio Magazine.

What a nasty compiler bug !!

bill — Wed, 21 Nov 2007 01:15:40 GMT

Kathleen has posted about a real nasty bug in the VB 9 (VB 2008) compiler. And I mean nasty !!

The compiler won't warn you, won't give an error of any sort.. it will just omit lines of code from your application ! Yep, it will compile as if nothing is wrong, yet it will remove your code !! If you're lucky, your test scenarios will pick up on this, otherwise expect the unexpected .

It'd be nice if the VB team would post about this and let us all know the exact scale of the problem and when a fix will be available.

Bug in XML literals around the Imports keywords..

bill — Tue, 20 Nov 2007 08:22:06 GMT

In VB9, there's a bug when using XML literals with any type member that is a protected keyword. For example, given the following psuedo types,

Class Doc
Public Property [Imports]() As List(Of DocImports)
End Class

Class DocImports
Public Property [Namespace]() As String

End Class

The following code won't compile:

Dim d As New Doc

Dim xml = <?xml version="1.0" encoding="utf-8"?>
                <Imports>
                   <%= From item In d.Imports _
                      Select <Import><Namespace><%= item.Namespace %></Namespace></Import> %>
                </Imports>

The trick is to escape the Imports property inside the the XML query:

Dim xml = <?xml version="1.0" encoding="utf-8"?>
                <Imports>
                   <%= From item In d.[Imports] _
                      Select <Import><Namespace><%= item.Namespace %></Namespace></Import> %>
                </Imports>

This seems to only apply to some keywords, not all. Imports, Sub, Function all cause the problem, yet Class, Private and Namespace don't. One thing you'll see is the <%= substitution block won't get the characteristic highlight colour.

And another quirk is if the property is called Option, VB will colour that as if it is a keyword even when it is a property such as stock.Option. This one only seems to impact Option, and does not impact the actual compile, only code aesthetics ;)