windows generated code M.I.A.

JoshK

Newcomer
Joined
Apr 12, 2006
Messages
10
Location
Akron, OH
I used to use VB.net 2003 but switched to 2005 recently. I imported and converted one of the programs I was working on into 2005 and finished it. So now I started a new windows app class. I designed a form with lables and text boxes and such, but when I go to code view, it doesnt show the windows generated code for all the controls I just added like in my last program showed. it just has:

Public Class Form1

End Class


nothing else... where all the generated code like


Friend with lblFoo

and

Inherits system.windows.forms
 
I've personally never used Visual Studio 2005, but I do know that it supports Partial Classes. It sounds like the code you are looking for may be stored in a seperate class file, have you checked out all class files in the solution explorer?
 
Look for a file called NameOffile.designer.vb in your project folder. Cags is right about the partial classes and the *.designer.vb files don't show up in the solution explorer to make it a little easier on us when you have tons of code files.
 
I've checked briefly in the options and didn't see it, but there might an option to show these files (I hope so). In C# they are visible by default. You click the "+" next to the form file and it expands to show the resource and designer code files associated with the form's code file. It can be really useful to get at the designer code sometimes, so I certainly hope that there is some way to get access to it other than finding it yourself with explorer.
 
If you want it in your project that bad, then add it (just like any other file). Nothing is stopping you. I think this is a convenience for VB programmers because of the way the designer/event code works in VB versus C# -- you don't really need to see the designer code.
 
Maybe this is a way to protect VB users from themselves, but I can't possibly see it as a convenience. The designer and resource files aren't in the way in C#. You'll only ever see them if you want to see them. It's not like it adds clutter, and I would say that having easy access to the designer code in case you want to tweak it would be more convenient.

Besides, as far as I can tell, the designer and event aspects between the two languages are identical with the exception of the VB Handles keyword, but if you manage your event handling through the designer then even this difference is eliminated.

On the other hand, it would certainly be inconvenient to have to manually add these files every time you add a designer control, and in that case it would absolutely add clutter. Besides that, the constructor is hidden from you by default. (I would certainly prefer to initialize in the constructor rather than a Form_Load event. We are past the VB6 days.) And suppose a programmer new to VB8 wants to add a constructor overload and doesn't know that he needs to call InitializeComponent seeing as he's never heard of such a function.

I can only speak for myself, but when I am creating my own controls, very often I do need to access the designer generated code. When properties and events are modified there is inconsitancy between what was serialized last build and what can be serialized this build, and this often results in designer and compile errors.
 
I was specifically referring to the convenience of the Handles keyword in VB and some of the conventions for form declaration in C#. Notice where the event handler for a button click is added in C# and VB. That is why there is a difference.
Visual Basic:
'Designer Generated Code
' ...
'
'NOTE: The following procedure is required by the Windows Form Designer
    'It can be modified using the Windows Form Designer.  
    'Do not modify it using the code editor.
    <System.Diagnostics.DebuggerStepThrough()> _
    Private Sub InitializeComponent()
        Me.Button1 = New System.Windows.Forms.Button
        Me.SuspendLayout()
        '
        'Button1
        '
        Me.Button1.Location = New System.Drawing.Point(50, 36)
        Me.Button1.Name = "Button1"
        Me.Button1.Size = New System.Drawing.Size(144, 131)
        Me.Button1.TabIndex = 0
        Me.Button1.Text = "Button1"
        Me.Button1.UseVisualStyleBackColor = True
        '
        'Form1
        '
        Me.AutoScaleDimensions = New System.Drawing.SizeF(6.0!, 13.0!)
        Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font
        Me.ClientSize = New System.Drawing.Size(292, 266)
        Me.Controls.Add(Me.Button1)
        Me.Name = "Form1"
        Me.Text = "Form1"
        Me.ResumeLayout(False)

    End Sub
    Friend WithEvents Button1 As System.Windows.Forms.Button
'
' ...
'
' Hand Maintainted Code
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click ' <------Event Handler added here, in the hand maintained section
' ...
End Sub

C#:
// ...
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
            this.button1 = new System.Windows.Forms.Button();
            this.SuspendLayout();
            // 
            // button1
            // 
            this.button1.Location = new System.Drawing.Point(55, 49);
            this.button1.Name = "button1";
            this.button1.Size = new System.Drawing.Size(157, 124);
            this.button1.TabIndex = 0;
            this.button1.Text = "button1";
            this.button1.UseVisualStyleBackColor = true;
            this.button1.Click += new System.EventHandler(this.button1_Click);  // <----- Event handlers are added here in the auto generated section.
            // 
            // Form1
            // 
            this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
            this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
            this.ClientSize = new System.Drawing.Size(292, 266);
            this.Controls.Add(this.button1);
            this.Name = "Form1";
            this.Text = "Form1";
            this.ResumeLayout(false);

        }

        #endregion

        private System.Windows.Forms.Button button1;
// ...
//Hand Maintained Code
private void button1_Click(object sender, EventArgs e)
{
 // ...
}

Plus, I recall many times when the 2003 Visual Studio "wigged out" in C# and I had to manually alter event listeners. I never had issues like that when working with VB. In the end, it is just more convenient to have ready access to designer generated code in C# and not nearly has necessary or common to require access in VB. Once again, VS makes it easy and effecient to do common things very well, while still allowing advnaced users the power and flexibility to do less common, extremely powerful things.
 
mskeel said:
I was specifically referring to the convenience of the Handles keyword in VB and some of the conventions for form declaration in C#. Notice where the event handler for a button click is added in C# and VB. That is why there is a difference.

You understand of course that Handles like AddressOf and many other VB keyword is merely a shim over the existing CLR functionality and doesn't actually exist when compiled. In the case of Handles the compiler simply dumps a lot of event hookup operations into the constructor of the instance which is pretty much identical to the C# way of putting them in the designer InitializeComponent method. If you like it that way then thats fair enough but it is generating a whole load of code behind your back that you get no chance to edit, personally i dislike that.
 
Wraith said:
You understand of course that Handles like AddressOf and many other VB keyword is merely a shim over the existing CLR functionality and doesn't actually exist when compiled.
Correct. But the last time I checked, I wasn't writing code in IL so it's kind of a moot point. If it were handled any other way I would be alarmed and concerned. I was just tossing up a possibility for why things might be handled the way they are, which seems plausible. It is merely a syntactic difference. (marble_eater might even call the handles keyword sugar ;) )


Wraith said:
If you like it that way then thats fair enough but it is generating a whole load of code behind your back that you get no chance to edit, personally i dislike that.
First off, it's not that you don't have access to that code (as you can always add it to your project, open it in a text editor, etc.). I'm not quite sure what would happen if you modified the "Auto Generated" code by hand. Would it be the case that manually adjusted designer code would show up in the designer? I'm pretty sure that would happen. If that is definitely the case, then I would make the argument that one auto-generation technique isn't really "better" than the other; they are just different and applicable in different situations for different people.

Personally, I find VB to easier to work with when creating simple to moderate windows forms and C# easier the rest of the time (libraries, complex forms, etc.). The C# designer is significantly improved in VS2005 (in my opinion) so the differences are even less now than they were before for me. But, as you implied, to each his own and there's nothing wrong with that.
 
mskeel said:
First off, it's not that you don't have access to that code (as you can always add it to your project, open it in a text editor, etc.).
You don't have access to the code. If you manually subscribe to events as is the c# idiom then you will have access to the code but the VB Handles keyword causes code to be generated at compile time which is not present in any code file. Yes its a keyword, yes its syntactic sugar lie lock and using statements however i would content that the scope of the code it hides is far far greater than that of those enclosing statements because it can affect almost any compile time present method.

I'm not quite sure what would happen if you modified the "Auto Generated" code by hand. Would it be the case that manually adjusted designer code would show up in the designer?
It depends if the designer understands the change made and picks up the new value. At best it'll be left present or slightly altered by subsequent autogeneration. More commonly it just gets thrown away or causes an error to be thrown in the designer which can be a pain to track down.

I'm pretty sure that would happen. If that is definitely the case, then I would make the argument that one auto-generation technique isn't really "better" than the other; they are just different and applicable in different situations for different people.
Chunks of autogenerated code are like any other code but i don't think autogenerated code which can have important causal affects on program functionality or stability are quite the same as a simple wrapper around a try-finally block, its a question of the affected scope not a question of auto generation.
 
Wraith said:
If you manually subscribe to events as is the c# idiom then you will have access to the code but the VB Handles keyword causes code to be generated at compile time which is not present in any code file.
I'm ready to learn. I don't quite see how the event/method binding is different and you "don't have access to the code." As far as I can tell, however you say it,
Visual Basic:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
And
C#:
this.button1.Click += new System.EventHandler(this.button1_Click);
still binds button1's click event to the method button1_Click. What specific code do you want that you don't have access to in VB? What do you have in C# that is sooo much better than in VB? I'm a little confused and don't see what the problem is here. In VB, with the Handles keyword there really isn't a need to have "access to the code" in the same way as you do in C# -- because there isn't any code for you to have access to. The languages are just different. But, as I said, I'm ready to learn :), so please teach me.
 
mskeel said:
I'm ready to learn. I don't quite see how the event/method binding is different and you "don't have access to the code." As far as I can tell, however you say it.
Simply because the Handles suffixes are translated to lower level delegate syntax and added to the .ctor. If its generated at compile time it isn't present at coding time, if its auto-placed (as it is) i don't get to choose where it goes. You can argue that i wouldn't get a choice in c# either but InitializeComponent isn't actually a contract merely a convinience as you know.


What specific code do you want that you don't have access to in VB? What do you have in C# that is sooo much better than in VB? I'm a little confused and don't see what the problem is here.

I dislike things turning up in my compiled il that i didn't put there, VB takes Handles and generates a lot of delegate instructions and puts them where it wants them. Its a personal perference that i got into when moving from vb6 to c#, i really dislike things trying to be clever and altering what i've written behind my back.

I've never said there is anything better about c# in this regard. I do think it is slighly cleaner because it limits itself to locally scoped generation like using() and lock() statements but i happily do without those as well.

In VB, with the Handles keyword there really isn't a need to have "access to the code" in the same way as you do in C# -- because there isn't any code for you to have access to.
I find it disingenuous, it is allowing the old VB model to persist in a system which does not conform to that model much as AddressOf and AddHandler are, they're not OO and they just hide what really happens in peculiar syntax.

I don't use VB because i don't much like it, i find it frustrating to work with becaause i constantly have to look up how the language abstracts the concept i want to work with. Thats my choice. On the other hand if that works for other people then i have no problem with it for the most part. What bothers me is there an explanation of something is incomplete of incorrect because the language is hiding important implementation details from the user.
 
Wraith, you bring up very interesting and valid points especially when you look at VB and C# in terms of the "pure .net" realm. I think it's a mistake to try and compare VB and C# as if, to use a cliché, we were comparing apples to apples but it happens all the time. While they both might compile to the same IL, they are two different languages with two different purposes and two different ways of going about things.

Personally, I'm a huge fan of code generation in many cases and in this case it just makes things easier. I can see how it might be annoying to some folks especially in specific, complex situations. I bet My namespace just drives you nuts! :)

With regards to event handlers and designer code for VB versus C#, I guess it does just come down to personal preference all the way back to where the code is stored/shown. I can see, from your perspective now, why the MIA designer code in the partial class would be extremely annoying. Basically, it goes against your expectations on what you should have immediate access to. Cool. I can dig that.
 
I hope we aren't getting too off-topic here...

Although Microsoft embraces the concept of a common language platform, they also acknowledge that each language is its own language, and they all have their own features. How these features are implemented in terms of IL is not particularly relevant. In just about any language, with the exception of IL or ASM, what you see is not what you get. This may be less the case with .Net than X86, but new features which don't have analogous .Net instructions and classes simply won't look the same in IL as they do in VB, C#, or whatever the language might be. The fact is that when you use the "Handles" keyword, you are asking for automatic event wiring and the compiler is only doing what it must to make that happen. I am of the opinion that a programmer should know what is going on behind the scenes before he uses any particular feature, for the sake of understanding what cost or benefit that feature will ultimately provide. That being said, all the extra "behind the scenes" IL for a "Handles" clause... well that is represented in your code. It is represented by the "Handles" keyword. It isn't being done behind your back, you are telling the compiler to do it. You just need to understand what you are telling the compiler to do. I also think that Microsoft has a responsibility to clarify what is going on behind the scenes in VB so that programmers can understand what their code really means, which they don't do very well--I'll give you that. And that brings me to another point.

Microsoft seems to be of the opinion that black-box features are a good thing for VB. Things that just work without any how or why. Things like default instances, Visual Styles, automatic event wiring, and designer created objects. These are all real nice things, but what bothers me is that they seem to almost go out of their way to hide the implementation from you. Many of these features are also present in C#, but the designers and options result in code files presented to you, clear as day. You are free to modify and free to understand. I can't possibly understand what advantage hiding designer-generated code could provide to VB programmers unless you are of the opinion that they need to be protected from themselves, or that they can't handle the complexity of expanding tree nodes in the solution explorer or are not intelligent enough to make use of designer-generated code. And I'm not giving VB programmers a hard time, here. Quite the opposite. I'm saying that they deserve more credit than that. They deserve more than "Here, it works, be happy." If you don't want to see the behind-the-scenes stuff, fair enough. I think it should be an option, though.
 
I'm personally of mixed opinion about this. Understanding what goes on 'behind the scenes' can certainly be important at times, but I also feel that many many programmers out there really don't need to understand these details. Things such as the Handles keyword basically embody the idea of encapsulation, allowing developers to use the feature without really needing to worry whats actually going on in the background. In my opinion its just another step towards making programming languages more accessible to new programmers.
 
Encapsulation is all good and well, and obviously, we can't expect a new programmer to learn everything at once, but as time goes on every programmer should eventually come to understand what a "Handles" clause really means and how a foreach loop really works. Sure it is nice when things just magically work, but I think it is nicer when you know how they work. I just think the information should be readily available. Sometimes it is, sometimes it isn't. But if you don't care how a foreach works, just don't read the documentation. It doesn't put more of a load on a novice, it just adds more to the expert's toolbox.

Just for a quick example, if you are run into a bottleneck while performing an operation over a large collection, you could save a handful of CPU cycles by understanding that a For Each loop has the overhead of instantiating an IEnumerator and many more function calls than a regular For loop.
 
I'm not sure which language you are talking about specifically when you compare a for loop to a for each loop, perhaps you are simply refering to the framework as a whole. I have however read somewhere (can't remember where it might not be completely accurate) that the comparison you gave is antiquitated and infact there is currently very little performance difference between the two loop methods.

Sorry this is getting abit off topic, but I think we solved the thread starters problem so hopefully this isn't too much of an issue.
 
We aren't entirely off topic... too far... I hope.

First of all, the foreach example was just an example. There are plenty of others.

Depending on what you are doing the difference between a foreach and a for loop can be enough to make a difference. A foreach loop requires the instantiation of an IEnumerator (one hit per foreach loop). Then, in order to iterate a call is made to MoveNext, and if that returns true, a call is made Current to obtain the object, which must be stored in a variable. A foreach is also automatically wrapped in a structured exception handling block. The foreach loop (at least in C#... I'm not positive about VB) is optimized for arrays, but for all other IEnumerable types you will see a performance hit.

A foreach on an arraylist would compile from this:
Visual Basic:
For Each o As Object In myArrayList
    If o Is SomeOtherObject Then
        Return o
    End If
Next
to
Visual Basic:
' IEnumerator instantiation
Dim i As IEnumerator = DirectCast(myArrayList, IEnumerator).GetEnumerator();
 
While i.MoveNext() 'Extra function call
    Dim o As Object = i.Current
    If o Is SomeOtherObject Then
       Return o
    End If
End While
There are a little more than half as many IL instructions in the equivalent for loop, and that isn't counting the function calls to GetEnumerator and MoveNext.

Using VB8 Express console application, I did a quick benchmark with an unsorted ArrayList of 100,000,000 objects where the ArrayList was searched linearly for a specific object inserted at a random position using a For and For Each loop with a release build, and then repeated the test with For Each first and then For after. The results are as follow:
Code:
For     ForEach    Ratio
78	547	7.012820513
94	656	6.978723404
78	547	7.012820513
47	313	6.659574468
31	219	7.064516129
16	46	2.875
63	437	6.936507937
15	157	10.46666667
31	172	5.548387097
47	312	6.638297872
47	281	5.978723404
As you can see, a ForEach loop over an ArrayList takes approximately six to seven times as long as a For loop. I would call that a signifigant difference in performance. The IL for C# and VB ForEach loops would be very similar, so you would see this difference in C# also.

Is this essential knowlege? No, but it sure helps. Is this something we should expect a new programmer to know. If you ask me, the answer is eventually.
 
I don't mean to be a wet blanket here (because I think this is all very interesting) but I think the conversation has deviated a little too far off topic. This thread is about the location and reasoning behind designer generated code in Visual Studio 2005 -- not differences between C# and VB, your opinions on VB's "dumbed down" or "black box" approach, or loop performance. So, unless it has to do, somehow, with designer code generation, I think we should let this thread rest and start directing unrelated posts to a new thread.
 
To answer the original question here, select "Show all files" under the "Project" menu to show the hidden designer files.
 
Back
Top