@ Head

OK, I shoulda used CInt() - would that have made you happier? <g>

I'll have to smack Paul for unleashing you on the world... ;)

Welcome!

yag

Hey, thanks Yag. Yeh, Cint, or Val or CStr etc are all good examples of how VB's intrinsic methods are *usually* faster, as well as being way more functional. Left was, a bit "left" field ;-)

Another VB blogger!

LOL. Thanks Paul. Should be fun !!

Most VB coders I've seen writing code turn the procedure line separator feature off. However, very interesting to know about the compiler "_" prefixing.

What is your preferred style? I believe the Design Guidelines for Class Library Developers[1] says not to use any prefix notation, but it is convenient (maybe more out of habit than not) to use a prefix.

[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

Late binding is a definite plus to using Office through Interop, otherwise you could end up writing a ton of extra code to get the strong typing.

Is it worth it? Like any cryptic answer, it Depends. <g> I think in certain scenarios it can definitely help, but as an otherwise general practice it should probably be avoided.

Even when you are working with Office through interop, it really is just a question of casting to the type you know you are working with. If you know the member name, you should be able to cast.

Personally, I still use the good old try and tested m_ prefix for fields. And interestingly enough so do a lot fo folk at Microsoft. If you do a bit of reflection on the framework class libraries, I think you'll find that it's about a 50/50 split between _ and m_. Of course there are some cases where they have used case sensitivity of all things. Fortunately FXCop lists that oen as a warning, and now that it is included inside VS.NET, that bad practice should be cleaned up reasonably soon :)

Check this one if you want to have it for VS.NET 2003:

http://weblogs.asp.net/gmilano/archive/2004/05/05/126491.aspx

You can suggest him to add the 'Close All After This' option ;)

The Visual Basic.NET Internals article (published on the MSDN web site) referenced by Paul in his blog says this about Left:

<snip>

The Mid, Left, and Right methods in Visual Basic .NET all call String.Substring. However, the Visual Basic Runtime methods are optimized to prevent string allocation for some common cases. For example, the following simple case is 85 percent faster using the Visual Basic Runtime methods versus the System methods:

Dim s1, s2 As String
s2 = "abc"

' fast, prevents string allocation
s1 = Left(s2, 3)
' SubString is not optimized for this case
s1 = s2.SubString(0, 3)
<snip>

The article's example Left code is faster than the Substring code only becuase it is a situation where n = SomeString.Length. Common use would be to use Left to return n characters of a string that is n= characters long. IMO the article gives impractical advice.

I tested the code as I found it in the article, through 10 million loops and Left way out performed Substring. After John Spano at VBCity checked the code behind the Left syntax he found the same thing you report. I set s2 to 'abcdefg' and ran the test again. Substring beat the heck out of Left.

I hope not to many people have used the advice about Left in a performance critical scenario in a VB.NET program.

Bill:>Yet all along you knew the name of the member, and hence probably knew a lot about the type you were calling, that your code fails to describe. So why is it we find ourselves needing this form of late binding?

I got engaged and married to Intellisense from day one so I always avoid late-binding. However, in the past where I needed the form of late binding you ask about above, it was to compensate for VB6's lack of user defined variants (like unions on C/C++).

Because of VB6's lack of "true" inheritance, the combo-box and text-box controls for instance, both had a Text property, but had no common parent defining this property. This meant that to write a routine that could work on any control with a Text property, one has to do something like:

Public Sub Foo(Ctrl As Object)
Dim txt As String
Dim ErrorOccured As Boolean

On Error Resume Next
txt = Ctrl.Text
ErrorOccured = Err.Number <> 0
On Error Goto 0

If Not ErrorOccured Then
'use the txt variable
End If
End Sub

Late-binding (and the ability to ignore errors) makes the above routine very easy to code as it saves us having to use the TypeOf operator to check the type before accessing the property.

If VB had user-defined variants, one could define a variant to restrict the range of objects to only those with a text property and therefore eliminate the need for using On Error.

This is a very interesting question.

I like to use 'my' prefix for the purely private fields and 'the' prefix for the fields that have corresponding properties. Also, I use 'our' prefix for shared private fields.

But it is only part of the solution.
It would be extremely nice to have some additional guideines. That would specify the distinct prefixes for the following types of fields:

+ Private fields (internal)
+ Private fields (used to keep public property values)
+ Private fields (friend property values)
+ Private fields (protected property values)
+ Shared Private fields (internal)
+ Shared Private fields (public property values)
... etc

Public Sub OpenActiveDocumentFolder()
If Not DTE.ActiveDocument Is Nothing Then
If System.IO.Directory.Exists(DTE.ActiveDocument.Path) Then
System.Diagnostics.Process.Start("explorer.exe", DTE.ActiveDocument.Path)
End If
End If
End Sub

May the source be with you...

May the source be with you...

Thanks Bill for pointing out that Visual Studio 'covers up' underscores, with its horizontal-rules.

I've been meaning to blog about that exact point for a while now.

One angle: it might be fixed by using other 'developer-focused' fonts, such as Pro-Font. (recommended by Mike Gunderloy in "Coder to Developer", chapter 6)

cheers
lb

interesting stuff Bill -- i'm an Iprimus customer too, but haven't had any of these problems yet. Will be better equpped for them thanks to your 'rant'.

cheers
lb

Bill,

There is actually very good reason for our montly security patch release schedule: our customers asked for it. They asked for longer cycles between releases and asked for more predictability so that they can plan for large roll outs.

We never said we would not release a patch out side of this schedule either. Quite the contrary actually. In fact, we did an out of band release back in February. We will do this any time we a) see that our customers are at risk from an exploit and b) have a tested patch ready for release.

You said: "Meanwhile, we see more and more "day-zero" exploits." Really? How many exactly? The reality is that there has not been that many. Most security researches practice responsible disclosure which means they wait for the vendor to release a patch before they make their exploit code public (if they ever do at all). Obviously this is not always the case and as stated above, we will act out of band if we can.

We DO have security products and they work quite well for what they are designed for. Take ISA Server 2004 for example. It has the best application level filtering of any firewall product out there and works extremely well for publishing/exposing Exchange and IIS servers to the net.

To summarize, our monthly patch release cycle has nothing to do with our needing more time to develope patches and has everything to do with what our customers have asked us for. We WILL release patches outside of this schedule if we can and we actively engage with security researchers to promote responsible disclosure.

Jerry

Jerry,

When you say “our customers asked for it”, I think that is in reality a gross over statement. What you meant was that *some* corporate customers asked for security rollups. That is, they wanted to make it easier to keep track of rolling out updates inside a corporate network. I bet you not one of them said “hold off on patches even though the vulnerability is known and reported in the wild”.

Further more, I bet “customers” does not refer to home users. Screwing the home user for the sake of the corporate client is bad. There would not be a home user out there that would say hold off on updates, instead make them bigger monthly rollups. What they might say is “don’t make me have to reboot”, but they would not say “leave my system vulnerable to known exploits for a month so as your corporate customers fell happier”.

Microsoft, if it wants to be honest about this, can put this to the test, and allow people to subscribe to patches as soon as they are available or wait till next month and get them in a rollup. The only problem with that approach is the level of disclosure MS gives would be minimal until the rollup is released. But that’s far more feasible than your concept of trying to silence the internet till MS is ready to hear the truth. (aka: “responsible disclosure”)

As to ISA server, great Jerry, how does that protect anyone from this exploit? In what *meaningful* way is it even applicable to the home user? It simply isn’t. I ask for a bullet proof vest, and you say we have an armored car. Like to see that running on a pocket PC <g>.

Finally, as to your “has not been that many” statement, well it has not been many months since MS started this “lunacy”. This month we have the exploit that allows code to run in the local zone, that impacts on home users. Last month we had the chm store exploit that basically did the same. Once again that one was documented on the internet for probably a least a month before MS patched it. I know I removed the relevant registry keys while waiting for MS to release a patch. But instead of releasing it immediately, they held off, and included it as part of last month’s rollups. As to this latest one, well the clock is ticking.

To put it simply Jerry, it only takes one bullet. Microsoft knows of this vulnerability, just like they did on the chm store vulnerability last month. But instead of “scaring” the public, Microsoft decides to leave them at un-due risk, and wait till next month just so as their corporate customers can have easier patch management. Like Caeser throwing the home user users to the lions for the pleasure of his corporate buddies. Sick, and totally irresponsible.

Andres,

Thanks, that's a cool example. Shows the power of the VSIP :-)
I think the "Close All After This" option though would require the tabs to expose an index property or similar, which I have not come across yet.

Bill

Simon,

It's easier than that. you jsut go to tool's menu and add an external tool, "explorer,exe" and in Arguements put
/e, $(ItemDir)

Bill

Hi Leon,

Iprimus has a good netwrok, IMO. The customer service thign thoguh is their real let down, just like Dell's customer service is See Alex Campbell's rant at http://weblogs.asp.net/ACampbell/archive/2004/06/06/149359.aspx

So much for a "service" based economy, hey ;-)

Andrey,

The "the" prefix is unique. I really can't say I have seen that anywhwere before :-)

Bill

Okay Leon, stop the tease. <g> If you know of *the* font to use, at least provide a link

Thanks,

Bill

Thanks Paul !

hopefully once people start palyign with the code, the focus might move on to the next step.. "what to do with it" :-)

But... we still can't upload images or files :(

Anyway. YES. must thanks Susan :)

Bernard,

I don't think .Text has any support for uploading files yet. The galleries feature though does let you upload images. All the pictures in my blog are now from pictures I uploaded to a gallery I created. Try it again. They work for me :-)

Bill, with all due respect, you seemed to overlook this:

We never said we would not release a patch out side of this (monthly) schedule either. Quite the contrary actually. In fact, we did an out of band release back in February. We will do this any time we a) see that our customers are at risk from an exploit and b) have a tested patch ready for release.

As far as my mention of ISA Server, that was in response to your statement that we don't have security products. I was not implying that it was a product applicable to home users.

I personally talk to lots of end (home) users who like the monthly release schedule and prefer it to releasing patches whenever they might be available or even the weekly schedule we did previously. As long as we can and will release a patch out of band, how is the monthly schedule bad?

Bill they have released an "out of band patch" and they say they might do this ALL THE TIME. I'm probably the only person I know who didn't mind the weekly schedule because I have a Patching tool both at the office and at home...but even then ... I had to make a decision ...is it okay to do it now.... should I see what my fellow SBSers are experiencing with it? Now.. way way easier to better track "issues" because we typically tend to patch around the same schedule.

IE is one of the NASTIEST ones to patch. They can't just roll out a English patch but have to patch ALL localized versions. It's like 400 "flavors" of IE that they have to "roll a patch for" and test.

Jeff Middleton did a white paper about 2 years ago saying that we couldn't handle the once a week patch schedule... sorry but I so disagree with you... I LIKE the once a month, occasional "out of band" patch schedule. As a SBSer who has applied practically all of Microsoft's patches I don't WANT to go back to once a week.

Bill... they have to test... they can't just throw out a crappy patch and then go "gee, I'm sorry". All it takes is one crappy patching experience and people remember that forever.

You know what I'm doing right now... which excuse me... we should be doing anyway.... running with IE in high security and then adjusting "trusted zones" to run in Medium and adding line of business web sites where needed. Man do some of these web sites use crappy coding practices. geeze.... it's unbelieveable out here what bad practices we put up with.

You have to have patches go through a certain test pattern, that's just downright common sense to ensure that the patch will do it's "thing"

Other than the POC links and security exploit emails.. I honestly have not seen these types of web sites. Hey we're surfing in the hood these days.. keep your doors locked and don't talk to strangers... you know?

http://radio.weblogs.com/0001011/2004/01/14.html#a6183
"Now, about the darn security fixes. These are tough. Tougher than it might seem on the outside. Why? Because Internet Explorer's engine is used in several different OS's. Dozens of different languages. Thousands of different applications. Changing one line of code in the inards of Windows means potentially breaking a large number of applications. That's unacceptable to the team. So, when they change things, they need to do it in a way that doesn't break things for customers."

XP sp2 "is" going to break line of business web sites. RC2 is [per Neowin] out shortly. I hope you are downloading and messin' with it.

I have to say a HUGE thank you for cornering those domains and forwarding them to the main site.. thank YOU for that!

I used to be an "Option Strict" kind of guy back in the good old days of C++. I had an innnate belief in my compiler's ability to protect me from bad code. I worshipped at the altar of Bjarne's decision to favor compile time errors over runtime errors.

However, I have recently come out of the closet to reveal myself as an "Option Strict Off" kind of guy. There are lots of folks who write large systems using dynamically typed languages, and Option Strict Off is the closest that I can get to the semantics of those languages in the CLR world.

The catch, of course, is that you must write tests that verify the semantics of your code, instead of relying on the compiler to catch (arguably) syntactical problems (which IMHO static compile time type analysis really is).

Just my own personal story about how I've come to love VB (from a reformed C++ dev).

aren't the leading underscores bad per your recent post ;-)

Hey Bill...thanks for readin' my blog ;)

Check out my comment here...sorry I didn't explain it very well...

http://weblogs.asp.net/eporter/archive/2004/06/16/157241.aspx#157275

Hey Erik.. Thanks for reading mine ;)

Okay, so you want a counter in both directions, then why not just initiate j outside of the loop and iether increment it or decrement it on each loop.

Now that VB.NET has the continue statement, you might find that a better over-all strategy (just be careful of code placement), as it means you can have one counter running behind the other such as when you are iterating a list and skipping items.

So code such as :
j = -1
For i As Integer = 4 To 0 Step -1
j += 1
Next

or vice versa:

j = 5
For i As Integer = 0 To 4
j -= 1
Next

Hey Susan,

Having patches made available at the earliest possible time does not preclude Microsoft doing monthly roll-ups. Personally I think monthly rollups are great, and they should really think about extending that and making it easier to bring new systems up to date as well. Once upon a time ago TechNet seemed to help a lot there, but it really became overly complex and also terrible out of date by the time you got the CD’s. Rollups help address those issues. I actually would like to see MS have a business update subscription, where you can pay an annual fee and they express ship to you CD’s or DVD’s (your choice) with the latest patch rollups and administration tools to help you roll them out.

Anyway, the thing is *timely* updates are not counter to rollups. Timely updates make more systems secure earlier which is good for all of us. But most importantly it gives the *customer* the choice as whether to patch now, or wait till the end of the month. That is the customer gets to choose, not MS holding the patch back for some artificial monthly schedule.

As to IE and using the secure zone, yeh that might work although that might actually be more dangerous ;) But I seem to have this faint memory of you not using IE, instead it was mozilla, Thunderbird not Firebird, no ??? ;)

Good point!

It might be interesting to weigh code readability vs. performance, see if either way of doing it would outweigh the other in those two areas.

btw, yah, Continue rocks...I'm so excited for it!

This is why I love blogging I get to share and learn! :)

Hi John,

I think non strict code has its place, especially when it is dynamically generated code on the fly. And VB.NET does do that very well.
I still believe though, that you should not rely on implicit code if you are actually writing that code. Sure, use it Option Strict Off where you absolutely have to, or in cases where you might be retrieving member names from a database etc. But if you actually write the member name, then it means you knew at compile time exactly what you were calling but didn’t have it clearly defined anywhere. It’s at that point you should consider using interfaces and/or generated assemblies/code to do that layer of marshalling for you, as you then remove a wide range of possible *human* errors.
Most folk who know me well, know I am adamant about string literals in code being dangerous//evil. I have seen them be the cause of hard to locate errors time and time again. And I have seen that and experienced that when working with some of the best developers I know. A simple typo can end up taking hours to track down. And just as this is bad with string literals, when you turn Option Strict Off, you realistically subject all your code to those same flaws string literals have.

Getting back to the For Each issue however, if you want to use Option Strict Off, that’s fine, it probably won’t make any difference for you. But for people who do want to use Option Strict On, the current implementation breaks that. That is, at present we don’t have the *Option* of making that code strict.

Options are good :)

LOL ! Yes, declaring field names starting with _ is bad, but with COM interop and all those leading _'s you aren't actually using those as field names, instead it would be field types, and as such you can qualify the name if needed ;)

From some aspect, try..catch..finally was invent in the Java language. In language like C, C++, Java, scope is where a variable defined and lived. Thus the constract in the scope is that all variables within the scope will be destroyed when it go "out of the scope". Scope in those language is define as {}. Scope variables have a *fix* rule on how it is looked up. Say, if you use a variable X which is not defined in this scope, it will look up through scope Tree by reverse traveling. If it hit the root Tree scope and still can't find the variable, a compiler error will show as X is not defined.

The problem in your argument is that as VB scopeing Languag can't prevent user from doing the following:

Dim F As File = new File("log.txt")
Try
Dim F As File = New File("foo.txt")
F.Read(...)
Catch ex Exception
Dim F As File = New File("err.txt)
F.Write(...)
Finally
F.Close() 'which F are you talking about
End Try

Now the question.
1. Is the above legal in VB? I believe it is. (Yes, I know it is bad code. But the language doesn't prevent bad coding.)
2. How do you determind the scope depth and, when a variable F1, F2, F3's memory need to be free (by defination, it should be freed when it "out of the scope") -- are you suggesting that Catch should be the parent scope of Finally, and Try should be the parent scope of catch.

if follow your suggestion, When is the catch block F variable memory should be reclaim by the system? Should this variable destroyed after all the variable in the Finally block is destroyed (by defination that the child scope variables should be destroyed before the parent scope variables destruction.)

In other word, your logic make the language more like
Try
Catch
Finally
End Finally
End Catch
End Try

Which doesn't visually/sematically express what will happen here, right?

If you enjoy scope variable -- (Say, allow you to create the same variable within a IF block when outside variable.) You need to have a set of *fix* rule how a variable can be looked up. Which need to be a consistent way. I just don't see user will like the idea that when you are in IF block, you have a set of Scope variable look up rule. Suddenly it change when user is using Try-Catch-Finally block, the scope variable look up rule just change on them.

On the compiler implemetation side, this proposed inconsistency scope look up rule creae even more problem, where do you keep those "variables" in the catch block that can be share only with Finally but not visible in Try block?

-Ming

v1.x of the C# compiler adds DebuggableAttribute(false, true) even for non-debug builds, unless you compile with /optimize. So just checking if DebuggableAttribute is present might not give you the expected result.

The arguments seem a bit silly to me. I could make equally trivial comments supporting _ over my as a prefix: 1) You can turn off the seperators in visual studio. 2) If you change your naming conventions every time MS comes out with a new feature, you'll have some incredibly confusing code. 3) "My" does not internationalize well. "Min" "Mio" "Mi"? I guese m_ covers most european languages. 4) I like the underscore because it stands out well using intelliscence when I'm cleaning up stuff in the class destructor.

At any rate, I think that only one rule applies to the use of _ or m_ or my:
Be consistent. That is use one or the other.

Thanks Mattias !

Looks to me like a bug in the C# compiler ;)

Anyway, I modified the code so as now it returns the IsJITTrackingEnabled value. hopefully that covers all C# quirky builds

Hi Cliff,

Looks like you are a die hard _ fan <g> I want to address some of those points you raise, but first I want to make it really really clear you should NOT use my as a prefix for fields. My is a namespace in Whidbey, and you should always avoid using prefixes that class with namespaces.

I do agree with you about the clarity _ brings with it, but I think that is even more the case with m_, and you don't have the problems that _ causes. Anyway, onto the issues you raise…

(1) Yes you can turn off separators and you can also turn them on. The point being that if someone likes to use separators, then when they go to read your code they should not have to change that. SO just because you can turn them off, doesn’t mean you have legible code for people who have them turned on.
(2) I 100% agree with you, you should not change your coding convention unless there is good reason to. For anyone familiar with VB6, this was also a known issue there, that’s one of the reasons why people don’t use _ as a prefix in VB6. So this is not a new thing at all. In fact, it’s the _ prefixing thing that seems to have become a fad from “new” languages. (read: fashion victims <g>)
(3) My not internationalizing well… hmmm, I don’t think anyone was suggesting using My as a field prefix. That would be a very bad coding standard. IF you are referring to the My Namespace, yes that is English based as are all the framework classes and namespaces, as is VB itself.
(4) Exactly the same thing can be said for m_ . Personally I hope they make intellisense a lot smarter as well, and that they have a filter for the current class code. That is, I find the issue of intellisense and what’s in the current code file (not the classes base classes), is a bigger problem when it comes to methods. The difference between _ and m_ there is insignificant. One might argue it’s easier to type m than _

Hope that gives you some more food for thought. _ is a relatively new code practice in VB, and it really does have some real problems associated with its usage. Tried and true naming methods make your code readable for other developers, and that’s what we really should aim for.

Bah! Who needs Continue when you have GoTo? ;-)

With respect to different modifiers on fields, I use:

m_ (non-public, instance field)
c_ (non-public, constant or "static readonly" field)
s_ (non-public, static but mutable field)

Although for constants, I am thinking about going back to the ALL_CAPS style for constants. There's something nice about constants standing out in the code a bit more.

I should have said ALL_CAPS style for *non-public* constants.

I understand what you're saying here, but your statement about C# is wrong: VB and C# have the exact same semantics in regards to requiring casts in for each statements. The problem is that you picked a bad example: while VB has a conversion from String to Integer, C# has no conversion from String to int. So C# gives you an error because no conversion exists, not because you forgot to explicitly specify the cast. Change "List(Of String)" to "List(Of Double)", and you'll see that C# and VB have the exact same behavior.

well said Bill!

Good catch. The issue still remains that VB, unlike c#, does conversions to string and from string for numerics, dates etc. This is, in the for each, VB.NET uses Option Strict Off rules and semantics, regardless of whether option strict is on or not. This is bad. It means that errors in code that could be caught at compile time become difficult to test runtime errors.

And given the ability to strongly type with arrays and generics, there is no need for that injection of that Option Strict Off code.

Hello Bill

Im glad I have found your blog!

you are no part of the Aussie .NET bloggers list

http://blogs.msdn.com/frankarr/archive/2004/02/05/67737.aspx

cheers

Hello Bill

Im glad I have found your blog!

you are now part of the Aussie .NET bloggers list

http://blogs.msdn.com/frankarr/archive/2004/02/05/67737.aspx

cheers

They'd have to be really careful to implement a plan like yours. It is my understanding that most consoles are sold for less than their manufacturing cost. They do that to get you to buy one then they make their money on the game licenses. In your plan you might have people buying an Xbox and never buying a game so MS would lose money on thay buyer.

That's a lot of the reason MS doesn't put much emphasis on the DVD playback for Xbox. First of all it stinks - I have a bunch of discs that will only play if you do things a specific way, others don't work at all. If Xbox was a great DVD player people might buy it just for that feature and never buy any games (or at least not enough games for MS to make back the money they lost on the hardware).

When will MS patch the known exploits ??

Yes, well said Bill.

When will MS patch the known exploits ??

XP sp2 will have the fixes, in the meantime.......

And pity those who trusted MS and bought windows ME only a couple of years ago :(

Ahem: http://www.philweber.com ;-)

Hey Phil,

Good to see ya back blogging !!!

Download the opml again :)

:The number one question is of course, why does C# require the break
:statement in a switch block? Is that some kind of antediluvian tar pit
:construct ?

Is this a serious question are or you poking fun? I can answer it if you like :)

"So perhaps they should be asking why is it that fortune 500 companies choose VB over C style languages, that VB is so strong yet is not part of the Computer Science curriculum."

A CS curriculum should have abolutely nothing to do with specific langauges like VB or C except to use as examples.

A CS curriculum does not exist to produce programmers (for whom a langauge is just a tool to allow them to effectively do their job). It exists to produce computer scientists.

"Evolution in terms of computers and computer languages is about bringing computers closer to human language and human needs and uses, not some re-hash1 of early grunts."

It most certainly is not.

"The number one question is of course, why does C# require the break statement in a switch block? Is that some kind of antediluvian tar pit construct ?"

It requires it because it is commonly viewed that switch's can be a source of bugs due to programmers forgetting a break statement. Because one of the tenets of a managed language is to go for the safe route first, it was decided that programmer should have to be explicit with switch statements. If they want to fall through, they can do so, but now they must use code (as opposed to a comment, or just forgetting altogether) to state that that was their intent.

The one thing I find very annoying with VB.NET is the extreme verbosity compared to C#.

Admittedly, the VB IDE appears to be better than the C# IDE in VS.NET but I must argue that if one bases one's choice of language on the IDE alone, it is a biased choice.

I for one prefer C# because of its simplicity, clarity, and lack of verbosity as opposed to VB.NET. However, organisations which choose VB.NET IMHO do so because of one overriding requirement: -

1. The need for developers with suitable skillsets. C# is good for those with C, C++ and/or Java background. This being so because of the need for maintanence and extending the code over time.

That is the case in my organisation as there is a dearth of C# programmers. That is not an indictment against C# per se. I have been coding with C# since beta 2 and now I am coding in VB.NET. The verbosity is mind-numbing in VB.NET

Thanks for stickin' me on the list :)

Isn't that the point? The more verbose it is, the easier it is to understand code and maintain it...

And about Delphi?

Delphi is a good choice. Borland is always focused on developer's needs and on evolution. VB.Net wasn't an evolution, it changed everything.

Delphi is a continuous evolving language, with object orientation suport and strong types much before VB, and it's also easy to understand.

VB.Net 2005 makes use of { }

What's more annoying than the break in C#, is how you can't fall through in VB.

Ever seen an "obfuscated VB" contest? No, only C based languages.

Does any vendor of VB debugging tools run an series of ads, well into the thousands of them, all with different hard to spot bugs (no only c based languages? Besides, what VB debugging tools?

Did Andrew Koenig write "Traps and pitfalls of VB?" No, he only wrote it for C languages.

Basically, smart people prefer VB. Dummies like saving keystrokes (what they really like is being cryptic, we know). Or as Anders said, "lifestylers".

blanket statements are the sucks.

True, blanket statements are always wrong.

But in this case, we have a blanket exemption to your blanket statement.

In my opinion, there are two factors that may influence language choice. First is personal preference. Second is the first language learnt by the programmer.

You can draw parallelism between programming language and natural language. If you're speaking one of European languages, you won't find difficulty to speak other European languages, since nearly all of them were derived from Latin. But, try to learn one of East Asian languages, such as Japanese or Chinese. That's a different ball game.

So, I guess Bill's argument that students who learnt C-style language is unable to evolve, is too superficial.
To me, VB is atrocious, because my first language was Pascal and it's kind of irritating to me to use a language that doesn't use semicolon to terminate a statement.

Commenting Anand's statement saying that "the more verbose it is, the easier it is to understand code and maintain it..."; I shall apologize to say VB is too descriptive that sometimes it is even hard to fathom why I have IsNull & IsNothing at the same time (VB 6).

Anyway, this is just my biased opinion because I don't speak VB natively. But every now and then, I found myself more productive, less error-prone, and more capable of maintaing codes written in C-style languages; including C, C++, Java, and C#.

Maybe if there is an OS written in VB in the future, I will try hard to get my head on VB. But before then, long live C#. ;)

A Gunawan,

<quote>
I shall apologize to say VB is too descriptive that sometimes it is even hard to fathom why I have IsNull & IsNothing at the same time (VB 6).
</quote>

By IsNothing, I assume you mean Is Nothing...

How is that hard to fathom? VB 6 distinguishes between (DB) Null and 'no object assigned'. Its hardly rocket science to understand the distinction.

Because I came from a language that only distinguishes null and NOT null. So, I can never understand the reason why we need to distinguish Nothing, Null, and something. I can't see the difference between 'No object assigned' and 'Null object assigned'; unless of course, you can enlighten me with a clever reasoning to why this VB system is better than "null" and "not null" only system. ;)

Gunawan,

The difference between Null and Nothing in Vb6 is equivalent to distinguishing between a variable that has never been assigned versus a variable that was assigned the value of null as returned from a database column.

How else would the 3 possible states - not assigned, assigned a dbnull value read from database and assigned a valid value (from DB or otherwise) be distinguished?

BTW, even variables in C# seem to need this feature as also the CLR which is why a new type "DBNull" has been introduced to distinguish between the 3 states.

Vb.Net has renamed isNull to isDBNull to clearly indicate what the function does.

A Gunawan,

<quote>
I can't see the difference between 'No object assigned' and 'Null object assigned'
</quote>

There is no such concept as 'Null object assigned' in VB 6 (or VB.NET).

As I said Null in VB 6 is based on DB Null. If you have a smallint column in SQL Server, and its value in one row is Null, then VB 6 (via a DB access tech like ADO or DAO) will say the value of the Field is Null. The Field is not Nothing (I mean, there is a Field object there), but it has a VALUE of Null.

In other words, in VB 6, an Object / Variant variable can have no object assigned to it - which is Nothing. Or a Variant variable can have the value Null - which (almost always) represents 'no value in the DB.'

Of course, the TERMINOLOGY may be confusing if you are used to a language which uses NULL the way VB uses Nothing. But the CONCEPT of Null vs Nothing in VB 6 was quite handy. The usefulness of the concept is illustrated by the existence of Nullable Types ( http://nullabletypes.sourceforge.net/ ) and their introduction into VS 2005.

<quote>
I shall apologize to say VB is too descriptive that sometimes it is even hard to fathom why I have IsNull & IsNothing at the same time (VB 6).
</quote>

I hope I have helped you in your quest to understand the distinction between the two. Despite the way other languages use the term, IsNull and Is Nothing are completely unrelated in VB 6, and are both very useful.

That's great, Bill! Congratulations!

Sql Lite marketing name would sound like Oracle Lite.

if they did not want to go along with the name MSDE, they would name it
Microsoft SQL Server Portable Edition.

I would name it MSDE 2005 (CodeName WhetStone).

Portable edition ? I think folks would think that one is for Pocket PC, aka Windows Mobile.

MSDE is okay, but it doesn't really indicate that it is a cut down version of SQL. The ability to scale from one to the other is a plus which the name should imply.

Je ne parle pas Francais.

Hi Bill & others,

Yep, they wanted to lose the MSDE moniker because the name itself introduced too much confusion ie: oh is it really sql server?

Maybe something like SQL Server For Small Workgroups or something? (note to self: stay out of marketing)

Hi Bill,

<resisting urge to make big date processing whinge>

While they're at it, they need to take a long hard look at functions like IsDate(). Either 27/12/04 is a date or 12/27/04 is a date. They're not both dates. I came across someone the other day who'd loaded 60 million rows into a database table, thought they were in US format, they were in Oz format. DTS (which uses the VBA functions) just loaded the lot without a whinge. Bit of a pity that 2/3 of them had the month and day reversed though. Bigger pity that it was only noticed 3 days into production when people started saying "that's not when that happened". Try to fix it then after days of real production...

Compare that to an error at row 3 of the load. I'll take the latter every time.

</resisting urge to make big date processing whinge>

Regards,

Greg

Hey Greg,

Yeh, IsDate does have some wierd behaviour. It is localized, but it also assumes that if a date has the form of x/y/z then if:
(x > 12 AndAlso y <= 12) OrElse (y > 12 AndAlso x <=12)
then it's potentially a date.
That is, if you enter in 12/30/2004 it will be interpreted as 30 Dec, 2004 where ever you are. CDate does the same.

The good news is in Whidbey, the DateTime Structure has a TryParse method, so I would recommend using that ;) Tat will also let you control which culture is used.

Hey Greg,

Yeh, stay out of marketting <g> The problem is that will become SSSW, just like how MSDE was the short form of Microsoft SQL Desktop Edition. (or something like that)

So what we need is a short name that keeps the "SQL" and does not encourage acronym building. Maybe we could give it the VB touch, that's be My.SQL right ? ;)

Hrmm... My.SQL? Sounds too much like a particular SQL product called MySql...

Maybe something like VFP has: {^yyyymmdd} translates to the currently specified date format in the application.

waht about : "Microsoft SQL Client 2005" ? since it's not running on a dedicated server.

How about "SQL Desktop Edition 2005"? :)

<grin>

>> To me, VB is atrocious, because my first language was Pascal and it's kind of irritating to me to use a language that doesn't use semicolon to terminate a statement.

Funny, the first language I learned was Pascal (Turbo), and I *can't stand* to use semi-colons on the end of a line! To me, they are always getting in the way. I ask myself; why do I always have to put a semi-colon at the end of the line and then not use one in the relatively rare cases where I am continuing a line? Why not the other way around? (like in VB...?)

Actually, VB.NET has a lot of things that drive me mad too (like parens for array subscripts and lots of other nigglets.) Ideally I'd love to design my *own* language syntax and do it exactly the way *I* want it to be, but that of course doesn't pay the bills and I doubt anyone else would use my language anyway, so chalk that up to "nice idea that will never happen!" :-)

+1

I think the "VB.NET smart tag error correction thingy ma jig" is where the VB team should focus its efforts in its attempt to bring VB6'ers into the .NET world. I wish they would do so instead of essentially breaking the language in the name of backwards compatability.

Take for exaple the "default form variable instance" "feature" in VB 2005. Wouldn't it be *waaaaay* better to utilize the VB STECTMJ rather than allow the following?

Form1.Show()

Lots of developers are really balking at the default form instance stuff just on principal [1]. It's obviously sending a very bad message to developers who want their language to do things correctly.

[1] http://discuss.develop.com/archives/wa.exe?A2=ind0407c&L=vbdotnet&D=0&T=0&P=8469

I'm planning to talk about the whole default instance thing, but to get back to the original subject -- this is something that we wanted to do something about but didn't have time this time around. We've got to leave something to do next time... :-)

Hey Paul,

Uhm, like you do realize that by the time the next version after Whidbey comes out, we are probably looking at 5 or more years since the first release of VB.NET. So if we are talking about migration facilities, that sure is putting them off, hence impacting on more customers in the meanwhile. Seriously, by then, you have to ask what's the point ;)

Realistically just how hard can it be to hook into the memeber not found, check the type, and then see if it was Label.Caption, or Form.Caption, or Debug.Print

It's not like there are thousand or even hundred of them,. geez, just add the top ten. Anything would be better than the do nothing till next time 'tude.

Hey Stuart,

Yep ! STECTMJ should be part of an integrated approach.

And yes, Form1.Show is evil ! But that does not mean they have to remove it, just tame it. Keep it in the dungeon with all the other "un dead" creatures. Actually this is worth a blog entry of it's own :)

Links broken this morning

The VS.Net IDE will produce a warning if a developer writes a shadowed method without using the Shadows keyword. I believe that Robert Green and his team have done a good job with this but I do agree with you about the new keyword. I believe that we should avoid shadow methods and stick with overriding the methods when possible.

You raise a good point here Bill! <g>

Overloads is not required when used in the same module, I don't normally add it in. I can easily see there are more than one method available when the tips show 1 of 3 or whatever, (where it is being called). So, its one of those, out of sight, out of mind things, if its not there, no one worries about it!

Also, isn't the role of hide-by-signature supposed to be covered by Overrides, and not Overloads? The way I see it, Overloads pertains to the current module, and Overrides pertains to method in the base of a derived class.

If you are using Overloads to perform the Overrides function, maybe the compiler should throw a warning?

Hi Larry,

Overloads is needed when adding a method of the same name but a different signature. You can omit it if they are in the same class, but cannot omit it if they are in a derived class. e.g.

Class foo
Sub test()
'...
End Sub
End Class

Class bar
Inherits foo

Overloads Sub test(ByVal name As String)
'...
End Sub
End Class

As for Overrides, that is a completely different thing, and you should NOT confuse overrides with Overloads. Overrides is the "same" signature, implemented in a different place. Overloads creates a "new" signature. When Overloads hides a base member by signature, the method is still a new method, but matches the base method by name, call type, parameters and return type. It is still a new method, even though to us it looks the same ;)

This is the reason they chose Overloads to do both adding new methods and hide by signature, as in both cases they append "new" to the emitted method. However, this does little to make the situation less ambiguous for developers. And most likely, this overloading of overloads is probably partly to blame for the confusion it causes you and many developers learning VB.

I was thinking back to when I first encountered Overloads and was digging into it's intricacies. I remember I didn't like it then, and still don't. I still have vivid memories of another VB MVP using most un-lady like language in regards to it when she discovered it's nuances back then too ;)

The simplest thing to do is to extend the language to allow deprecation of the shadowy part of Overloads, phase it in over time, integrate it with compiler warnings and smart tag helpers to correct code. Leaving it as is, just makes the language un-necessarily ambiguous, and hence harder to learn, IMO.

Thanks Isaiah.

Nevermind! After a little more investigation, I found this in the docs:

"Derived classes can overload inherited members with members that have identical
parameters and parameter types, a process known as shadowing by name and signature.
If the Overloads keyword is used when shadowing by name and signature, the derived
classes implementation of the member will be used instead of the implementation
in the base class, and all other overloads for that member will be available to
instances of the derived class."

So again, you were right, Overloads, is overloaded!

(Now how do I cancel my earlier submission? ;-)

LFS

OK, but as defined, the Bar class has a member called Test(), because it is inherited from the Foo class. Now, like any other time you want methods of the same name, in the same module, you will be overloading that method name. So it would appear, that Overloads is the right choice, but then there is this in the Docs:

"The Overloads keyword is optional when overloading, but if any overloaded member
uses the Overloads keyword, then all other overloaded members with the same name
must also specify this keyword."

That's why I can overload without using the keyword, but your situation breaks that rule!
One version uses overloads, while the other does not....

What if they just made it optional, so that you would not need the Overloads keyword in your situation. It is after all a new method is it not?

Hey Larry,

You can't. I could, but I think leaving it there highlights part of the issue. Overloads is overly complex. It shouldn't be. There should be no confussion ;)

They could make Overloads optional everywhere, but then you loose the explicit nature of the language, and once again are reliant on object browser and class view to indicate if the method is an overload.
So I think removing it, or making it optional would actually be a loss in explicit readability

Thanks Kathleen,

Looks like MS has pulled it from their downloads already :( Msut have been popular <g>

You can still download it from http://www.lookoutsoft.com/Lookout/download.html

C# ... has some pre Neanderthal form of language...

Wow another C# bashing..... Anyway ... So Neanderthal languages only qualifies for Standards :P

Dum dum....

Oh wait ... Do I hear alot of utilities converting from VB.NET to C# ......

I add myself to your requests...

Corrado

I agree. When VB.Net first came out, it wasn't a big deal. But now that I've got to look at 2-year-old code, it is quite annoying.

We're not alone...

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=65ff7de1-5075-46f5-89e4-2a11dac20db2

Hey Bill! Thanks for posting this. It's still not a mere mortal kind of thing, but it's definitely a step in the right direction.

Installing VB6 without Java

Other that the default prefix, that's definitely something I would use.

(The prefix dosen't matter to me because iot would take longer to select all the text expect the prefix than it would to type the extra three characters.)

Do you see an unwire method being generated for all classes that have WithEvents fields? Or just forms?

Amen, Bill! We're in the Middle Ages of Least Privilege, and running as Admin for installations is the only way to confidently go. But if you do that, be sure to take the option to install for use by all users. Otherwise only the Administrator will be able to run the new software. Sigh.

I have used runas (mostly via Shift-Right Click) to install most software in the last year or three (even Windows Update works!) and it seems to be only setup programs that wrap *.msi installations that cause the MSI install to run as the interactive user, not the one I started the exe as. This is often fixed by just extracting the .msi file (or just copying it before dismissing the error message) and then draging the file to the Administrator Command Prompt window I have minimimised most of the time.

actually, Nick's comment (that I quoted) was about shareware, he then went on to comment on commercial software...

Just to be clear :)

Hey Duncan,

Right, Nick’s first paragraph was about shareware, and his second about NON shareware. In the first paragraph he did not touch on the framework distribution issues. The second, talking about admin installation is really a red herring in what is an important issue.

For example, look at XP SP2. Yes it does help to distribute the framework, but not 1.1 SP1. So the complexities of (a) how to determine what framework and service pack as user has still exists, and added to that the complexities in knowing which install they need to use. For shareware authors, this still equates to probably two hours download for a potential customer, *just for the framework*.

I am not disputing the facts Nick alluded to, that is, there are other important factors as to whether your shareware is a success or not, and that for corporate intranet, neither shareware or the framework distribution is really relevant ;) But for all other things being equal, if you had a non managed application versus a managed application, the framework detection and distribution is a major hurdle for the managed app.

The only real benefit t the potential customer is the sand boxing the managed app can provide, but once again, that is neither obvious to most consumers and is overly complex for any substantial app.

So the point in this, is that we need to stay focused on the real issues, not get side tracked by other scenarios.

Where can I find the generic BindingList?

System.ComponentModel.Collections.Generic

Nice.

Installing Visual Studio 6.0 without the MS JVM

Um, why is Ti Yukon?

Of course, my info was aimed at people without VS.NET, because if they have VS.NET, they don't need to automate builds from the command line for a small project like the one described, but you bring up an interesting point about the future...

"Hopefully one day in the not too distant future they will release a vbproj pre-processor that passes the info off to vbc.exe, hence allowing simple command line compiling without the need for VS.NET on the machine"

MSBuild provides exactly that... for VB 2005 of course, but at least we know it is coming, and it is part of the Framework SDK... no VS.NET required.

I come from a background in vb programming and i find VB.NET simply annoying. It contains too many vb functions that at times do not function exactly as they did.

Instead of creating VB 7. Microsoft decided to create VB.NET. But instead of making it pure OO like C# they decided to retain many old VB functions. This only served to confuse the developer further.

But one thing make me like VB.NET as opposed to C#: it is more readable.

I like the descriptive nature of VB and i hate those curly brackets even though the first language i ever learned was pascal.

Then there are the C style for loops.
for(i=0, i<=10, i++).
what is wrong with for i=1 to 10? simple, efficient and readable.

Also C# programmers have a tendency to declare their variables anywhere and i have always found that annoying.

But in the end what will decide the language i use will be the code samples on the internet. Is it easier to find VB code Samples or C# code samples? Right now VB.NET has more code samples. But C# has more components.

+=1
We are not alone but is MSFT listening?

I use .net for "freeware" and have had no problem with acceptance. I get about 100 downloads a day each for my 3D software

http://www.callipygian.com/3D/

and my web-spidering image download software

http://www.callipygian.com/CallipygianGrab/

and have had few complaints. From my "register" log, about 80% of the people who download the software run it!

Bill, please be mindful that everything that is not Win32 API is essentially a wrapper; including .NET CLR (probably until the release of Longhorn). I can't see that much overhead in the interaction between Scripting runtime and COM objects instantiated during the execution of a script.
Besides, do you really need that much efficiency for creating just a shortcut? WSH is widely available on almost all default Windows installation, while .NET is not. So that's definitely a big plus.

Don't you think it's really that efficient to waste hundreds of megs for .NET framework installation, when all you need is just automating the creation of a bloody shorcut? Read Brendon Chase editorial in Builder AU's October 2004 edition, you probably need to renew your state of mind and not get too carried away by only a specific tool just because you think you know it best. ;) Good luck, Bill!

You mean I have to download 22MB of .NET framework just to create a wrapper for a shortcut ? Hmmmmm .. sounds justifying.

.NET is good, but it's not the solution for every problems.

<quote>
So rather than throw an exception if you try to re-show a form, the VB team added code to check if the form had been disposed, since when a Form is closed, it’s Dispose method is called.
</quote>

The docs and experience suggests that closing the Form calls Dispose only if the form was shown modally.

Will's Blog &raquo; Automatic vs Manual Drivers?

Hmmm... Although I love background compilation in VB and this is probably the only feature I'd love C# to get...I must admit I'd never trade my manual transmission...in other words I don't find the analogy works that well. For another analogy of manual/automatic check this post out:
http://www.interact-sw.co.uk/iangblog/2004/09/02/apicomplexity

Hey Daniel,

At first I thought it must be an age thing ;) Over the years I've had many cars, auto and manual, and I can tell you quite seriously that it will be autos for me from now on. :)
The newer automatics are much much better these days. As I pointed out, fuel efficiency is just one example. They can also provide faster and more appropriate/fail safe gear changes than a human can. Such as when corning, if a gear change is needed, the destabilizing effects are much less in an auto. New autos also have grade logic control, overdrive, etc.
In fact, some of the hotest autos now allow semi manual change as well, which is much like having a formula one's automatic clutch.

Having a history with the PTO in my previous history as a CEO, I can assure you that they view the origins of a concept and the actual development of a concept into a tangible property are viewed as completely different items.

If a couple people sit around discussing the next great widget and one goes on years later to make it happen, who does the patent belong to? Both? Why?

Hi Larry,

This isn't just people sitting around discussing a concept. It was clear documented evidence of other people suggesting this be added to the language. Those claiming the patent clearly cannot claim to have invented the idea.

Oh, and to further answer your qusetion (if indirectly), let's consider a person invents something. They think of a great concept. They then discuss this with others. Is it okay for those others to claim that as their own ? If they wait one year, is it then okay to take the inventor's idea and claim it as their own ? Is it simply a question of who can afford to lodge the patent, who can afford the laywers, who can implement the idea first ?

But when changing gear in corner, the destablising effects of an auto changing gear when no sane human being would ever have considered a gear change are the worst of all!

It's true that the new breed of autos that are essentially manual gearboxes with a conventional clutch, but with everything operated automatically under hyrdaulic control, the transmission losses are no worse than with a manual.

Claims that the auto is *more* efficient than the manual are a little suspect. If that is the case, then it's almost certainly simply because the two boxes have different sets of gear ratios - the top gear and final drive ratio have an impact on fuel efficiency, so if you're getting better mileage out of an auto, that's likely to be the reason. (Either that, or you're really bad at selecting the right gear in a manual. ;-) Bear in mind that mileage *does* vary massively according to driving style.)

But to get back to the point, it always amazes me when VB people make this point - I just don't understand it. Do you really think that it's obtrusive? You describe the process as being very cumbersome:

"you have to actually stop to change gears! Stop and save your code. This requirement that you must physically safe files to see changes,"

but that's just because you've chosen a cumbersome way to describe it.

The reality is that I just have to hit Ctrl-Shift-B. I can do that without lifting my hands off the keyboard. It saves all the files for me and compiles them. This is not a slow process. It's not even remotely disruptive.

Why auto when you can manual?

The MSDN content in my eyes is getting to big and heavy. While I want all the content available, I'd also like to be able to see a window sooner when I hit F1.

Having worked on a very large VB.NET application, I can say it's definitely not always a good thing. Even on an extremely beefy workstation, big solutions take FOREVER to open and assemblies with a lot of dependencies are basically un-editable. For small solutions, yeah, it's nice to have.

If C# were to get it, I'd want it to have a more comprehensive set of options for it than VB currently has.

If you covered that somewhere in the car analogy, sorry. You lost me in the middle of that.

I think the biggest problem with the patent system is that they they forgot the obvious clause. This alone should invalidate most of the bogus patents we hear about.

Title 35 Part 2 Chapter 10 Section 103
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains.

You can always split up your huge solution into smaller manageable chunks and make VB work.

The only situation where this essentially doesn't work is visual inheritance in windows forms - and well - even C# sucks there.

Yes, I'm with you on splitting things up. But, we are where we are, unfortunately.

Hi Dan,

In VB.NET 2002, the "transmission" was a very early design, much like the old tri-matics. That is it was terrible in certain conditions, but fine under normal conditions. For example, if you had a huge single file the IDE would grind to a halt; you could literally count seconds between keystrokes ! Not a normal condition, but when you did encounter it, things got very nasty quickly

Then in VB.NET 2003, many of those issues were addressed. A huge single file no longer is such a system draw down. Still there are some issues with multiple project solutions. So the transmission is improved, but it is still not quite there...

Now in VB.NET 2005, the transmission is finely matched to the IDE, and can handle those different driving conditions where it previously wasn't the best. It is now very much like the latest state fo art automatic transmissions.

Hi Ian,

In VS.NET 2005, there's some new highlighting features, where green markers indicate code that has changed since you opened the solution, and yellow indicates code that has changed since the last save. So in C#, to check your code compiles correctly, you have to save the files, hence loose the yellow markings. This makes it impossible to have both compiler checked code and any indication of current changes. So yes, being *forced* to save the files in C# is a big deal


Bill.

Hopefully we'll be going down the road of splitting things up by the time 2005 is out. If for no other reason, I'm sick of VB and I need to be using C# on new stuff for my sanity's sake.

It's good to hear that the issues are being addressed. I actually got curious one day and opened up our solution in the 2005 beta, and was astounded at how much slower it was. But, I guess the "beta" thing is key here, and the slowness could also have been due to the "unused local variable" warnings numbering in the tens of thousands.

Sigh.

I'll hang up my sexist, geek beard when the British synchronized swimming team accepts my application form.

On a serious note, the reason Women don't create great programmng languages is that they spend too much of their time fighting of the male of the species.

So, What's it?

oh yes we can

I haven't put any thought into my cognitive state, but bad eyesight runs in my family (while i remain glasses-free). Given the developers penchant for very high resolutions and coding in the dark, i get my eyes tested every year just in case so far, so good however, i'm still glasses-free!

This is so true! I don't get profeesional opinion of my cognitive state but it is something that both me and my partner monitor. It is interesting how much 'health' is driven by attitude and we have been researching this area a fair bit. Kris (my partner) runs a motivational coaching and mentoring company and I do my share of this for technical companies. Maybe measuring cognitive health is something that could (should?) be added to the package we offer?

Imports int = System.Int32
Imports bool = System.Boolean
...
etc

and you can code in VB using C# style :-)

Hey Geoff,

I'm lucky there, and despite having once scratched my eye badly, had chemical burns, welder's flash, etc, my eyes are still good These days I have modified my behaviour, and have lots of different safety glasses for all occassions

Hi Neil,

Ah, straight from "the doctor's mouth" And yes, most definetly! I think software development needs to be more holisitc, not just matching the product to the customer, but also in the complete development process. I think the "softmore" days of drinking coke and eating pizza while coding for days on end without a break is a lifestyle that people often associated with "geeks". Yet that lifestyle is really unsustainable and is also probably a major contributor to those late night mistakes/bugs. And we also really are at a unique period in time, when only now are we beginning to have "veteran" developers
But I haven't heard of software shops really taking this into consideration. I'm not even sure how many individuals do.
Maybe it's time for a "healthy developer" movement ?

I've been reading the to-and-fro you and Mitch have been having.
I like Mitch. He's been a useful source of info. And he's a canberran.

But you write VB.

So I'm on your side for this one

Tretchery! I'm going to come out there and unplug your cable. No more Internet for you!

IMO the biggest gain of generics being CLS compliant is this:
Without CLS compliancy, some C# devs had the excuse of not applying the attribute to their assembly. Because of that, they could easily fall foul of writing case sensitive public methods e.g. void DoSth(Car car), which are unusable from VB. Now, there is no excuse :-)

I have my RSA certificates and my PGP keyring on it

Hey Bill, traced you over from Bill Ryan's blog..

i'm not sure where i left my brain, but i've never actually thought about using the key for anything other than bringing files home to work with (that was actually why i paid the fugly $189 for it!!!!).

I've now seen the light...excellent idea!! gonna fill out my meagre 256mb usb key with useful stuff now!

best remedy ever - coffee....i'd swear by it!

Totally agree with you. THere are times when it's necessary - so be it - I have no issue whatsoever there. It's just that people that leave it off because "it helps me code faster" or ______(fill in lame excuse) that's when it's an issue. I think the ability to turn it off is a positive - I just think it should be on by default.

Hi Bill,

Yep, definetly On by default. But to change that now, they need to address the visibility thing, which of course would have lots of other positives. nad if they make it more granular, I think folks will tend to use it more wisely

LOL ! Funny you should say that ... I've gone from a 10+ cup a day person down to a 2 cups a day only, and decaf the rest of the time. I still love the taste of coffee, but am no longer addicted.... and it's that addiction I am afraid you might be thinking is a "pick me up". It's not really, it's more your brain is bitchin' on ya till you feed it some more caffaene

don't forget to load Windows 3.1 on there just for fun ......

hmmm... that reminds me... I should try to find the old trumpet winsock and Netscape 1.2

Agree. But just a nitpick by way of correction, IUnknown doesn't cause late binding, IDispatch does that.

I think that would be a good suggestion with the essentially block-level setting of option strict on/off.

I like the idea of regions. I'm just not a fan of the actual text you chose. I'd prefer something that makes it very clear that you are relaxing the type checking. You shouldn't have a keyword to enforce it for a section.

So, I'd propose something like:
#Relax Option Strict
'Code with relaxed type checking
#End Relax

This would enforce the fact that you are doing something potentially unsafe. And, it would also force you delineate the code that allows this (instead of the other way).

Hi Bill,

Couldn't agree more. I mentioned to Bill that the irony is that people see having it off as a newbie thing. Having Option Strict off should be considered an advanced technique! I like the idea of having regions for it but if we're going to pick a name, I like Martin's suggestion.

Regards,

Greg

Hi Scott,

IDispatch is the mechanism by which we do late binding, but IUnkown defintions is the cause of API that have parameters/return types "As Object"

Hi Greg & Martin,

Maybe we should bat this around a bit more ... I think the # is good, as that is in keeping with compiler directives (not regions)

But I don't like the Relaxing as such, because then we would need another for Tighteneing. And now in 2005, we have more granular control of compiler switches, albeit only at project settings level, but ideally we should be able to apply any of the switches On/Off at a block scope. so concepts of Tightening/Relaxing would probably just complicate things...

How about:

#Compiler Option Strict Off

#End Compiler Option

or just :

#Option Strict Off

#End Option

i'm going to try NOT to load winblows 3.1 onto it but i definitely need the dell diagnostics software and ghost...

Bill,

touche!

Happy new year man!

Hi Bill,

I did the same. Installed it becuase it's from Oz.

Besides the fact that it is quite buggy.
It a good product.

I have been using it for 3 months or so and I'm looking forward to Synop delivering another release hopefully with less bugs!

Last time I gave it a whirl it was a massive memory hog (that was before I had my 2gb ram pc though)

I'm happy with Newsgator outlook edition

- Angus

What if you made Operator+ overridable in Invoice and Overrides in ShippingInvoice?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vboperatoroverloading.asp may be relevant also...

Hi Matthew,

Operators are Shared, so you can Overload them or hide them with Shadows, but you cannot make them virtual which is what Overrides requires. It's for this very reason there connot be polymorphism with operators as they are Shared (aka static)

"ShiipingCost?"

You could probably accomplish what you want by providing an overridable instance method (ie, Invoice Invoice.AddTo(Invoice a)), then calling that from the operator in Invoice. Derived classes would redefine that method rather than shadow the operator.

You do realize that this is the same in any other method in .Net as well? And in any other static typing OO language that I know.
What you've here is a simple compile time checking, nothing more.

Hi Clarke,

yep I am finding it buggy when posting (usaully takes a couple of attempts), and deleting items from the top of the list is really slow redraw in the UI. Also it seems to do soem wierd stuff when you've got it set to auto summary view. Other than that, not too bad.. shows lot of promise.

Bill

Hey Angus,

I **really** do NOT want blogs messing with my outlook store

As far as memory hog goes it does seem high, but is less than SharpReader or on par with it. The memory allocation is really a .NET thing

hi Dan,

Exactly !! If they want polymorphic behaviour then they need to use instance methods that are Overridable. One problem though that you do get with Overridable methods is that the type is that the derived type cannot be represented (strongly typed), for example, let's say we had an Add method :

Public Overridable Function Add(value As Invoice) As Invoice

When we go to override that in the derived class, the return type remains as Invoice, not ShippingInvoice. SO what happens is as we extend our hierarchy, we are forced to extend the number of methods. ShippingInvoice becomes:

Public Overrides Function Add(value As Invoice) As Invoice

Public Overridable Function Add(value As ShippingInvoice) As ShippingInvoice



BTW: looks like I need a spell checker on my property/public field declarations

Bill

Hi Ayende,

This is NOT the same in any other method in .NET, at least not instance methods. What we are looking at here is the issues that arise from operators being shared (aka static), something which may not be obvious from the code that uses the operators but should be obvious from the code that declares the operator. But if these calls were instance methods then the issue would not arise.

Bill.

http://weblogs.asp.net/autocrat/archive/2004/12/10/278899.aspx

I have lost about 3 huge blog posts by it simply not saving my posts when I hit the save button

When you use this software, make sure you copy/paste the html source of the entry into notepad for backups - otherwise you might end up a very angry soul

Have fun! I need to get working on mine so I can use it instead, till then - sauce reader it is!

Blog link of the week 01

I admire the way you incorporated hookers into your code.

If they _have_ to do it (and I wish they didn't) why couldn't they just write a 'Option Defaults On/Off'? While your <VBNoDefaualtInstance> attribute is nice, it's limiting those people who want to (sadly) use it.

With Option Strict On, only the code i write gets checked, and errors generated at design time if i forget to type something.

With an Option Default Off, same deal - if a call is made on something that would ordinarily be using a default instance, a compiler error is thrown, and we get a red squiggly underline.

Or am I missing something?

Thnx Jeff

Hi Geoff,

Options can be applied to a code file. When you consider partial classes, an option allows coding within each partial class as per the code fiel, not the entire class. For example you could have one partial class with Option Strict Off and party down with late binding, and in the other partial class have Strict On.

So Options are not type/entity specific. That is, if you had Option Default Off in one code file, and Option Default On in another, then if we have partial types, then what rules are applied and where ? Which form gets a Defualt Instance generated for it, and in which code file can you call on Default Isntances using the shortened syntax ?

This is why i went with attributes as they are entity/type specific.

I think if we can get the Vb team to see the light on this, we will have macros and tempaltes otu there very quickly that will turn these things off for the experienced VB developer

I get what you're saying, but I'm not sure I really see the problem.

There'd be a global setting like there is now for the Options - so by default you'd have option defaults on or off, as your preference.

Let's say we default to setting it off.

If in one code file, i manually add a option default on line to the top, then that's exactly what i mean - only in the code in this file does the compiler allow the the compile to happen if any default instances are referenced.

So now let's say we default to on.

If it's manually overridden in particular code file to off, then the compiler throws errors in that one code file saying that the defaults used there can't be.

In both cases, i've manually adjusted one specific file to allow or not allow an action, and in both cases that's exactly what i wanted.

I don't see how partial classes are a problem - each is a code file, and each has it's own requirements - surely if i have a partial class split over two files, I can have option explicit on one and not on the other?

In all cases when defaults are an issue and not wanted, it's the code that _we_ are writing at the time that has to be on guard. If i write a form and someone uses it 'defaultly' (hey, i'm inventing english here!) that's netiher a problem of mine or a concern of mine. However, if _i_ don't want defaults, I can choose to not use them or not. Having a compiler stop you from touching those areas is as good enough for me as having them removed. However, (and i'm using a metaphor very very loosely here) just like I don't think mormons should come to my door preaching god to me (it's up to me, not them, whether i want to beleive in god) I have a real issue with stopping _others_ from touching my stuff in the way I see fit. They should do what they want with it, and if they want to touch it via defaults, they should be allowed to. I might not like them doing it, but I shouldn't stop them.

I'm sure there's a bigger picture here, and i'm really only thinking about forms, not anything else in the My namespace, and I'm sure you still totally disagree with me That's ok, tho. The real point I guess I'm trying to make is that this is something that _must_ have been requested a lot for them to bring it in, even if we see no evidence of it now - so i'm happy to just adjust my habits to welcome the addition, but never actually call it myself. That way, i'm happy because i never get stuck with the issues that defaults bring in, and other people are happy, because they can call their my.forms.form1 and eat it too

(Also note: I'm fighting you on this mostly for the principal of the thing - debate is useful to ensure that you're happy with your own justification, and I couldn't help but take a different approach just to make sure that you can fully justify your reasoning *grin* I quite like your idea really, jsut trying to come up with different solutions, especially this late in the whidbey cycle where large changes are likely not to happen

I'll shut up now...until you decide to respond anyway

(PS: Do you have any control ove rthe CAPTCHA control? I can't tell if it's a zero or an oh i'm supposed to type, and so far i've got it wrong everytime

hi Geoff,

Okay so I see you are viewing the Option Default On/Off as being consuming code only ? That is, it dictates whether or not you can write Form1.Show, but doesn't dictate which forms are actually default instances.

One of the main reasons I choose attributes was so as I could have granular control over what forms appear in My.Forms. That is, I might only allow certain default instances such as my option form, or there may be a special form I really don't want a default instance of used (yeh I know, all of them )

So through Imports and attributes we have fine granular control which means we also have extensibility.. who knows what the future holds right ?

Oh, and the CAPTCHA, nope, no control at all.. it gets me sometimes too I think machines probably can read it better than we humans

Yes, that's what i'm thinking - compiler protection, just like option strict

Well then just to flush out your attribute a bit more(*), what about inheritance?

The only forms that get put into the my.forms collection are those that are in the current executable project only. So what if using visual inheritance the form is declared in a different assembly, but but my new form inherits from it, what happens?

If the derived form has the attribute, obviously it's excluded from the forms collection.
But what if the base form has the attribute? Obviously the guy that wrote the base form didn't want it touched - so does the form go into the forms collection or not? If it _does_ go in, that's a waste of time for the guy that wrote the base form to even include. If it _doesn't_ go in, why would the guy who wrote it in C# care enough or even know that he _could_ add the attribute?

For that point, I don't have a VS2k5 instance nearby to check, but do inherited forms even make into the forms collection anyway? I would hope so

Actually, i think this brings up the biggest problem. Something as big as this, which can completely change the way you write code (dependant on your retardation - sorry, i mean skill - level) is fundamental to the framework. This shouldn't just be a VB thing - it should have been an all or nothing thing, even if it _is_ only vb6 gumbies that want it. That way all the C# and C++ and other .net language people will also have voted in the PFC to not include it, and they would have listened.

OK, well it makes sense to me!

* still just stirring the pot

inheritance would work without any issues

the Attribute would be marked as being inherited and being applicable only to classes and assemblies. So let's say you have class foo, and class bar: inhertis foo. If foo is written as :

<VbNoDefaultInstance()>_
Public Class Foo

Then Bar would inherit that attribute by default. But Bar coudl also overwrite that attribute, e.g.

<VbNoDefaultInstance(False)>_
Public Class Bar : Inherits Foo

And hence Bar could be a default instance but foo could not...... and they all lived cross language cross assembly with visual inheritance happily ever after

(and yes inehrited forms do get def instanced)

Hi Bill,

I think it must have suffered melt-down. No access with or without passport.

Regards,

Greg

Hi Greg,


Yeh either been hacked or running it past MS legal

Captcha also stops you from posting via RSSBandit or any other CommentAPI capable reader, perhaps they will begin updating RSS Readers to include this but I haven't seen one yet.

I recently started using SharpHIP which is basically the same as Captcha, I have since received 0 spam which I used to have to clear several times a day.

I am sure that you could add Accessibility to the control easily, there are several ways I can think of to extend one that would still frustrate spambots.

I also thought of using some sort of Beyesian filter control instead to just filter the comment and reject it if it meets certain criteria. That could at least cut down most of the spam I got which was 10 links and no real text.

Ok, this is a rather tricky scenario! But I think Dan's idea, taken internally as a Protected Overridable Method, called by the +Operator, and then overridden within the Derived Class, should be the ticket:

Public Class Invoice
Public Price As Decimal

Shared Operator +(ByVal first As Invoice, ByVal second As Invoice) As Invoice
Return first.Add(second)
End Operator

Protected Overridable Function Add(ByVal addInvoice As Invoice) As Invoice
Dim retVal As New Invoice
retVal.Price = Me.Price + addInvoice.Price
Return retVal
End Function

Public Overrides Function ToString() As String
Return "Invoice Price = " & Me.Price
End Function
End Class


Public Class ShippingInvoice
Inherits Invoice

Public ShippingCost As Decimal

Shared Shadows Operator +(ByVal first As ShippingInvoice, _
ByVal second As ShippingInvoice) As ShippingInvoice
Return DirectCast(first.Add(second), ShippingInvoice)
End Operator
Shared Shadows Operator +(ByVal first As Invoice, _
ByVal second As ShippingInvoice) As Invoice
Return second.Add(first)
End Operator
Shared Shadows Operator +(ByVal first As ShippingInvoice, _
ByVal second As Invoice) As Invoice
Return first.Add(second)
End Operator

Protected Overrides Function Add(ByVal addInvoice As Invoice) As Invoice
' Overrides Invoice.Add() which is the Protected, internal implementation
' for the '+' binary operator.

If TypeOf addInvoice Is ShippingInvoice Then
With DirectCast(addInvoice, ShippingInvoice)
Dim retVal As New ShippingInvoice
retVal.Price = Me.Price + .Price
retVal.ShippingCost = Me.ShippingCost + .ShippingCost
Return retVal
End With
Else
Return MyBase.Add(addInvoice)
End If
End Function

Public Overrides Function ToString() As String
Return "ShippingInvoice Price = " & Me.Price & _
", ShippingCost = " & Me.ShippingCost
End Function
End Class

The above seems to do the trick. It's not necessarily "perfect" in that I really was not sure how to handle mixed-class operations and had to make a choice. For example, how should one handle BaseClass + DerivedClass? Should one add them as BaseClass's, or just Throw an Exception on the basis that this has "no valid meaning"?

I decided to take a "lowest common denominator" approach and decided to make it legal, but to have the results be interpreted as a sort of "BaseClass.Add()" methodology. The other approach would be to have it take a "DerivedClass.Add()" methodology, but consider the BaseClass.ShippingCost = 0. Or maybe just Trow an Exception in a Mixed situation.

However, adopting a "DerivedClass.Add()" methodology cannot work in the above as-is since the BaseClass cannot have a clue what to do. It can't even know to Throw an Exception in a mixed-class scenario, because it can't even know that there is one. Or can it..?

I'll follow-up with an explanation of how to pull that off if anyone is interested...

Mike

I thought it was supposed to be the other way around. VB.NET is more user friendly that C#. Talk about a drastic change of events. Pretty soon C# with have E&C and VB.NET won't, they'll just have a command line debugger.

See the below interesting article:

http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx#top

Now who said VB.Classic was dead? ;-)

vb.classic will still be heavily used for the next decade or so (slight over exaggeration ???)

all i know is that i'll definitely hand on to it for the rest of my life!

How'bout MSDE 2005?

>- Explicit casting. CType or DirectCast, such as CType(myfoo, IBar).DoIt

Of all the things that whidbey is giving us, do you know what i'm most impatient for?

TryCast.

Hi Geoff,

Yeh I wanted TryCast way back in the beta's of 2002, but more for performance issues than anything else. If you use TryCast, you then have to test for null, as opposed to testing the TypeOf the object before doing a DirectCast, well there isn't really much difference in coding style, rather the difference is in the under pinnings.

Personally, as much as I like TryCast, especially as it does make it easier to port C# code to VB.NET, I would have preferred the effort went into recognizing and optimizing the If TypeOf foo is bar Then .... x = CType(foo, bar).

Or basically what I am saying is that a high level language should not force us to use different constructs for optimisation where it is posible for the compiler to do it for us An example is ForEach with arrays.

In my blog post, I completely misunderstood what you were tryingn to say with "End XXX," apologies. Although, it's probably obvious that I don't agree. I'd like to hear examples of your thoughts on how VB is more object-friendly.

Hi Dan,

Actually on the End XXX constructs, I said that pretty badly What I meant to say is they are more readable, but they do also more closely mimic the spoken language. Try this yourself at home, write a couple of blocks of C# code then try to read the code out aloud including all block and flow constructs. Presume the person listening to you cannot see the code. When you do that, you will or should find yourself uttering "end if" for your }'s that indicate the end of an if block etc.

As to VB.NET being more OO, well interfaces, event handlers, are all implemented in mroe OO fashions. I'll blog about these separately as I think a lot of people haven't yet seen the forest for the trees on these issues. Think polymorphism, think encapsulation, then look at how the two languages compare.










\

Blog link of the week 08

On readability, what I'm saying is that I can more quickly look at C#/Java/whatever and understand it. Obviously "end" is more natural than "closing brace thingy," but I'm not saying the words in my head. My brain just parses it. VB is slower for me because of its verbosity. If I needed to read the code aloud to someone else, sure, "End XXX" is better.

On event handling, I can understand your argument. But I consider event handling in VB to be a very leaky abstraction (as Joel on Software would say). Serialization issues, inadvertent GC rooting, et al come into play here and it all comes crashing down.

The issue, I think, is that VB (currently) has the abstraction in lieu of the "nuts and bolts" pieces that you need to get event handling to work, 100% of the time, in every context. The "RaiseEvent" keyword doesn't do me any good if, for instance, I want to raise the event asynchronously. This is elegant in C# because the underlying implementation is accessible.

So in conclusion, I think OO abstractions are great. But we need the fundamentals there first.

hey Dan,

On readability: yes on both counts VB.NET is indeed the more natural language. As to it's verbosity, well that is coded telling you things, rather than being reliant on added in comments, the code itself is explanatory. (which also brings with it conformitiy) It's all part and parcel of declerative programming.

that being said, I do think at a shallow level, C# code has a lot more whitespace in it, which visually, for some folks can make it easier to scan. I think for Vb.NET, improvements in the IDE can make a significant change there.

But as to your difficulty in parsing VB.NET code, well as you said, VB.NET is actually more natural. It is probably more that you need practice reading and writing the code. Your mind will soon pick up on keywords and skip similarly to how you do in C#. For example, you won't focus on the Dim keyword, rather just mentally note the declaration is there and when looking at it you will focus on the variable name and the type. So on the visual side of things, that really is a matter of experience.

As to events in Vb.NET, I'm sorry but there is no "inadvertant GC rooting". I don't know who told you that, but you/they were sorely mislead.
On serialization, Vb.NET has absolutely no problems with XML serialization. There is however an issue with binary serialization and MarshalByRef classes. The real problem is MarhsalByRef classes, eg a Windows.Form, cannot be binary serialized. If you need to work around that, you can do so in Vb.NET 2005, and more elegantly than C#
As to async event raising, I'm sorry but once again you have been sorely misled, but that is also a common misunderstanding. I remember sometime ago Juval Lowey wrote me saying you couldn't raise events in VB.NET asyncronously. I wrote back and told him you could, but it took a couple of emails and the code before he was convinced. Then happily a couple of months later he told me that you could raise events asyncronously in Vb.NET <bg> Anwyay, so the experts are all in on this, and indeed you can *easily* raise events asyncronously in VB.NET, and have been able to since day one.

So when we look at what you claim to be a leaky abstraction, you are basing that purely on not being able to binary serialize events if any handler is MarshalByRef. That is not the fault of the abstraction. In fact if you look at the VB.NET 2005 implementation you can keep the abstraction AND also customise the storage and raise method in an encapsualted design that uses the full CLR spec, something which C# still doesn't do.

I will follow this up later this week with a couple of posts on Events and Event handlingn in Vb.NET. Seems there may still be some folks who need to learn the facts there

HOLA

Bill: The "Visual Basic language" is fully supported in the form of VB.NET. Unless you mean "the VB 6.0 language," in which case that's what you should say. ;-)

Hey Phil,

Those points, 1 to 3, are from the petition. On point 2 it says :

"Microsoft should demonstrate a commitment to the core Visual Basic language. This core should be enhanced and extended, and changes should follow a documented deprecation process. "

I think that patly applies to *both* VB6 and VB.NET, as neither at present has a documented deprecation process.

aptly applies that is

Hey Bill, here's a post discussing this very topic

http://blogs.msdn.com/Brad_McCabe/archive/2005/03/12/394658.aspx

Hey Frank,

Maybe I should have been more clear. Brad's blog entry does NOT tell us if Longhorn will have the VB6 runtimes on it or not. That is the primary question.

BTW: I also found Brad's post pretty mis-leading. As far as I know you CANNOT distribute the XP VB runtimes, so support for XP runtimes won't do people any good as they will need to compile against the last public available runtimes or those runtimes they have a license to distribute.

Oh and of course that owuld mean there is also no support for VB6 on Longhorn !!

Hmm...

I am interested Bill if you still support versions of your product that are 6 years old and 2 (nearly 3) version cycles behind?

Hey David,

Where do you get 6 years old ? You are aware Microsoft Spyware which was *only* just released in the last couple of months is written in vB6 aren't you ?
Personally I don't own any significnat VB6 code as I was one of the first to move to VB.NET. But I am aware enough to see that many companies and individuals do. Just about every developer survey will tell you there are still millions working with VB6 *today*, not 6 years old.

VB6 was released at the start of 1999, which is 6 years ago.

I don't doubt that there are companies still working with VB6 code, but do you seriously believe that Microsoft should continue to give mainstream support to these companies until they are finished with VB6?

I was talking to a well-known Australian Microsoftie last week and he made the comment that most of the people that are making a fuss over this don't even call product support services. Even those that do. have most likely used the two free support requests they received with their product anyway. Because that's all we are talking about, two free support calls!

I think that those that are still holding onto VB6's lifeless corpse are worried. They're worried that because they haven't updated their skill set (whether it be because VB.NET looks too daunting or because they are too comfortable where they are) that they are going to be out of a job soon, and that mainstream support ending has made that inevitability, that little closer…

Hey David,

I think you are entirely missing the point. Pretending that all VB6 apps are 6 years old is hardly conducive to talking about the real issues, nor is saying all people coding VB6 will soon be out of a job. I think if you talk to some of the top consultants in Australia and World Wide, you'd be amazed how many are still working with clients who have VB6 code assets. These people aren't going to be out of a job, nor are the people working at those companies. Reality is, as cool as .NET may be, there really is no need to re-write a lot of existng applications to take advantage of some of the things .NET has to offer. In fact telling people to re-write their existing applciations now, as winforms is about to move into deprecation mode and Longhorn API is only a year or two away would probably be the worst advice anyone could give them at present.

Anyway this has drifted so far away from the actual issue of the pending DLL hell ....

So anwyay, please don't start saying folks are all going to loose their jobs, that all VB6 apps are 6 years old, that no-one is still using VB6. All those statements coudln't be further from the truth. Look at any recent developer survey. The number is still in the millions.

If it doesn't imapct you, good luck to you, but let's not pretend the issue is not real.

Hmm... I guess the following quote from Brad McCabe is "a little confusing":

"I have checked with the Development group and it [VB6 Runtime] will work with Longhorn. "

Hey Cory,

Actually Brad says in the comments of his previous post:

"Individual applications might not."

in regards to Vb6 on Longhorn.

That VB6 might just happen to work on Longhorn some of the time, but is an *UNSUPPORTED* scenario is the real issue.

Whether the VB6 runtime is included with LongHorn OS is also part of the issue. If it is not, then talk about VB6 being supported because XP is still supported is just misleading people.

All the focus is on the development community, but non software developer users, the millions of amateurs, use VBA to customize word in lots of domain specific ways. It is a big selling point for Office. Office is a mid-range product whose shortcomings can be compensated by third party or self developed customizations. If that capability goes down the tube then the attractiveness of alternatives goes up a lot. Thus the user community could end up playing as big a role as developers. This user community typcally have jobs that are in areas other than microsoft won't lose their jobs no matter what Microsoft does.

i have a 7k60 too, amazing ;-)

I think its reasonable to have support for programming languages shorter than support for programs compiled in those languages.

One is to do with supporting 'programmers', the other to do with 'users'. They are a significantly different client base, with significantly different needs.

Hey Matthew,

First, it's important to remember that with VB6 (and VBA especially) the user is often the programmer.

But the key point here is that there technically is no reason to stop support for the VB6 tools especially when Microsoft is continuing support for thier C++ COM tools.

You are right on the money Bill.

I don't like today's ability to call static members on instances but a much better solution than the C# approach (which is what we get in VB2005) is your suggestion.

Propose it to ladybug and you'll have my vote. The icon overlay may be too much to ask at this stage, the automatic substitution of instance variable with class name may be too much to ask *but* it should be fairly straightforward to show the list of all members and give me the warning/error if I choose a static method (I can then correct it myself!).

Thanks Daniel,

I think you are right as to what could be done to rectify this now.


I already gave the team this feedback sometime ago, so I am pretty disappointed to see it not addressed yet. Perhpas if you were to ladybug your suggestion ??

Good One

cjgjdg

A loss of 25% of VB 6 developers isn't necessarily a bad thing. I'm part of that 25%. I moved to VB.Net. I'm sure that Microsoft is pretty pleased about that conversion.

I wonder what % of that 25% went to VB.NET or C# as opposed to RealBasic or Java. From what I see in my world, most went to VB.NET or C#...

Hey Eric,

Actually my understanding is the 25% is those who moved away from all VB including VB.NET. Many of them moved to C#, some to Java some to Delphi etc.

I wouldn't say that REALbasic doesn't have true properties, but I agree it doesn't have the Property block you're used to (although I do suggest filing a feature request for that if you're interested in that feature). However, you can "fake" a property by using a cool language feature called "assigns". For example:

Class MyGrid
Sub ColumnCount( assigns newCount as Integer )
// blah blah, use NewCount somehow
End Sub
End Class

dim foo as new MyGrid
foo.ColumnCount = 4

The method "ColumnCount" will be called in the above code. Using this, you probably can get similar behavior to the property block by creating a pair of methods like such:

Class MyGrid
private dim mColumnCount as Integer
Sub ColumnCount( assigns newCount as Integer )
// blah blah, use NewCount somehow
mColumnCount = newCount
End Sub
Function ColumnCount() as Integer
return mColumnCount
End Function
End Class

Hope this helps,
-Jon

Hi Jon,

I was already aware of assigns. Not a huge fan of it though as it feels to me like a hack/workaround. You end up resorting to method calls, yet in code that calls them this is not apparent. And of course we still haven't fixed the very issue I mentioned, that is a grid at desing time. You cannot set an assigns method in the properties window, so at design time no action can take place.

I moved to REALBasic from VB6 and a massive dose of VBA. REALBasic rocks as a programming language. It took some getting used to the IDE but I prefer it to the all encompassing SUB FUNCTION module view used in VB IDEs. If you want to view more than one Method (Sub Routine, Function) in the same window you can split the IDE's window panes to show you the methods you choose. I've only ever had to use that functionality on a few occasions myself.

If you don't like the binary format of the project you can export the project to XML and make the project external. (I think this is right?)

Assigns isn't really a hack but a real handy function for programming. For example, if I wanted to use a Windows API I'd simply extend the window object and assign a property value...

Sub PutWindowOnTop (Extends w as Window, Assigns Position as Integer)

Then as I type the window object into my IDE this method appears as one of the methods for that window object in the intellisense drop down;

myWindow.PutWindowOnTop = SW_TOPMOST

This saves me Inheriting from the window object and adding a new method then changing the parent class for all of my windows in my application to use my new window object. Yuck! What's more is a whole series of functions in a single module that Extends the Window class can be made external and can be used by all of my projects, I never have to remember the methods and go hunting for them again.

Look, I think REALBasic is brilliant and I program in quite a few diverse languages other than the ones I make a living from (stated above). It is different but the major advantages are the cross-platform ability. I can sell an application to a wider market than just a windows based one.
REALBasics ability to compile the application to a number of "Human" languages in one hit is also a bonus. I can send a spreadsheet of menu-captions, button captions and so on off to a translation service, they can fill out the spreadsheet with the menu-item names in the foreign languages I want and then send it back. I simply import the spreadsheet and voila, I have hit a global market providing the application to other countries, translated into their own languages on three different platforms all in one compilation. That is brilliant! :-) What's more, all the librarys and functions needed by the application are compiled into it so there will not be missing library issues like with VB6 or having to install frameworks like .NET.

Hey Duane,

The extends feature you may have noticed was one that I said I liked and Brendon quoted me on that

But rather than code such as :

Sub PutWindowOnTop (Extends w as Window, Assigns Position as Integer)

I would expect that to be more like:

Public Property Let Position() As PositionEnum Extends w As Window


In RB's version of it, the method appears to declare two parameters but in practice the method is never called passing in parameters. So I view it as an inconsistency.

Functionally, assigns, is not equivalent to a property. There are real differences there, not just design time. I know when I first looked at RB, I did a simple test, psuedo code follows:

Class IBase 'VB6 abstract base class
Public Property Name As String
End Class

Class Derived
Implements IBase

Property IBase_Name As String
End Class

Totally failed in trying to upgrade to realbasic. And this is the exact kind of pain VB6 people can expect if trying to upgrade.

so the point I was and am making is that RealBASIC is not a replacement for VB6. IT's an alternative, but it won't address the problems of upgradign your VB6 code. In fact the path to VB.ENT is a lot easier. And for Vb6 people, I think they will find the VB.ENT syntax a lot more familiar.

That's not saying RealBASIC is bad, it's just not an upgrade path from VB6. The current marketing around the demise of support for VB6 might make people think otherwise.

I think if people want to look at REalBASIC, they really do need to look at it as a different language, not an upgrade. I do think RB has some cool features.

I totally disagree with you as to the editing experience. I'd much rather have a pre document view any day. And to go with that, I'd much rather have single documents. Exporting to xml just doesn't cut it. And although I didn't try it, I'd imagine RealBASIC would have real isues when trying to use it with a source code versioning repositry (something akin to source safe or vault etc).

That being said, I will be keeping an eye out for changes in RealBASIC in the future. I think if they address these and other issues as have been raised with Geoff, then he'll have a great product.

That is a great new feature! In VB 6, I always requested people put lower bounds in their declaration to save me unnecessary thinking. The same feature in VB.NET (even if the lower bound is fixed at 0) will once again save 'unnecessary thinking' and make code easier to read.

Bill,
I'd agree that RB is a different language, it does seem to have elements more akin to other languages than VB on occasion.

I must admit I tried importing a VB6 project and couldn't be bothered with the changes that needed to be made manually, it was easier to write out project again, but then it was someone else's VB6 project which I was unfamiliar with so I guess some people find it handy, I didn't on that occasion.

Porting the code across can be painful in any language though I guess :-)

RB's move to windows has been fairly recent which is when I got into it and it was a Mac development tool before that, developed from CoolBasic I think, anyhow it derived from Australia (I forgot the developer's name) I think Geoff was his partner for a while and then bought him out and changed the name to REALBasic. For a history on it's beginnings for anyone interested all you need do is download the PDF Sampler from www.rbdeveloper.com and the story on RB's birth is in an article in there.

RB isn't really an upgrade path but a lateral shift to a different development environment for delivery of cross-platform compilations from a single source. All they need do now to make it more awesome is to compile Java byte-code files aswell. Geoff was asking RB Developers about their experiences porting code to RB a while back and one of the languages he mentioned was Java. Did he mention any of this during your interview with him? I'm wondering where they are heading with it.

Coolies...

Well Isnt The . Net framework supposed to support any language???

maybe someone will write a vb classic compiler for .NET


The in the meantime for those of you that wrote code in VB6 and have been left hi and dry you shouldnt me surprised at all.


When VB went from 16 bit to 32 bit the same thing happend and there was exactly the same problem ... with backward compatbility.... or have you all forgotten the VBX -> OCX night mares

Funny though, it was about that time that Delphi suddenly became hugely popular... because Delphi developers had no such upgrade issues..... (and it was way superior)

Its pretty sad that MS managed to spread so much FUD that delphi began to fade away....
Interestingly Borland has just released Delphi for .NET 2005 and with minute adjustments (mostly conditional compiler directives) all the delphi samples recompile in .net pretty much with out fuss....
http://www.borland.com/delphi/demo/tutorial/tutorial1.html


So those guys still smart enough to make their own choice and use delphi... can now

compile to either
Native win32
.NET
Native Linux (in many cases).

All from the same source code
All from the same IDE
All from the same Components...(delphi components are written in delphi)

Eat your heart out.

Ah yes, but can we finally drag a project onto the 'references' node in the solution explorer to make a project reference? now _that_ would save me most of my time in that dialog

I'll second Geoff's comment... Took the words right out of my mouth (or keyboard).

You were not there at the last MVP submit but I asked for it: every dialog window must be resizable ;-)))

Amen brother!

Invest in Delphi and end up waisting money.
Delphi was from day 1 OO, VB6 hardly was.
Now the OO power is available to VB programmers.But it comes at a price and that price is adapting you way of programming and rewritting code.
You gain an environment that's so dominant/sophisticated that Borland is has adapted Delphi to fit in. (Making it easier to mover over to C# or VB dot net )
And yes, VB6 is still used in many companies including mine.
And yes, as all VB6 programmers I had a GENmodule
And yes, the screen handling is less easy

But I must say, I preffer dot net above VB6

I'm running a 4200 RPM Travelstar that is just far too slow for normal use. :-(

Where did you purachse the 7K60 and what was the price?

Thanks.

Why would refactoring support in VB cause 'an extreme case of VB envy' in c# devs? c# already supports refactoring support.

VB6 should be able to compile Standalone Applications.

Files are on my USB key

Geez Bill... Are you also sorry *I* was offended reading your post? I think I'll go throw up now.

TB: in response to your question "Are you also sorry *I* was offended reading your post? ", the answer is NO!. Why should I be ? I have no idea why you would be offended.

....Not to mention C# has Resharper which is based on InteliJ and kicks the pants of pretty much any other refactoring tool out there, and generally enhances the Visual Studio IDE experience. Sadly not for VB. It's also been around for quite some time. No VB-Envy For me! Nice try though

Heres some more info on Steve Maine's blog: http://hyperthink.net/blog/PermaLink,guid,c84fb408-a764-48f4-870e-498191031c89.aspx

Seriously though if it's as good as or better than Resharper, which I doubt 'cos it's a big ask, that's really good for the VB community because these sorts of tools are great.

Actually .... looks like the next version of Resharper (v2.0) is going to have VB support too. Equal playing field
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+2.0+Plan

Background: I have been working on mainframe computers since 1986. Please spare me the BS that mainframes are out-of-date; no longer used. Yes, we still use ASM & Cobol II.
I also run my own VB development shop that supports products that we initially wrote in 1986 - and have been updating ever since (refer to www.ebt.net). We have 13 products; over 600,000 lines of code.

Here's my point: Large banks, large insurance companies - still use COBOL2. Why - because they have an investment in that code. If you don't run a business where you actually have to support lots of clients and interfaces - the point is probably lost on you. Microsoft has simply told the developers - go screw yourself and your investment. All you have to do is....... well that is BS.. We use VB6 because it stable; capable of working on many platforms.

If I have to "convert my code" AND/OR basically re-build programs from scratch - it would be worth my time to move to a platform that I KNOW will be useable 5 years from. It is obvious to even the most casual observer - that Microsoft is saying "count on the platform 'X' " until we have a new platform. Yes - Delphi - looks better all the time

Finally - who is still on VB6??? Well lets see: mmm - Microsoft, American Airlines, EDS, CSC just to name a few.

Microsoft has to remember that most developers are in the business of supporting and developing new software for their - clients.... not forthe love of learning and converting to yet one more thing.

It is this mind-set from Microsoft that has allowed me to convince our management to pull-out every flipping Microsoft Exchange Server and go to a mail system that is stable. Yes - there were patchs for Microsoft Exchange - and they have new platform... but the point is - I don't care. I am not in the business of helping Microsoft and learning new patches and new fixes; I am in the business of helping my clients. By being a VB6 Developer - I had always thought that is the way Microsoft looked at us(as their clients)... but it simply not true.

MDWait

w00t!!! It's back it's back it's back!!! *dances*

It's strange how they'd bring something like that back in, having decided to get rid of it in the first place...maybe they needed it to get default form instances working *grin*

LOL ! Geoff, that's just cruel

Seriously though this rocks ! And it's actually done by the framework team !!

i've swapped back to my old ways already

I use #5, with Procedure Separators off. ;-)

#1 all the way baby.

I'm also a fan of apps hungarian as desscribed by Joel in this article:
http://www.joelonsoftware.com/articles/Wrong.html

I prefer #1.

camelCasing without any prefix;

to distinguish between local and member variables you should use [this]

#2 at work (Tha'ts the corp standard..) and #6 at home.

Why, it's less typing...

For all non public variables I use camel case, and I just use the _ to indicate it's module level... (I'm too lazy to type the extra m)

I use:

pCamelCase

The p is for 'private'

Hey Jacob,

Good article. Basically use common sense when naming <g>

Scary thing is I kind of agree on the Exception thing also. Everytime I write code knowing that it may cascade an error out of a method, I just get this urge to not do it.. to try to encapsualte that. Can't always achieve it though

Phil: But what happens when someoen else workign on your code does have procedure seperators turned on ?

Anatoly: Doesn't that require you to have a different naming pattern for case insensitive languages ?

Eddie: ROFL. I've hear people say that for 3 & 4 more so than 6, as then they just type m, instead of SHIFT -

I Agree with Anatoly. If I have a property with the same name in VB I always put Value in the end of the private module variable (camelCasingValue).

I seriously can't believe that they added to the framework.

I can just imagine the questions by newbies now, what's the different between Print and Writeline?

Do they seriously think that VB6 programmers are that stupid that they can't learn a different way of doing things?

Hey David,

thought'd you love it

Nice thing is it's less to type, only 5 chars instead of 9 !!

You are right however it may cause some confussion, so hopefully over time they'll deprecate WriteLine as it's now obsolete. That'd be pretty cool when you think about it, you'd just have Print and Write, so with the aid of intellisense automatic word completeion you'd be down to only having to type either p or w. Rocks hey !!!

Oh and the nicest thing is it's based on observing prior art

What Anatoly said. Using the underscore can lead to FxCop violations if the field isn't private, and I just don't like "m_"

And I know you're asking for private field naming conventions, but I don't want a different naming convention for private and non-private fields, so I end up not using "m_". I used to, but now I just use camelCasing and prefix this (or Me, or self, or whatever the language wants) to scope it and make it explicit in code.

And your CAPTCHA control is driving me nuts! I can't tell if some characters are upper-case or lower case of it's a "1" or an "l".

Jason, you *should* have different naming conventions for fields based on their accessibility. Public fields should be PascalCase. (Public includes Friend). Protected fields should be camelCase. So logically it makes sense that if we differentiate for those two (based on MS's published standards), then we should also differentiate Private from Protected. Doing so, allows anyone editing your code to look at the member usage and know whether or not that is encapsulated within the class or not.

Besides a class with a Public Property HashValue using camelCasingValue rules, the backing field becomes hashValueValue. That's just ugly. returnValueValue is another.

On the CAPTCHA, yeh I knwo, sorry ,but not in my control. I beleive letters are only a-f, os it should never be i or l, but it does have a short tiemout as well. Usually will fial onthe first attempt so I don't even bother tryign first time

I'm still trapped back in my vb6 days. Hungarian baby!

Well, at least, I think so, I've never actually bothered to research it.

for private members, I use msFoo for a string, mlFoo for an int, mbFoo for a boolean, etc. The worst of these if mlFoo - in VB6 a real int was a long, so therefore now that I have real ints in .net, the l stayed too
Of course, you'd then think that if I ever had an miFoo, then it would have to be an Int16, but sadly no - that looks too confusing *laughs*

For local variables within a method, I use the same convention - but leave the 'm' off. Parameters to a method I replace the m with a p. Properties of course are PascalCased.

Me, I like the fact just by glancing at a variable I can immediately tell if it was declared locally, passed in, or member level variable. I still put the type prefix on mostly from habit, but it's nice to tell immediately if it's a bool or string or int or whatever. In most other cases, I make sure i name the variables to both be description of what they represent AND their type (eg, moSerializer shows it's the member serializer, and that its, well, a serializer

I particularly hate having to qualify access to members by preceding it with a Me. or equivalent. To me, it's a waste of a dereference operation *grin* When I refer to msSomeString, it's pretty damn well obvious that it's a member level variable and not method call.

It's a sad state of affairs. I know noone that does it the same way as me, but no ones been able to convince me enough to change.

The important thing is that I'm completely consistent, and even someone else complains at my style, they've never once complained (to my face) that they can't tell what's going on.

A good point you did make is access to protected variables. I've never been happy with how I've named them (they still get the msFoo) but I haven't thought of a nice way to make it clear that they're protected and still be consistant to my style (p is already taken....hmm...maybe f for friend

Hey Geoff,

you just sick We'll have to beat the 21st century into you

did you read Joel's take on hungarian ? Jacob posted the link :
<http://www.joelonsoftware.com/articles/Wrong.html>
to summize, he basically talks about using hungrain for logical distinctions not type distinctions. I find 99% of the time I really don't need type suffixes as the name should imply what it is. Waht with intellisense, strong typing and back ground compiler checking that strong typing, I jsut dont' really need to worry abotu the size of an integer type anywhere other than where I declare it. Okay sure I still sometimes use semi hungarian, eg strFoo for locals, and abbreviation style locals for small routines, eg fs for a filestream, but not at moduel level.. I think the biggest difficulty I have is finding good names for method parameters (and NO adding p in front of them is eeeeeeeeewwwww. Like imagine a routine that asks for a hue, it's get a phue

#3 from the minute I was born

Waste of metadata in my view. It is features like this that make me shake my head in disappointment. Not trying to start anything here... just stating my opinion...

[kinda surprised you are so happy about it though...]

hey Daniel,

hey I think overloads waste a LOT more metadata <bg>

The thing to remember is what the class is for. That is look at things in perspective. This is not meant to be of significance at runtime, instead it's something to assist developers when debugging. So if Debug.Print is more natural to a lot of people then more power to them. if it makes it easier for them to switch between Vb6 and VB.NET even more so better. It doesn't mess with the state of anything, it doesn't make any object more unstable or overly complex, and it doesn't even really (or shouldn't) exist in released code anyway, only in Debug builds.

So it's a developer preference thing.

If we want to dictate what that needs to look at, I think we could do a lot better by standardising what people use for naming conventions for private fields first

Seriously, this is empowering people at no expense to others. Let's be happy for those who want to use it (and yes that does include me. After years of WriteLine I'll happily take Print anyday

Bill, I completely agree.

They won't be content until they eat the f'cking lot. I was incensed that after all the publicity and general public opinion that it unjustfiable, they carry on as usual.

Hey Mitch,

Although I'm against the killing whales for food, I do understand that in many apsects these things are cultural. For example, to some killing of cows is sacrilidge. So I think those things need to be sorted otu with a bit of tolerance for difference cultures.. BUT you can't do that if one party is continually F***ING LYING !! And that's waht really pisses me off. Claimign it's for scientific research just reminds me of those sicko "scientists" experimenting on humans during the Hitler years. It's friggin peverse, and the scientific community deserves better than to be associted with such f'ing crackpot lying a'holes...

(hmmm.... looks like I'm still pissed off over this )

I use (6) _camelCasing. I don't see any value in the m_ other than the "other languages don't support" argument, which doesn't affect me. Why? Because all of my fields are private as they should be. You shouldn't have public or protected fields because implementation changes end up being breaking changes, so better to use properties for public and protected items. Fields should always be private. CLS compliance should not be an issue if you stay away from publicly (or protected) identifiers.

Excellent tip, thanks very much Bill !

They seem to have had trouble over at MSN since the change of Blog engines. I let someone know that their comment system was off and they had no idea about it. It seems that his comments system is working, did you let him know via that?
MOlly

His comments are off, but the trackback seemed to work. So I think it might be the skin he has. And yeh, that "upgrade" to community server from .Text broke a lot of things, and still is unfixed. The one I hate the most is comments appearing as "anonymous" even thoguh they weren't.

Thanks Bill - Subscribed. I'm looking into the the comments thing.

Hey Andrew,

Cool. Good to see the pingback worked the trick

I haven't seen this yet, but you should also check out:
Koyaanisqatsi, Powaqqatsi and Naqoyqatsi. You may like them. They're quite good.

Jacob

Hi Bill:
First, thanks for letting me know the chats listed in my blog are useful. However, I do have to take some ownership on the chat RSS feeds you commented on above. My team owns these and so I need to take some of the heat. I totally agree with you on needing them to provide more information. This is something we are working on and I just sent an email to the person managing this project letting him know.

If you want to stay up to date on the status of the RSS feeds or provide additional feedback, drop my an email: janac@microsoft.com anytime.
Thanks
Jana Carter
Product Manager
Microsoft

Hi, Bill and Jana--

Date and time we definitely need to provide in the RSS feed; we'll also have to evaluate including the links to the chat room. The problem there is that typically chat rooms are used for multiple chats, and if users click on the link to the chat room, they may be taken to a chat on a different topic, and so suffer a confusing experience.

Thanks for the feedback; we understand we have a long ways to go before the RSS experience on Microsoft.com is what it needs to be for customers: easy to find, useful, and generally consistent. Know that we're working on it and are taking your comments to heart.

Dave Morehouse
Product Manager
Microsoft

Hey Jana and Dave,

Wow... I'm impressed with the way you guys both stepped up to the plate !!

Thankyou !!

Thanks Jacob. I'm not sure about Naqoyqatsi, that sounds a bit too depressing, but the others sound interesting, especially Koyaanisqatsi. The later sounds a lot like Baraka. The thing I liked about Baraka is it "balanced" the content which really leaves it up to the viewer how to interpret rather than leading them down one particular view of ilfe

I don't know why comments aren't working. I have them turned on, so they should work. I'll have to figure out what's going on. Sorry about that.

Hey Rob,

I'd double check to make sure you have comments set to on for the individual post as well as your blog.

For example :
http://blogs.msdn.com/robertco/comments/421236.aspx

should open up your comments page, but instead it redirects to your archive page:
http://blogs.msdn.com/robertco/archive/2005/05/23/421236.aspx

So that makes me think that for some reason the "system" thinks comments is off. I checked Jay roxes is working fine as he is using the same skin as you are. So I would log on via the web to your side, admin it and double check . Might be the blogging sw you are using ?

Yeah, just when we thought the versioning couldn't get any weirder!

I had some major problems when trying to install this on top of Visual C# Express Edition Beta 2 - The new project types for Avalon and Indigo do not appear when creating a new project, with no errors raised during the installation process.

Mine of course ;-)

No, mine!!

Actually, mine is crap. For VB, the best stop has always either been Bill's or Paul Vick's. I thought I'd hit a goldmine when I discovered vbcity, but it's not very VB nowadays.

Of course you both failed to write down your rss feed urls in your comments
<bG>

Geoff: yeh agree on VBCity. I would delete it from my feeds except I am still waiting on Mike McIntyre to update his blog about migrating to VB.NET. But yeh there is little VB there

"Funny how there's one rule for Microsoft's source code and yet another for their customers."

Ya... sure is. Difference is: One COSTS them money, the other MAKES them money!

I figured I didn't need to, since my name links to my blog itself

Sorry for asking a dumb question, but what does DirectCast do?

Yes i just tried installing Avalon Beta 1 RC on top of VS 2005 C# Express and got no errors, but also no results. There is no way to make/open an Avalon project. The XAML can of course be viewed since it's just XML, but it can't compile.

Gosh, just finished a consulting gig where (in at least one app) there are (by coding standards) form/module/class-level declarations like:
Private miptrItemReceiptFrm As frmSomething
Private mintChocolate As Integer
AND method-level declarations of similar ilk
Dim liptrItemReceiptFrm As frmSomething
Dim lintChocolate As Integer
AND global constants like:
gstrCOLUMN_ITEM_RECEIVE_SERIAL_NBR
AND maybe best of all, parameters like:
ByRef aINOUTstrDataString As String
ByRef aINiptrSomething As Object
ByRef aINstrStringValue As String

...I'm worn out from all the typing and mental gymnastics. Ya, the "iptr" prefix on various objects was a C guy trying reform VB (circa 2001), and the parameter names were an attempt to distinguish ByRef/ByVal parameters, though I never did figure out what the "a" had to do with it.).

I especially like the "mint" and "lint" prefixes -- you can get a coder doubled-up in laughter with a little creative variable naming. All-cap constants ARE FUN, TOO.

Seriously: For underlying class variables of properties, I use "x_sPropertyString As String" just to make sure I don't try doing a direct assignment to the property variable (something I see often as a consultant and get good money for fixing) instead of going thru the property itself.

Until vbScipt/ASP-Classic are outa my life, I'll keep using simple hungarian -- like [m][s, i, l, b, o]VariableName. It keeps my coding life simple and minimizes (unexpected) type-coercion screwups.

Lets all agree to dump "_" except in extreme cases (the "Matrix" gets it's energy from developers pressing the "Shift" + "-" keys and from MS-Solitare mouse-clicks).

[For clients, I write it my way and then do RegX manipulations to conform to their individualized styles.]

And, ya, I use [p]ParamName for ByVal parameters and [pref]ParamName for byRef parameters (in the rare cases I'm forced to use them). Go, Geoff...

Showing my age and heritage, I use "fVariable" for singles and doubles -- otherwise know as 'floats".

Last but not least, (I like my code's references to seem obvious) I like the clarity of writing:
Me.PropertyValue = "abc"
oClass.PropertyValue = "abc"
because
PropertyValue = "abc"
looks hinky (lacks intuitive clarity), in the sense that it has no context if you're using some sort of prefix notation for variables. (Sorry, Geoff. Sorry, Compiler/DeReferencer.)

It (on-the-surface) would be good if there was an obvious way to distinguish between a class's methods and properties, as in:
SomeClass.Methods.DoThis(parameter)
SomeClass.Properties.IsDirty = False
T'would be nice in the IDE, too, to separate methods from properties (more than just the method/property icons).

why we go for a custom events in java?

I don't see GoTo's as evil, so long as you have a damn good reason for using them.

And I've tried. Really tried. Really hard.

I can't come up with anything that runs faster.

I'm still trying tho

Hey Geoff,

I think you've hit the nail on the head ... it's not that they are evil, more it's the way that we use them that can be. In complicated code, or large methods I think GoTo should be avoided. With complicated code they can actually make it hard to restructure, and can easily lend themselves to spaghetti style code. In large methods, they tend to be used instead of breaking the method out into smaller methods. But in this kind of code where the method is pretty simple, unlikely to need major changes so I am thinking that maybe goto is not so bad in this case. What I found interesting though was my instinct was to avoid using GoTo, rather use a flag, or look at even using While True blocks etc.

BTW: I'm glad you haven't been able to optimize it Makes me feel happier about that choice.

OT: Definition for Legacy Code

I'm going to explain my thoughts first, then show the code since I wrote it without really knowing VB.NET and without a compiler:

To me the first problem with your function is the duplication of code where you check if the first character is whitespace and where you check if the second character is whitespace. If you pull that out into its own function that simplies the code and removes the need for the goto:

Please excuse any obvious typos/mistakes.

Public Function IsWhitespaceCharacter(ByVal charToCheck As Char, ByVal ParamArray whitespaceChars() As Char) As Boolean
Dim whitespaceUbound As Int32 = whitespaceChars.Length - 1
For j As Int32 = 0 To whitespaceUbound
If charToCheck = whitespaceChars(j) Then
Return True
End If
Next
Return False
End Function


Public Function IsWhitespaceOnly(ByVal stringToCheck As String, ByVal ParamArray whitespaceChars() As Char) As Boolean
Dim length As Int32 = stringToCheck.Length
Dim middle As Int32 = length \ 2
Dim first As Int32 = middle
Dim second As Int32 = middle + 1

If whitespaceChars Is Nothing OrElse whitespaceChars.Length = 0 Then
whitespaceChars = New Char() {" "c, ChrW(&H3000)}
End If

For i As Int32 = 0 To middle

If first >= 0 Then
If Not IsWhitespaceCharacter(stringToCheck.Chars(first), whitespaceChars) Return False;
first -= 1
End If

If second < length Then
If Not IsWhitespaceCharacter(stringToCheck.Chars(second), whitespaceChars) Return False;
second += 1
End If

Next

Return True ' I believe a empty string is considered whitespace only, correct as necessary.

End Function

Hey Matthew,

The code you posted looks pretty good to me (I haven't tested it). The problems I see with it though are increased call stack usage, and the ubbound for the character array loop is recalculated each time the IsWhitespaceCharacter function is called. So my guess is it would result in a performance penalty.

The ubound recalculated bothered me too -- I almost passed it in as an extra parameter. But I thought their might be some use for the IsWhitespaceCharacter as a standalone function, so I didn't. If you knew it was internal only, then I'd add it as a parameter at the small cost of increased coupling between the two.

The call stack usage doesn't bother me too much -- mainly because I think there is a decent chance it would get inlined. I'd love if someone who has a VB.NET compiler could do a quick perf analysis of the two.

I can't right now, but I'll run some tests later tonight and post back here. It sounds like Geoff may have run some tests... I actually haven't run any yet.

BTW: I actually think my base assumption of starting searching in the middle is probably not a good assumption. I tend to find strings generally have leading whitespace rather than trailing whitespace, but it would depend on usage. Take for exampel reading from a text file line by line, if the lines actually have the carriage returns and or line feeds on the and of them, and they are considered whitespace, the optimal may be searching from "near" the end but not at the end.

Bill, no, i think your right in starting from the middle.

Remember, the way the mothod is structured is to find one single non-whitespace char ASAP, and bail out immediately if it does. If whitespace mostly appears on the left or right, it doesn't matter. most of the time (and we can only talk probabilities here) a non-whitespace char is highly likely to be somewhere near the middle of the string, or not too far away from there.

As for tests, yeah, I have been. I'll run through Matthew code when I get a chance.

Hey Geoff,

I think you're wrong about me being right. It's probably not a bad assumption. I think when I look at strings, there's a reasonable probability they will start with whitespace. Chances of them having more than one consequtive whitespace char in the middle is low, but only if the ratio of test to whitespace is generally large. One example that comes to mind is say parsing an indented XML file. LEt's assume they use "space" or similar ,not tabs. There the likelihood of the ratio of whitespace to non-whitespace on any given line is likely to be > 1:1,( depending on the depth of the object model and the type of xml output used) in many cases. So for those lines, the ideal spot to start would be near the end. Definetly not at the start, not so the middle, and maybe not the end. We could optimise this better is we knew the whitespace char list was optimised accordingly. That is if it checks for cr's and lf' early in the list, then it's only going to be one or two comparisons for the ending chars, rather than the 20 ro so comparisons it can take ot declare a character as not being whitespace. Obviously the relative efficeincy depends a lot on the whitespace shar list though, whether cr and lf are considered to be whitespace, whether the whitespace lsit is large etc. But If I take the two standard lsits, VB's 2 char one, and String's 21 char one, then I think searching from the end in will genrally be the most efficient, as we can reduce the complexity of your code, and with the VB char set, as cr or lf is considered non whitespace, and with the string char set the cr and lf are pretty early on in the list, so the cost of those likely couple of comparisons shoudl be trivial compared to the cost of settign up to say work from the middle out.

Okay, maybe, maybe not... it's a theory anyway

binary search perhaps?

Here's an interesting one for you. based on a few sample strings of random gumpf, this one seemd to deal better with longer strings...

Protected Overrides Function IsWhitespaceOnly(ByVal stringToCheck As String, ByVal ParamArray whitespaceChars() As Char) As Boolean
Dim length As Int32 = stringToCheck.Length
Dim middle As Int32 = length \ 2
Dim quarter As Int32 = middle \ 2
Dim first As Int32 = middle
Dim second As Int32 = middle + 1

Dim chr As Char

If whitespaceChars Is Nothing OrElse whitespaceChars.Length = 0 Then
whitespaceChars = New Char() {" "c, ChrW(&H3000)}
End If

Dim whitespaceUbound As Int32 = whitespaceChars.Length - 1

'check first char
chr = stringToCheck.Chars(0)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo firstpart
End If
Next
Return False
firstpart:
If length = 1 Then Return True

'check last char
chr = stringToCheck.Chars(length - 1)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo secondpart
End If
Next
Return False
secondpart:
If length = 2 Then Return True

'check middle char
chr = stringToCheck.Chars(middle)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo thirdpart
End If
Next
Return False
thirdpart:
If length = 3 Then Return True

'check first quarter char
chr = stringToCheck.Chars(quarter)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo sixthpart
End If
Next
Return False
sixthpart:

'check third quarter char
chr = stringToCheck.Chars(middle + quarter)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo seventhpart
End If
Next
Return False
seventhpart:

'check first quarter range backwards
For i As Int32 = quarter - 1 To 1 Step -1
chr = stringToCheck.Chars(i)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo eightpart
End If
Next
Return False
eightpart:
Next

'check last quarter range forwards
For i As Int32 = middle + quarter + 1 To length - 2
chr = stringToCheck.Chars(i)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo ninepart
End If
Next
Return False
ninepart:
Next

'check second quarter range forwards
For i As Int32 = quarter + 1 To middle - 1
chr = stringToCheck.Chars(i)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo fourthpart
End If
Next
Return False
fourthpart:
Next

'check third quarter range backwards
For i As Int32 = middle + quarter - 1 To middle + 1 Step -1
chr = stringToCheck.Chars(i)
For j As Int32 = 0 To whitespaceUbound
If chr = whitespaceChars(j) Then
GoTo fifthpart
End If
Next
Return False
fifthpart:
Next

Return True

End Function

Neither Definitely not C# and probably not VB

I don't really see a good reason to clear a variable halfway through a code block, especially if it's a value type. If it's a value type, it's impossible to truly "clear" it anyway. It's either unassigned or it has a value. I think you'll find default(T) returns a zero whitewash on the structure, which if you are dealing with an <int>, means you'll get a zero back.

I see default(T) more as a nicer way to pass back an empty return value - be it a null ref for a reference type or a zero whitewash for a value type.

That all being said, default is a horrible keyword to use, especially since we c#ers are already using it in switch statements.

I thought I'd talk a little bit more about a post from a few days ago, String Performance Over Different...

I thought I'd talk a little bit more about a post from a few days ago, String Performance Over Different...

How well it works is another issue altogehter ;-)

Geoff .... uhm... I'm speechless

22KB, not 22MB.

Char.IsWhitespace(myChar) ...

This uses a Select Case statement. Returns true if the character is
ChrW(9)
ChrW(10)
ChrW(11)
ChrW(12)
ChrW(13)
" "

Or if the unicode category is 11,12,13 ..

Probably not the most efficient, but it's in there.

Speechless huh?

So tell me...NOW are gotos evil? *grin* I think all it really proves is that you have to be willing to wear the penalties of anything other than walking the entire string from one end to the other. Statisitical analysis (which is what i was trying to emulate while not really doing it) might allow us to find in advance more _likely_ locations of non-whitespace chars, but it is it really worth the penalty of either slower or harder to maintain code?

hey Jacob,

Actually that is probalby very efficient. I think I might switch to that not only becuase of that, but also it adds some consistency. Although one has to ask why Vb's Trim, and String.Trim don't use that ?? I wonder if they did some benchmarks on calling CharacterInfo.IsWhitespace(char) or not ? Then again maybe it's just because String.Trim is designed to do other things. I think that may be it. I haven't tested, but I think the CharacterInfo.Iswhitespace(char) is probalby the better choice... well it's my bet at this moment anyway

Hey Geoff,

uhm... speechless.... totally ...

<slap><slap> Ah, no I'm better.... yes, you have convinced me, GoTo is evil. give it an inch and someone will take it for a mile <bg>

i'm going for the easier to maintain code. I know the following is different code, but simple is good, you've convinced me. (well unless you tell me the perf suxs that is)


Public Function IsWhitespace(ByVal stringToCheck As String) As Boolean
IsWhitespace = True
Dim i As Int32

If stringToCheck Is Nothing OrElse stringToCheck.Length = 0 Then
Return True
End If

i = stringToCheck.Length
While IsWhitespace = True And i > 0
i -= 1
IsWhitespace = Char.IsWhiteSpace(stringToCheck.Chars(i))
End While

Return IsWhitespace

End Function

With respect to the statistical analysis as to where one should start the inquiry, if you're dealing with a random string, then the odds are highly in your favor that any character you start with will be non-whitespace. Though, no character has any more likelihood than any other.

However, if you have some context about the string and its contents (i.e. it's not random) then some analysis could be performed to increase the likelihood. Though, I'd be willing to bet that the first or last character would be the most fruitful.

Hey Bill, I haven't done any testing with this, but in my head this is a little more efficient:

Public Function IsWhitespace(ByVal stringToCheck As String) As Boolean
IsWhitespace = True
Dim i As Int32

If Not stringToCheck is Nothing Then

i = stringToCheck.Length -1
Do

IsWhitespace = Char.IsWhiteSpace(stringToCheck.Chars(i))
i-=1

Loop Until Not IsWhitespace OrElse i < 0

End If

Return IsWhitespace
End Function

Hey Jacob,

On the code, you need to test for a zero length string, or set up your loop such that it isn't entered in that case. Looking at mine, I could drop the explicit test for a zero length string and it should work okay, which would be about the same in code. I would do an early exit rather than nest the hwile loop... I just prefer them.... I doubt there is any performance difference between the two on that count.


The statistical analysis of strings, I think given the predonimance of "code", html and xml, leading whitespace is very common. Given the parsing on a line by line basis is also common, then carriage returns and line feeds can be expected to be very common at the end of a string. Ideally we want to find a non whitespace character as soon as possible, so looking at the ends is actually the worst place to start. My guess is, that two or three characters in from the end is the most likely place, BUT considering we have to test all the characters if we find the string is purely whitespace, then startign from other than the ends adds extra complexity.

anyway, if it's raining on Sunday and I get bored on Sunday, what I'll do is recursively parse all plain text files in( my documents or something like that) and cache all the strings on a line by line basis, and then test some code with them

oh btw: did you notice I used And, not AndAlso. Given that during the loop you do have to check both (only on exit of the loop can you short circuit), And is actually more efficient than the conditional branching AndAlso

Yup, my fault on the zero length string. I saw that it could be taken out of yours, so I left it out of mine.

re: Stats
Well, what you're talking about is the context of that which you are parsing. Parsing code/html/xml makes sense on that front to start in the middle and work your way out to the ends. Now, assume that you have some generic text file, you have no knowledge whatsoever of its contents. You randomly take a line from that file and you randomly take a contiguous sequence of characters from that line. Any character in that sequence is as likely to be (non)whitespace as any other. That's the point I was trying to make.


Oh, and that's an interesting note on the short-circuit. I'll have to keep that in mind. I have reams of code that looks like:

Do Until blnFound OrElse i = Count
..
Loop


What's up with your human proof, btw? It never works the first time for me.

My understanding is that all versions of SQL2k5 will all allow the reporting engine to run and that all versions except SQL Express will come with the report builder. So, the runtime on any version and the dev interface on everything except express.

Thanks Andrew. That's still pretty cool as you could have the "MSDE" 2005 and do client side reporting.

Hey Jacob,

At least on developer's machines, "text" is more likely to have leading whitespace. As office moves to XML this is going to spread. For use input, leading whitespace is rere (usually only a sinlge space), but trailing whitespace can be common as it is visually not as obvious. Even then the usual I see is people cut and pasting and getitng on extra trailing whitespace.

So i get what you mean about it any character can pobbily be whitespace or not, but I think there is a definetly a probability that the start is less likely than the end for non whitespace. It's like the alphabet.. although any letter could be any legal char, we usually find a higher percentage of a and e, s and t compared to q or z etc. So if you had to test for each different letter, you'd be better to test for say s and t earlier on, than alphabetically.

Re: short circuited versus non, the simple rule I use is if the second expression is not dependant on the first to be legal (eg testing for null first) then bitwise operators can be more performant than branching ones. The toehr factors are the cost of evaluating the second expression. But if you expect that to be evaluated the majority of the time anyway then that cost is the same for both.


As ot the CAPTCHA, yeh don't even try first time. Apparently it has a rediculous short time out. (sorry, but not my doing)

Why not use something better?
Like ProFont For Windows?
http://www.tobias-jung.de/seekingprofont/

Hey Ayende,

Thanks for the link, but honestly, those fonts suck in comparison to Courier New. And that's the crux of the problem, it's hard to find a good TTF that's mono spaced. I've looked before, and was disappointed like I was this time. Courier New really is a lovely font, scales well, highly readable etc, except those 3 letter, 1, l and 0.

Puppy linux boot, portable browser and email client... oh yeah and files

It blowsmy mine how many newbie programmers use that "support a XX year old legacy app" mantra.

almost ALL telephone companies, airlines and other LARGE businesses are running on apps that are 6-30 years old and YES support is still available. Hell many critical systems are running on older sun servers with an OS from 10+ years ago.

Fools complain about supportting an "old" app. This may be true for the consumer toy grade applications you can buy at best buy or for home use, but enterprise and commercial apps are expected to run for a very long time and be supported for a very, very long time. when your customer pay's you $35,000.00 a year in maintaince contracts you can not take a "snotty" attitude with them, look down your nose at them and say "upgrade" if they want to stay with version 1.0 because it works then you support it or tell that customer that your competition is more willing to help them.

I can not count how many time the new "improved .NET" version that was fast-tracked out the door was 10 times worse than the old VB6 version that has worked fine over the past 3 years.

That is why any .NET upgrades from our vendors here require a 12 month testing process or submit to a sourcecode review before we accept the upgrade.

I agree with you about Overloading being most frequently used to simulate 'real' optional parameters - at the cost of more lines of code and more opportunity for mistakes (by coding an implementation in more than one overload instead of chaining). Overloading is a valuable technique with many uses, one of which is a clumsy implementation of optional parameters in those languages that don't have them...
For some reason however, optional parameters are often dismissed as somehow less 'object oriented' than overloading - maybe because VB provides them while 'real' languages like C# and Java don't?

I'm not so sure about returning different types from overloaded methods though - while I agree that it makes sense in some cases, it has great potential for confusion if used unwisely. Our coding standards have always disallowed this - maybe they are too strict, although no-one has complained so far...

Hey Kevin,

I think you're right on both counts

The need for returning different types is rare.

As to other languages nto getting the big picture, yes sadly that is true. It's kind of funy to hear a lot of them talk about dynamic languages as if it's somethign new, when it's something VB always has had. Let's hope that one day languages like C# will finally catch up there, then the only hurdle will be to educate the users of that language

Sweet dude. Very very funny.

Damn C# hacks. Yet again it goes to show, it's not the language, it's what you do with it

Thanks for the anecdot.

Benjamin

*laughs* very cool man, very cool.

You make some good points.

I'm going to have to think long and hard about this. My other daughter is almost 4. I've been refraining from teaching her to code because of the language issue - I hadn't even considered using C# as a temp substitute!

Possibly it would do more harm than good - we shall see how it goes over time.

congrats man !!!

I've been writing code for about 28 years now. First in FORTRAN (remember it?), then C and MASM on the early PC's. Wrote a few obscure languages like Waterloo PORT (C-Like) for awhile.

I really did enjoy writing in C for many years. I wrote a lot of good code in it, particularly some of the device-level stuff I did. Heck, I even did some applications-level work with it.

More recently, though (about 8 years ago) I discovered VB. At first I thought "you got to be kidding" - back to BASIC? However, it was the availability of VB (version 3 originally) that got me into Windows programming in the first place.

Even VB.Net with all the changes is, IMHO, a much better choice than C# is. I can think about the problem at hand with it far better than I can with C#'s obscure dialect. Someone said that VB is more verbose than C#. Maybe --- but it ain't by much. Further - I HATE the case-sensitive nature of C#. Why the heck do we need X and x? Fubar and FuBaR?

In the shop I'm in, I'm in the minority. All the "hot" new developers want to program in C# because that's what "the big boys" say is the thing to do. I never listened to the "big boys" ... I AM a big boy. I'm more interested in solving the problem at hand with a tool that doesn't require that I be an expert in language features that shouldn't concern me. At my age my brain would rather concentrate on the solution than on struggling with the tool. VB makes that possible.

C# ... OK, it's cool. Use it. As for me, I'd rather turn the key to start my car than to spend time under the hood figuring out how the starter works! I'll already be at my destination while you are still figuring out how to start your car!

-CB

This is just the information I needed. Installing MS Java VM off the Visual Studio CD when you run a complete up-to-date Windows XP with Sun's Java is quite useless and annoying.

Now I can just go on installing it without the Java VM, thank you very much!

Thanks for the great laugh Bill

Wait, wait, wait. Maybe I was sick that day in class, but why again are Shared methods to be avoided? Isn't it the other way around? i.e., defining a derived class where the Shared methods of the base class would be dangerous to call?

Can't vote until someone else verifies it.

Validated (which opened the voting) and voted.

Happy now?

Thanks Geoff

Michael, voting is open !!

You're so right dude. Really really right. If they said it was bill's blog, they'd be hired

The answer you give there is a whole lot more than I was hoping to hear. I really just wanted people to show that they had even a slight inkling. Of the people interviewed so far, one had heard of them but didn't know what they were, the others hadn't even heard of them.

As for my boring description of it, tough I was trying to give a fair technical summary for the googlers I'd seen come in, not keep you awake. However, do you mind if i copy and paste your summary into my post as well (attributed, of course) for those weirdass googlers that _don't_ want the technical version?

Will these new features announceable after PDC?

vb is nice don't get me wrong. i'm a firm believer in using the right tool for the right job. vb is nice because so many people know how to use it (even though many people don't take advantage of it's full potential).

with that said, i must agree with the above comment, c# is MUCH easier to read than VB. the reason is because c# "usually" uses symbols rather than words, leaving the words to things like variables and function names.

when i look at a page of vb code, it looks more like a dictionary with words scattered all over the page. i'm sure the code was easy to write, but when a developer who didn't write the code has to come along later and debug it, it can really be a pain in the arse. i would much rather debug a c# application as i can almost instantly see what the programmer was trying to do without having to siff through a bunch of words.

finally, the biggest advantage c# will always have over vb is that it's almost identical to the languages of java, java script, and c. if you master 1 you will be well rehearsed in the other languages. if programing languages were instruments, the language syntax of c would be the piano.

again, vb has it's place too and we use it all the time. but when it comes to programing low level or internet intensive application, i always use c# and for good reason.

I have been programming for over 10 years now. I started in VB and I'm still using VB today. However, I must admit, I don't share your belief that VB will dominate the world. At 1 time I shared that belief... that is until the release of a new language called C#.

C# has so many advantages over VB it would take a novel to show them all. I will cover some of them in this post. I'm not going to list things that C# can do that VB can't... or things that VB can do that C# can't... because it is irrelevant to what I'm talking about. The simple fact is, both languages can do virtually the same thing and they both have their place in the programming world. I'm a firm believer in the right tool for the right job and I personally use VB just as much as I use C#.

I realize some of you are probably very good at writing VB code that is set up nicely and easy to read and that your programs flow naturally and logically. The sad fact, however, is that most VB programmers are not very good at it. In the real world, there are a lot of sloppy VB programmers because for years these programmers had to deal with a lousy programming language that taught them bad habits. Granted, I have seen some pretty poorly built applications in C#, but not even close the messes I have had to deal with in VB. Put VB into the wrong hands and you will truly get a mess that can be very difficult to clean up later, usually by programmers who didn't make the original mess.

C# is much more elegant language because if it's use of symbols rather than words. I realize that C# uses keywords just as VB, but the C# language takes advantage of symbols in many cases, making the code much easier to read and understand. To demonstrate this... take your best VB programmer and your best C# programmer. Give them the same project to build. When the project is complete, have another VB and C# programmer look at the code and explain it... which is a VERY real situation in the real world of professional programming. I can guarantee 9 out of 10 times the C# will be much easier to read, explain, and debug if necessary. Even after 10 years of VB and just 2 years of C#, I can read C# twice as fast and twice as clear. In the real world... chances are... the person building that VB application won't be doing so elegantly as your best VB programmer.

C# has another advantage over VB that it will always have. The syntax and style of C# is so similar to Java, JavaScript, and C that to know 1 is to be well rehearsed in rest. Granted, Java and C or C++ have different rules to follow, but they are similar enough to be well rehearsed. Ever written an ASP.NET web application? It is so much easier to maneuver between C# and JavaScript than from VB to JavaScript. I have done both several times, and I'm not knocking VB nor am I saying it can't be done or that some of you aren't good at it. I'm sure many of you are. I'm only pointing out that it's much easier working between C# and JS than VB and JS. I also realize that some of you use VB script... and in those cases, I'm sure it's much easier using VB to VB Script than it is from C# to VB Script. But in the real world dealing with many browsers, chances are most of you will be using JavaScript.

As I said before, I'm a firm believer in using the right tool for the right job. In many situations VB will be the desired language and will have many advantages over C#. I use VB.NET everyday in my job and there are many things that I love about it. The point of this post is to demonstrate my opinion that I do not believe VB will dominate the world and that I do believe C# is the more elegant language when building low level applications, web applications, or complicated application frameworks. When diving low into the code where the logic is so efficient it becomes extremely complex, I would much rather build and debug it in C# than VB. C# has it's place in the market just as VB and I think both tools will co-exist side by side offering the right tool for the right job for years to come.

Some of the attendees are blogging:
Bill McCarthy - TechEd Oz (Day
0)&nbsp; It's ALL about the shirts...

In the version of Visual Studio.NET 2003, VB.NET has less advantage than C# indeed. Because VB can hardly do things that C# can't not, with no less codes. But in the future, VB will create it's own world -- dynamic and clarity, easy to use and easy to learn. I believe in the VB Team. They will create the best programming language.

I agree, in the future VB will create it's own world but along side C# in the process... because Microsoft's strategy is to develop the language together on top of the same framework.

I must caution, however, that VB will always have a weakness... and that is that it's a proprietary programming language. The C-style of programming language is universal and is more understood by the masses than VB.

VB will always have it's place and I think we can all agree it has FINALLY matured into a real language. I look forward to see where it goes and have enjoyed watching it mature.

Baby Jim,

Where do I start ? Really, not only do you not provide a URL or a real name, but you base your argument on nothing but your own bias, meanwhile while totally missing the point of the original post. Stop and think a bit Baby Jim, and watch the video. "Listen" to what is said.

I know you C# guys are getting all upset over this, and that's good, because it may mean that C# will evolve too to catch up to VB, and in turn VB will respond. That kind of competition is good for all of us

But to claim that C# is more elegant or more easily debugged is complete and utter nonsense. C# is more terse, it is not more elegant. A HUGE penalty for that terseness is the lack of declarative programming.. a method becomes less descriptive, no longer indicating it's relationship as clearly as it could.

Your claim about c# be better suited for low level classes is absurd. The only advantage C# has there is unsafe code, and really, if you use unsafe code in any project I'm working on, be prepared to be shown the door in no uncertain manner You loose all ability to sandbox the code, and it really is an indication of using the WRONG language for the task at hand.

Another example along the same lines is case sensitivity. Once again, if you use that around me, you sure better have those walking shoes on. It's another example of a completely useless construct in C#, something which you should be able to turn off. And this is part of the BIG problem with C#. It takes on all the worse of C style languages. It's a pity Anders didn't really innovate, instead he just continued the mistakes of the past..

Oh, did I mention redundant break statements in switch blocks ?

Let's not forget that it's the C languages that are re-known for having "obfuscated" code writing competitions. No, they aren't talking about obfuscating the compiled code, just making the written code as cryptic as possible. Sadly this is the legacy C# took on board.

So as far as readability goes, as far as code maintenance goes, C# is in FACT miles behind. Look at how the hoops C# programmers go through just to parse a string can represent a numeric value for example. Too much code written for basic functionality, meanwhile the language focuses on the obscure, the unsafe and the undecipherable. VB on the other hand leads the way in productivity, just as it always has.

And that, Baby Jim, is the key issue here. In Orcas, watch as VB once again leads the way in productivity when working with data. Read it, watch it, and weep

Oh, and as to the quality of C# programmers, no I am sorry most too many of them are very shallow impersonators IMO. I call them the Elvis impersonators (insiders joke ) Interestingly, you claim you have programmed in VB for 10 years, so doesn't that make you one of those you say write bad code, have learnt bad habits ? And there you are using those bad habits in C#. The fact it's like JScript seems to have also attracted those script kiddies from the web. unfortunately I see this all too often with code which I can only classify as "written by the clueless".

The reality is, any VB programmer can learn and use C# in less than a matter of days.... there really is not that huge a difference, just a lot of missing functionality in C#. Within days they will be trained like a keyboard monkey to type ; after each statement, to hit CTRL+B to do what should have been a background build. But their code won't be any different. Sadly for C#, the reason many choose C# is because they believe they can claim their code is somehow better... which is much what your claim was.

Oh, and as to debugging, let's be 100% clear here Jim, VB eliminates more problems at design time than C# does simply because it has a background compiler. When writing web applications, yes I do use JScript, and find that having client and server side languages different helps in readability. It also minimises the number of mistakes that a lot of people make thinking JScript is the same as C#, which it clearly is NOT. The familiarity of syntax is more problem causing than anything else.

But Jim, all these things are really beside the point. Here I am just debunking your nonsense rant. I was going to delete it, but it's so typical of the nonsense a handful of C# fanatics espew, I thought I'd leave it just to show how sadly desperate and scared you guys are. You can't argue about the cool things VB is getting in Orcas, so you start with your nonsense line about VB programmers somehow writing worse code. Yet that's exactly who you are. The difference being you switched to C#, just like all the worst of the VB programmers have.

But Jim, don't totally despair. VB is more powerful and the future is clearly VB will lead the way. and Jim, when you get over your inferiority complex, I'm sure you'll see the light and want to join us

??? ??&nbsp;? ????.
GAC? ?? ?????. .NET framework?? assembly? global scope? ?? ???? ? ?????. ??? ??...

Bill McCarthy poses an interesting question about software updates and limited users. The gist is, where...

Just saw this. I'm afraid you're right, (4) is the only decent option. Which I hate, since it likely means that over time systems will be cluttered with services (which mine already are, by far).

Other comments:
(1) Could cause a lot of duplication as well, if you used multiple applications from the bank. But this makes me wonder... Is what they are putting in the shared directory really something that should be shared? Are you using multiple bank applications?
(2) You're right. I don't think I'd even consider this option, since it adds a layer of complexity to the app that I doubt is justified.
(3) No!!!!

Maybe this calls for a shared service that an app could enroll in for updates? InstallShield has something that sounds like this, but I don't know enough about it to know if it's a feasible option.

Have you seen this: Snippy - Visual Studio Code Snippet Editor

http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b0813ae7-466a-43c2-b2ad-f87e4ee6bc39


You're gonna have to crush them like a bug Bill!

cheers
lb