""Jeffrey Tan[MSFT]"" wrote:

> Hi Michael,
>
> Thanks for the feedback of the debugger version!
>
> Oh, yes, I originally used VS.net2003 debugger to do the test, so I am
> seeing different behavior from you. By using the VB2005, I can reproduce
> the behavior with the testing code below:
>
> Public Class Form1
> Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles MyBase.Load
> test.Test_method()
> End Sub
> End Class
>
> Public Class test
> Public Shared Sub Test_method()
> Console.WriteLine(Form1.DataSet11.Tables(0).DefaultView.RowFilter)
> End Sub
> End Class
>
> Yes, in VB2005 we can use the Form1(class name) to refer the dataset
> instance without using the real Form1 reference(like Me keyword). This is a
> new language enhancement in VB2005. However, we still can not use this
> approach in the debugger "Immediate Window" or "Watch Window", below is the
> confirmed test result:
>
> From Watch Window:
> Form1.DataSet11.Tables(0).DefaultView.RowFilter Reference to a non-shared
> member requires an object reference.
>
> From Immediate Window:
> ? me.DataSet11.Tables(0).DefaultView.RowFilter
> ""
> ? Form1.DataSet11.Tables(0).DefaultView.RowFilter
> Reference to a non-shared member requires an object reference.
>
> Below is the analysis details:
> After some investigation, I find that the VB2005 compiler does the magic in
> this issue. If we are using *Form1* class name instead of form reference in
> the code, the VB2005 compiler will emit an extra "ImmediateWindowTest.My"
> namespace (my testing application's name is "ImmediateWindowTest") which
> contains several compiler synthesized hidden classes:
> MyApplication
> MyComputer
> MyProject
> MySettings
> MySettingsProperty
>
> These classes are used to support the VB2005 language enhancement. For
> example, ImmediateWindowTest.My.MyComputer class is used to support
> My.Computer.Audio.Play() usage in VB2005. So was the
> Form1.DataSet11.Tables(0).DefaultView.RowFilter usage in our source code.
>
> If we use Reflector to view the compiled code of Test_method(), we will get
> the following code:
>
> Public Shared Sub Test_method()
>
> Console.WriteLine(MyProject.Forms.Form1.DataSet11.Tables.Item(0).DefaultView
> .RowFilter)
> End Sub
>
> So the *Form1* class name in our code is actually redirected to
> "ImmediateWindowTest.My.MyProject.Forms" shared property, which is emitted
> dynamically by VB2005 compiler. Using Reflector to view this shared
> property, we will get this:
>
> <HelpKeyword("My.Forms")> _
> Friend Shared ReadOnly Property Forms As MyForms
> Get
> Return MyProject.m_MyFormsObjectProvider.GetInstance
> End Get
> End Property
>
> So this "Forms" shared property returns a MyProject.MyForms class instance.
> "MyForms" is another internal class included in "MyProject" class, if you
> use Reflector to naviate to "MyProject.MyForms" class, you find there is an
> extra "Form1" shared property which is listed below:
>
> Public Property Form1 As Form1
> Get
> Me.m_Form1 = MyForms.Create__Instance__(Of Form1)(Me.m_Form1)
> Return Me.m_Form1
> End Get
> Set(ByVal Value As Form1)
> If (Not Value Is Me.m_Form1) Then
> If (Not Value Is Nothing) Then
> Throw New ArgumentException("Property can only be
> set to Nothing")
> End If
> Me.Dispose__Instance__(Of Form1)(Me.m_Form1)
> End If
> End Set
> End Property
>
> Now, the VB2005 implementation is clear: VB2005 compiler will synthesize
> some hidden internal classes to contain the Form reference in "m_Form1"
> field, so that we can leverage *Form1* class name to access the member
> field of the Form1 class. All the magic is taken care of by VB2005 compiler
> while generating the assembly.
>
> Let's turn our attention to the original issue. Why the VB2005 debugger can
> not recognize and use the *Form1* magic? This is because both the "Watch
> Window" and "Immediate Window" will execute what we typed code in the
> context of the debugging application runtime. Since this is runtime, VB2005
> has not chance to detect *Form1* class name and redirect it into
> *MyProject.Forms.Form1* shared property to obtain the form reference. The
> runtime debugger will only interpret the code directly, so it will treat
> *Form1* only as class name, which generates "Reference to a non-shared
> member requires an object reference".
>
> Based on our analysis, we can see this behavior is by design. Without the
> magic help from VB2005 compiler, it is hard for the VB2005 runtime debugger
> to recognize the "Form1" should be redirected to *MyProject.Forms.Form1*
> shared property.
>
> Hope this information helps.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>