Some thoughts on VB9

My thoughts on this....

http://msdn.microsoft.com/vbasic/Fut...b9overview.asp

My thoughts:

1. Regarding Implicit types, I don't use type declaration for the benefits
of performance. It's for the benefit of clarity of purpose when reading
code. The first thing I do with neophyte developers is turn Option Strict
On to help them understand why they do what they do. With this, I can't
stop people from writing garbly gook.
2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
and there could be real beneifts to it.
3. Nullable types. I think this is a really good idea if it integrates
with SQL Server well.
4. I think I will like the Query Comprehension features, because I think it
makes understanding certain intents clearer.
5. "Because extension methods are intended mostly for library designers,
Visual Basic does not offer direct language syntax support for declaring
them." - This kind of comment has always bugged me, and probably rubs all VB
developers who are serious about the language wrong. It reveals a "red
headed stepchild" attitude toward the language, as if C# is the "real
thing". If you really talked to VB developers in the field, I would imagine
what they want more than anything is just a one to one feature set with C#.
But this aside, I don't really like the extension concept because it feels
too much like multiple inheritance and might have similar issues associated
with it in terms of maintainability of code.
6. Nested functions I can see real benefits to, but it does make VB feel
quite a bit like ML. But this could really go along way to making some
things really easy to understand.
7. Relaxed Delgates. Dislike this for the same reason I don't like
implicit type conversion.
8. Dynamic interfaces. Ditto.
9. Dynamic identifiers. More of the same.

I guess my conclusion is I like some, but overall because of the
destruction of clear typing, I have to give it a thumbs down. These sorts
of things should be done sparingly in clear code, so sparingly that
programmers should have to understand the intricacies of reflection before
they are given a license to do them. I feel VB9 legislates bad habits and
practices we gave up prior to VB.NET.

My gut tells me that this is really all about upgrading the tremendous share
of VB5 and VB6 users to .NET who so far not made the transition. I imagine
upgrading a VB6 application to VB9 will be much simpler than any other .NET
upgrade prior. But for those of us who have made the transition, I think
the lack of typing is bad policy. It may simply be time for me to byte the
bullet on curlies and semicolons

--
Justin Weinberg
MCAD/MCSD .NET

>> this is really all about upgrading the tremendous share of VB5 and VB6
users to .NET
Not to mention all the DotNet 2001, 2003, 2005 users who have already dished
out thousands of $$$ trying to keep up with MS's "Developers!, Developers!,
Developers!" non-backwards-compatible treadmill.

Bob Lehmann

"Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl...[color=blue]
> My thoughts on this....
>
>[/color]
http://msdn.microsoft.com/vbasic/Fut...b9overview.asp[color=blue]
>
>
> My thoughts:
>
> 1. Regarding Implicit types, I don't use type declaration for the[/color]
benefits[color=blue]
> of performance. It's for the benefit of clarity of purpose when reading
> code. The first thing I do with neophyte developers is turn Option Strict
> On to help them understand why they do what they do. With this, I can't
> stop people from writing garbly gook.
> 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
> and there could be real beneifts to it.
> 3. Nullable types. I think this is a really good idea if it integrates
> with SQL Server well.
> 4. I think I will like the Query Comprehension features, because I think[/color]
it[color=blue]
> makes understanding certain intents clearer.
> 5. "Because extension methods are intended mostly for library designers,
> Visual Basic does not offer direct language syntax support for declaring
> them." - This kind of comment has always bugged me, and probably rubs all[/color]
VB[color=blue]
> developers who are serious about the language wrong. It reveals a "red
> headed stepchild" attitude toward the language, as if C# is the "real
> thing". If you really talked to VB developers in the field, I would[/color]
imagine[color=blue]
> what they want more than anything is just a one to one feature set with[/color]
C#.[color=blue]
> But this aside, I don't really like the extension concept because it feels
> too much like multiple inheritance and might have similar issues[/color]
associated[color=blue]
> with it in terms of maintainability of code.
> 6. Nested functions I can see real benefits to, but it does make VB[/color]
feel[color=blue]
> quite a bit like ML. But this could really go along way to making some
> things really easy to understand.
> 7. Relaxed Delgates. Dislike this for the same reason I don't like
> implicit type conversion.
> 8. Dynamic interfaces. Ditto.
> 9. Dynamic identifiers. More of the same.
>
> I guess my conclusion is I like some, but overall because of the
> destruction of clear typing, I have to give it a thumbs down. These sorts
> of things should be done sparingly in clear code, so sparingly that
> programmers should have to understand the intricacies of reflection before
> they are given a license to do them. I feel VB9 legislates bad habits and
> practices we gave up prior to VB.NET.
>
> My gut tells me that this is really all about upgrading the tremendous[/color]
share[color=blue]
> of VB5 and VB6 users to .NET who so far not made the transition. I[/color]
imagine[color=blue]
> upgrading a VB6 application to VB9 will be much simpler than any other[/color]
..NET[color=blue]
> upgrade prior. But for those of us who have made the transition, I think
> the lack of typing is bad policy. It may simply be time for me to byte[/color]
the[color=blue]
> bullet on curlies and semicolons
>
> --
> Justin Weinberg
> MCAD/MCSD .NET
>
>[/color]

Seems to me MS is going in the wrong direction.... Accomodating the huge VB6
developing community is something they should have started with, and make
things a bit stricter with every succeeding release.

"Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl...[color=blue]
> My thoughts on this....
>
> http://msdn.microsoft.com/vbasic/Fut...b9overview.asp
>
>
> My thoughts:
>
> 1. Regarding Implicit types, I don't use type declaration for the
> benefits of performance. It's for the benefit of clarity of purpose when
> reading code. The first thing I do with neophyte developers is turn
> Option Strict On to help them understand why they do what they do. With
> this, I can't stop people from writing garbly gook.
> 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
> and there could be real beneifts to it.
> 3. Nullable types. I think this is a really good idea if it integrates
> with SQL Server well.
> 4. I think I will like the Query Comprehension features, because I think
> it makes understanding certain intents clearer.
> 5. "Because extension methods are intended mostly for library designers,
> Visual Basic does not offer direct language syntax support for declaring
> them." - This kind of comment has always bugged me, and probably rubs all
> VB developers who are serious about the language wrong. It reveals a "red
> headed stepchild" attitude toward the language, as if C# is the "real
> thing". If you really talked to VB developers in the field, I would
> imagine what they want more than anything is just a one to one feature set
> with C#. But this aside, I don't really like the extension concept because
> it feels too much like multiple inheritance and might have similar issues
> associated with it in terms of maintainability of code.
> 6. Nested functions I can see real benefits to, but it does make VB
> feel quite a bit like ML. But this could really go along way to making
> some things really easy to understand.
> 7. Relaxed Delgates. Dislike this for the same reason I don't like
> implicit type conversion.
> 8. Dynamic interfaces. Ditto.
> 9. Dynamic identifiers. More of the same.
>
> I guess my conclusion is I like some, but overall because of the
> destruction of clear typing, I have to give it a thumbs down. These sorts
> of things should be done sparingly in clear code, so sparingly that
> programmers should have to understand the intricacies of reflection before
> they are given a license to do them. I feel VB9 legislates bad habits and
> practices we gave up prior to VB.NET.
>
> My gut tells me that this is really all about upgrading the tremendous
> share of VB5 and VB6 users to .NET who so far not made the transition. I
> imagine upgrading a VB6 application to VB9 will be much simpler than any
> other .NET upgrade prior. But for those of us who have made the
> transition, I think the lack of typing is bad policy. It may simply be
> time for me to byte the bullet on curlies and semicolons
>
> --
> Justin Weinberg
> MCAD/MCSD .NET
>[/color]

Very thoughtful analysis, Justin. I'm also against implicit types, and I
propose instead an autocomplete enhancement. The programmer types in
dim xxx = "abc"
and based on the initializer, autocomplete yields
Dim xxx As String = "abc"
In this way, the resulting source code will be understandable months later,
and the programmer has yet another shortcut. Perhaps applicable to anonymous
types as well.

nice idea!

totally agree with justins analysis too!

--guy--

"AMercer" wrote:
[color=blue]
> Very thoughtful analysis, Justin. I'm also against implicit types, and I
> propose instead an autocomplete enhancement. The programmer types in
> dim xxx = "abc"
> and based on the initializer, autocomplete yields
> Dim xxx As String = "abc"
> In this way, the resulting source code will be understandable months later,
> and the programmer has yet another shortcut. Perhaps applicable to anonymous
> types as well.
>[/color]

The problem VB has now is that Microsoft is puzzled about all the VB6
developers who haven't upgraded and their solution is starting to be a
slightly desperate "give them whatever they want".

The catch is that developers who haven't upgraded to .NET yet are likely to
be the ones who most love the VB6 "let me forget to type in half the details
and let the compiler sort it out" philosophy.

So the result is that we already have implicit form instances (no, most VB6
developers don't know what that means, but they certainly know that they
don't want to type one line to instantiate a form instance). In VB9 we'll
have implicit variable types (again, most VB6 developers don't know what that
means, but they certainly know that they don't want to have to think about
variable types). I know that there are some intelligent argument for
implicit types, but that is not what is driving the implicit variable types
initiative at Microsoft.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

"Justin Weinberg" wrote:
[color=blue]
> My thoughts on this....
>
> http://msdn.microsoft.com/vbasic/Fut...b9overview.asp
>
>
> My thoughts:
>
> 1. Regarding Implicit types, I don't use type declaration for the benefits
> of performance. It's for the benefit of clarity of purpose when reading
> code. The first thing I do with neophyte developers is turn Option Strict
> On to help them understand why they do what they do. With this, I can't
> stop people from writing garbly gook.
> 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
> and there could be real beneifts to it.
> 3. Nullable types. I think this is a really good idea if it integrates
> with SQL Server well.
> 4. I think I will like the Query Comprehension features, because I think it
> makes understanding certain intents clearer.
> 5. "Because extension methods are intended mostly for library designers,
> Visual Basic does not offer direct language syntax support for declaring
> them." - This kind of comment has always bugged me, and probably rubs all VB
> developers who are serious about the language wrong. It reveals a "red
> headed stepchild" attitude toward the language, as if C# is the "real
> thing". If you really talked to VB developers in the field, I would imagine
> what they want more than anything is just a one to one feature set with C#.
> But this aside, I don't really like the extension concept because it feels
> too much like multiple inheritance and might have similar issues associated
> with it in terms of maintainability of code.
> 6. Nested functions I can see real benefits to, but it does make VB feel
> quite a bit like ML. But this could really go along way to making some
> things really easy to understand.
> 7. Relaxed Delgates. Dislike this for the same reason I don't like
> implicit type conversion.
> 8. Dynamic interfaces. Ditto.
> 9. Dynamic identifiers. More of the same.
>
> I guess my conclusion is I like some, but overall because of the
> destruction of clear typing, I have to give it a thumbs down. These sorts
> of things should be done sparingly in clear code, so sparingly that
> programmers should have to understand the intricacies of reflection before
> they are given a license to do them. I feel VB9 legislates bad habits and
> practices we gave up prior to VB.NET.
>
> My gut tells me that this is really all about upgrading the tremendous share
> of VB5 and VB6 users to .NET who so far not made the transition. I imagine
> upgrading a VB6 application to VB9 will be much simpler than any other .NET
> upgrade prior. But for those of us who have made the transition, I think
> the lack of typing is bad policy. It may simply be time for me to byte the
> bullet on curlies and semicolons
>
> --
> Justin Weinberg
> MCAD/MCSD .NET
>
>
>[/color]

I agree. If the VS2005 TableAdapter (which harkens back to the Data Access
methodology of the 90's), and the My namespace, and Code Snippets tool
doesn't entice them, there's no hope. I say forget them.

VB doesn't need to get dumber. It needs to get smarter... and cooler- as I
explain in another post in this thread.

--
-C. Moya
www.cmoya.com

A Document Outline for code that displays #regions as well as groups members
by type (Methods, Properties, etc). I saw at the Feature Request Labs that
this is
already in the pipeline but I'm not sure how many people have voted on it.
Done right, this would be awesome.

Smarter Code insertion. I don't use #Regions very much (I find them to be
unwieldy given the lack of a Document Outline mentioned above) BUT I do like
to keep
related types of methods near each other in the file... like all my Property
Accessors at the top and all my Event Handlers towards the end of the file.
When I double click on a Control I'd like the code to be inserted near other
event handlers.... not in the (seemingly) random way it's inserted now.

Visual Attributes Editor. Attributes (or at least a common set of them)
should show up in the Properties Toolbox (or something similar... like the
way Code Snippets appear) when the cursor is positioned on the
Method/Function/Property name line. I can never remember the exact syntax of
the oodles of attributes that I often want to apply to a property.

Refactoring in VB2005 is pretty lame. I like the right-click "Rename" symbol
feature but that's pretty much the extent of refactoring in VB2005. The 3rd
party free Refactor! Lite tool MS touts as a workaround is OK... but I'd
like to see this as part of VB proper.

Super-Smart Find. Regular Expressions is cool... but Find is still pretty
dumb. I'd like to be able to search by Type- (Find Next
"System.Windows.Forms.Control" reference).

Probably no other thing will the give the VB community a slap in the *ss as
a good set of Coding Standards Recommendations from MS. No, public Object
Model recommendations is not enough. This would go a long way to helping VB
achieve the same level of respect given to other development languages. It
is for good reason that VB developers have a bad rep.... because we tend to
write bad code because we feel like it and because we can. Open up two
different applications from two different VB developers and you will see
WILDLY different code standards.... this makes maintaining VB programs a
NIGHTMARE.... and it is for sure a BIG reason corporations are trying to
move away from VB and to C#.

--
-C. Moya
www.cmoya.com
"Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl...[color=blue]
> My thoughts on this....
>
> http://msdn.microsoft.com/vbasic/Fut...b9overview.asp
>
>
> My thoughts:
>
> 1. Regarding Implicit types, I don't use type declaration for the
> benefits of performance. It's for the benefit of clarity of purpose when
> reading code. The first thing I do with neophyte developers is turn
> Option Strict On to help them understand why they do what they do. With
> this, I can't stop people from writing garbly gook.
> 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
> and there could be real beneifts to it.
> 3. Nullable types. I think this is a really good idea if it integrates
> with SQL Server well.
> 4. I think I will like the Query Comprehension features, because I think
> it makes understanding certain intents clearer.
> 5. "Because extension methods are intended mostly for library designers,
> Visual Basic does not offer direct language syntax support for declaring
> them." - This kind of comment has always bugged me, and probably rubs all
> VB developers who are serious about the language wrong. It reveals a "red
> headed stepchild" attitude toward the language, as if C# is the "real
> thing". If you really talked to VB developers in the field, I would
> imagine what they want more than anything is just a one to one feature set
> with C#. But this aside, I don't really like the extension concept because
> it feels too much like multiple inheritance and might have similar issues
> associated with it in terms of maintainability of code.
> 6. Nested functions I can see real benefits to, but it does make VB
> feel quite a bit like ML. But this could really go along way to making
> some things really easy to understand.
> 7. Relaxed Delgates. Dislike this for the same reason I don't like
> implicit type conversion.
> 8. Dynamic interfaces. Ditto.
> 9. Dynamic identifiers. More of the same.
>
> I guess my conclusion is I like some, but overall because of the
> destruction of clear typing, I have to give it a thumbs down. These sorts
> of things should be done sparingly in clear code, so sparingly that
> programmers should have to understand the intricacies of reflection before
> they are given a license to do them. I feel VB9 legislates bad habits and
> practices we gave up prior to VB.NET.
>
> My gut tells me that this is really all about upgrading the tremendous
> share of VB5 and VB6 users to .NET who so far not made the transition. I
> imagine upgrading a VB6 application to VB9 will be much simpler than any
> other .NET upgrade prior. But for those of us who have made the
> transition, I think the lack of typing is bad policy. It may simply be
> time for me to byte the bullet on curlies and semicolons
>
> --
> Justin Weinberg
> MCAD/MCSD .NET
>[/color]

Oh yeah. And I totally agree with Justin's initial comments. I'd go further
and say Implicit types will be VB's death-knell. MS, I think, has gone
insane in the last two years.... they're like a chicken without head not
quite sure about what they should be doing. IMHO Soma Somasgar needs to
goooooooo.

There's so many more things they could be spending time to improve instead
of this (like a good Visual Editor for Databinding rather than the
cumbersome dropdown combo methods of today, better WebForm Designer, better
more intuitive Visual Editor for Localization via Resources rather than
bug-ridden unweildy combo dropdown editor we have today, etc etc).

I could go on.

P.S. I like LINQ and XLING though. That seems truly innovative.

--
-C. Moya
www.cmoya.com

<SNIP>[color=blue]
> The catch is that developers who haven't upgraded to .NET yet are likely
> to
> be the ones who most love the VB6 "let me forget to type in half the
> details
> and let the compiler sort it out" philosophy.
>
> So the result is that we already have implicit form instances (no, most
> VB6
> developers don't know what that means, but they certainly know that they
> don't want to type one line to instantiate a form instance). In VB9 we'll
> have implicit variable types (again, most VB6 developers don't know what
> that
> means, but they certainly know that they don't want to have to think about
> variable types).[/color]
</SNIP>

"Most VB6 programmers" are not that dumb and/or messy...

The only thing on my wish list for VB2005 are a couple of bug-fixes, maybe a
additional control or two (MDI Tabs perhaps) and most important: Decent help
documentation!

"CMM" <cmm@nospam.com> wrote in message
news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl...[color=blue]
> Oh yeah. And I totally agree with Justin's initial comments. I'd go
> further and say Implicit types will be VB's death-knell. MS, I think, has
> gone insane in the last two years.... they're like a chicken without head
> not quite sure about what they should be doing. IMHO Soma Somasgar needs
> to goooooooo.
>
> There's so many more things they could be spending time to improve instead
> of this (like a good Visual Editor for Databinding rather than the
> cumbersome dropdown combo methods of today, better WebForm Designer,
> better more intuitive Visual Editor for Localization via Resources rather
> than bug-ridden unweildy combo dropdown editor we have today, etc etc).
>
> I could go on.
>
> P.S. I like LINQ and XLING though. That seems truly innovative.
>
> --
> -C. Moya
> www.cmoya.com
>[/color]

Sorry for the blanket statement - too rash.
I'll revise those statements to read "the VB6 developers who Microsoft seems
to be listening to" instead of "most VB6 developers".

It's the VB6 developers who are clamoring for implicit types who probably
don't know the meanings of these terms.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

"Martin" wrote:
[color=blue]
> <SNIP>[color=green]
> > The catch is that developers who haven't upgraded to .NET yet are likely
> > to
> > be the ones who most love the VB6 "let me forget to type in half the
> > details
> > and let the compiler sort it out" philosophy.
> >
> > So the result is that we already have implicit form instances (no, most
> > VB6
> > developers don't know what that means, but they certainly know that they
> > don't want to type one line to instantiate a form instance). In VB9 we'll
> > have implicit variable types (again, most VB6 developers don't know what
> > that
> > means, but they certainly know that they don't want to have to think about
> > variable types).[/color]
> </SNIP>
>
> "Most VB6 programmers" are not that dumb and/or messy...
>
>
>[/color]

MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source
code included.
Yeah, the Help contents... especially in VS2005 seems to have been written
by robot... or simply dumped using a tool like NDoc. It's plain unhelpful. I
find way more pertinent information using Google than using the gigabytes
and gigabytes of VStudio Help and MSDN.

--
-C. Moya
www.cmoya.com

"Martin" <x@y.com> wrote in message
news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl...[color=blue]
> The only thing on my wish list for VB2005 are a couple of bug-fixes, maybe
> a additional control or two (MDI Tabs perhaps) and most important: Decent
> help documentation!
>
> "CMM" <cmm@nospam.com> wrote in message
> news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl...[color=green]
>> Oh yeah. And I totally agree with Justin's initial comments. I'd go
>> further and say Implicit types will be VB's death-knell. MS, I think, has
>> gone insane in the last two years.... they're like a chicken without head
>> not quite sure about what they should be doing. IMHO Soma Somasgar needs
>> to goooooooo.
>>
>> There's so many more things they could be spending time to improve
>> instead of this (like a good Visual Editor for Databinding rather than
>> the cumbersome dropdown combo methods of today, better WebForm Designer,
>> better more intuitive Visual Editor for Localization via Resources rather
>> than bug-ridden unweildy combo dropdown editor we have today, etc etc).
>>
>> I could go on.
>>
>> P.S. I like LINQ and XLING though. That seems truly innovative.
>>
>> --
>> -C. Moya
>> www.cmoya.com
>>[/color]
>
>[/color]

I agree. I think the VB community had sorted out all those "bad practices"
by the late 90's and early 2000 or so. But not all. I've met MANY genius
(genius!) VB developers who wrote good (great!) code. However, because of
VB.Classic's easy entry-level, there were many (many!) bad programmers who
actually got well paying jobs and ended up producing a lot of the horrible
crapola of VB programs that folks like me need to come in and
upgrade/maintain/port. I think those guys formed about 75% of the *entire*
VB developer base (from students to pros).

Microsoft doesn't need to take a step back now. I think the learning curve
of VB.NET is GOOD. It helps to weed out those kiddie-programmers who gave
VB.Classic the rep it is still trying to live down to this day.

Just my (admittedly condescending) 2c.

--
-C. Moya
www.cmoya.com

"David Anton" <DavidAnton@discussions.microsoft.com> wrote in message
news:D2A0A2D9-2305-49FD-B8AA-74FF19F1318D@microsoft.com...[color=blue]
> Sorry for the blanket statement - too rash.
> I'll revise those statements to read "the VB6 developers who Microsoft
> seems
> to be listening to" instead of "most VB6 developers".
>
> It's the VB6 developers who are clamoring for implicit types who probably
> don't know the meanings of these terms.
> --
> David Anton
> www.tangiblesoftwaresolutions.com
> Instant C#: VB to C# converter
> Instant VB: C# to VB converter
> Instant C++: C# to C++ converter & VB to C++ converter
> Instant J#: VB to J# converter
>
>
>
> "Martin" wrote:
>[color=green]
>> <SNIP>[color=darkred]
>> > The catch is that developers who haven't upgraded to .NET yet are
>> > likely
>> > to
>> > be the ones who most love the VB6 "let me forget to type in half the
>> > details
>> > and let the compiler sort it out" philosophy.
>> >
>> > So the result is that we already have implicit form instances (no, most
>> > VB6
>> > developers don't know what that means, but they certainly know that
>> > they
>> > don't want to type one line to instantiate a form instance). In VB9
>> > we'll
>> > have implicit variable types (again, most VB6 developers don't know
>> > what
>> > that
>> > means, but they certainly know that they don't want to have to think
>> > about
>> > variable types).[/color]
>> </SNIP>
>>
>> "Most VB6 programmers" are not that dumb and/or messy...
>>
>>
>>[/color][/color]

Yup, I've seen and downloaded that MDI tabs control, you did a great job
there.

"CMM" <cmm@nospam.com> wrote in message
news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl...[color=blue]
> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source
> code included.
> Yeah, the Help contents... especially in VS2005 seems to have been written
> by robot... or simply dumped using a tool like NDoc. It's plain unhelpful.
> I find way more pertinent information using Google than using the
> gigabytes and gigabytes of VStudio Help and MSDN.
>
> --
> -C. Moya
> www.cmoya.com
>
> "Martin" <x@y.com> wrote in message
> news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl...[color=green]
>> The only thing on my wish list for VB2005 are a couple of bug-fixes,
>> maybe a additional control or two (MDI Tabs perhaps) and most important:
>> Decent help documentation!
>>
>> "CMM" <cmm@nospam.com> wrote in message
>> news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl...[color=darkred]
>>> Oh yeah. And I totally agree with Justin's initial comments. I'd go
>>> further and say Implicit types will be VB's death-knell. MS, I think,
>>> has gone insane in the last two years.... they're like a chicken without
>>> head not quite sure about what they should be doing. IMHO Soma Somasgar
>>> needs to goooooooo.
>>>
>>> There's so many more things they could be spending time to improve
>>> instead of this (like a good Visual Editor for Databinding rather than
>>> the cumbersome dropdown combo methods of today, better WebForm Designer,
>>> better more intuitive Visual Editor for Localization via Resources
>>> rather than bug-ridden unweildy combo dropdown editor we have today, etc
>>> etc).
>>>
>>> I could go on.
>>>
>>> P.S. I like LINQ and XLING though. That seems truly innovative.
>>>
>>> --
>>> -C. Moya
>>> www.cmoya.com
>>>[/color]
>>
>>[/color]
>
>[/color]

It's a work in progress. The tab window switching works well I think. Now
I'm working on perfecting some of the other esoteric options like the Aux
window.... as some of the properties conflict with each other (for instance
AutoHide, doesn't resize the Aux Window when the WindowManagerPanel hides
itself). If you have any comments or suggestions, by all means.

--
-C. Moya
www.cmoya.com
"Martin" <x@y.com> wrote in message
news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl...[color=blue]
> Yup, I've seen and downloaded that MDI tabs control, you did a great job
> there.
>
>
> "CMM" <cmm@nospam.com> wrote in message
> news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl...[color=green]
>> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source
>> code included.
>> Yeah, the Help contents... especially in VS2005 seems to have been
>> written by robot... or simply dumped using a tool like NDoc. It's plain
>> unhelpful. I find way more pertinent information using Google than using
>> the gigabytes and gigabytes of VStudio Help and MSDN.
>>
>> --
>> -C. Moya
>> www.cmoya.com
>>
>> "Martin" <x@y.com> wrote in message
>> news:u6UgwUyOGHA.3856@TK2MSFTNGP12.phx.gbl...[color=darkred]
>>> The only thing on my wish list for VB2005 are a couple of bug-fixes,
>>> maybe a additional control or two (MDI Tabs perhaps) and most important:
>>> Decent help documentation!
>>>
>>> "CMM" <cmm@nospam.com> wrote in message
>>> news:Of$v69wOGHA.312@TK2MSFTNGP12.phx.gbl...
>>>> Oh yeah. And I totally agree with Justin's initial comments. I'd go
>>>> further and say Implicit types will be VB's death-knell. MS, I think,
>>>> has gone insane in the last two years.... they're like a chicken
>>>> without head not quite sure about what they should be doing. IMHO Soma
>>>> Somasgar needs to goooooooo.
>>>>
>>>> There's so many more things they could be spending time to improve
>>>> instead of this (like a good Visual Editor for Databinding rather than
>>>> the cumbersome dropdown combo methods of today, better WebForm
>>>> Designer, better more intuitive Visual Editor for Localization via
>>>> Resources rather than bug-ridden unweildy combo dropdown editor we have
>>>> today, etc etc).
>>>>
>>>> I could go on.
>>>>
>>>> P.S. I like LINQ and XLING though. That seems truly innovative.
>>>>
>>>> --
>>>> -C. Moya
>>>> www.cmoya.com
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

Agreed, very nice!!
james

"Martin" <x@y.com> wrote in message
news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl...[color=blue]
> Yup, I've seen and downloaded that MDI tabs control, you did a great job
> there.
>
>
> "CMM" <cmm@nospam.com> wrote in message
> news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl...[color=green]
>> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and source
>> code included.
>> Yeah, the Help contents... especially in VS2005 seems to have been
>> written by robot... or simply dumped using a tool like NDoc. It's plain
>> unhelpful. I find way more pertinent information using Google than using
>> the gigabytes and gigabytes of VStudio Help and MSDN.
>>
>> --
>> -C. Moya
>> www.cmoya.com
>>[/color][/color]

Why thanks! I'm working on fixing the logic that deals with making changes
at runtime... like the AutoHide and Orientation clashing with each other and
stuff. I'd like to get it real nice and super-stable so I can kinda leave it
be for a while. ;-)

--
-C. Moya
www.cmoya.com
"james" <jjames700REMOVEME@earthlink.net> wrote in message
news:%23SUthQ1OGHA.3100@TK2MSFTNGP11.phx.gbl...[color=blue]
> Agreed, very nice!!
> james
>
> "Martin" <x@y.com> wrote in message
> news:em8MvEzOGHA.3516@TK2MSFTNGP15.phx.gbl...[color=green]
>> Yup, I've seen and downloaded that MDI tabs control, you did a great job
>> there.
>>
>>
>> "CMM" <cmm@nospam.com> wrote in message
>> news:OJVnbtyOGHA.2300@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>> MDI Tabs. http://www.cflashsoft.com/progs/mdiwinman/ It's free and
>>> source code included.
>>> Yeah, the Help contents... especially in VS2005 seems to have been
>>> written by robot... or simply dumped using a tool like NDoc. It's plain
>>> unhelpful. I find way more pertinent information using Google than using
>>> the gigabytes and gigabytes of VStudio Help and MSDN.
>>>
>>> --
>>> -C. Moya
>>> www.cmoya.com
>>>[/color][/color]
>
>[/color]

CMM wrote:[color=blue]
> Oh yeah. And I totally agree with Justin's initial comments. I'd go further
> and say Implicit types will be VB's death-knell.[/color]

Why will implicit local variable typing kill VB but not C# ?

--
Larry Lard
Replies to group please

> Why will implicit local variable typing kill VB but not C# ?

I don't know how to answer that without offending anyone.

I fear in five years I'll be opening a big VB application at some bank and
see a huge mess of code with nothing but implicit type declarations..... I'd
go crazy! I'm sure Implicit Types have their place... like when used in
conjunction with LINQ. But, VB developers are going to abuse it... I just
know it.

For the most part (and I know this may be an over-generalization) but C#
developers are more disciplined and adhere to more structured sets of
standards than do VB developers.... the language practically demands it.
It's lack of background compile- and thus full real-time full syntax
checking and full intellisense- (I won't even get into the reliance on
delegates and non-intuitive event handling) just force you to be. VB may be
easier to approach... easier to maintain... but, also A LOT easier to muck
up. VB has a bad rep that it has just in the last four years begun to live
down. I can smell that rep coming back.

--
-C. Moya
www.cmoya.com
"Larry Lard" <larrylard@hotmail.com> wrote in message
news:1141040057.721226.309240@e56g2000cwe.googlegr oups.com...[color=blue]
>
> CMM wrote:[color=green]
>> Oh yeah. And I totally agree with Justin's initial comments. I'd go
>> further
>> and say Implicit types will be VB's death-knell.[/color]
>
> Why will implicit local variable typing kill VB but not C# ?
>
> --
> Larry Lard
> Replies to group please
>[/color]

I don't get the feeling MS is listening to any developers, but I'm sure some
bright mind in the marketing department thought of this all on his/her own.

There are a whole bunch of serious, knowledgable and professional developers
in VB6 who have created products over the years which can't be easily ported
to VB.Net. For instance the upgrade analysis tool (the name slipped my mind)
said about our flagship app that it would take a bit more than a year and a
couple of $100K to port the app to VB.Net. And to make things worse it would
mean that we would need to stop development for this app for that period of
time. This is simply not an option. I don't know what MS was thinking when
they created such an upgrade path, probably that there were only hobbyists
toying with the language or so.

Reading about the future releases of Windows shows that continuing in VB6
isn't an option either, so we are basically forced to invest this time and
money into this upgrade.

If MS would have listended to developers they would have never created such
a nightmare scenario.

Let me say that I do love VB2005 as language and development platform, it
contains everything I have missed so much in VB6. But they should have
offered a decent upgrade path (and useful help-documentation, I can't say
that often enough, the provided documentation is absolutely sub-standard).

Martin

"David Anton" <DavidAnton@discussions.microsoft.com> wrote in message
news:D2A0A2D9-2305-49FD-B8AA-74FF19F1318D@microsoft.com...[color=blue]
> Sorry for the blanket statement - too rash.
> I'll revise those statements to read "the VB6 developers who Microsoft
> seems
> to be listening to" instead of "most VB6 developers".
>
> It's the VB6 developers who are clamoring for implicit types who probably
> don't know the meanings of these terms.
> --
> David Anton
> www.tangiblesoftwaresolutions.com
> Instant C#: VB to C# converter
> Instant VB: C# to VB converter
> Instant C++: C# to C++ converter & VB to C++ converter
> Instant J#: VB to J# converter
>
>
>
> "Martin" wrote:
>[color=green]
>> <SNIP>[color=darkred]
>> > The catch is that developers who haven't upgraded to .NET yet are
>> > likely
>> > to
>> > be the ones who most love the VB6 "let me forget to type in half the
>> > details
>> > and let the compiler sort it out" philosophy.
>> >
>> > So the result is that we already have implicit form instances (no, most
>> > VB6
>> > developers don't know what that means, but they certainly know that
>> > they
>> > don't want to type one line to instantiate a form instance). In VB9
>> > we'll
>> > have implicit variable types (again, most VB6 developers don't know
>> > what
>> > that
>> > means, but they certainly know that they don't want to have to think
>> > about
>> > variable types).[/color]
>> </SNIP>
>>
>> "Most VB6 programmers" are not that dumb and/or messy...
>>
>>
>>[/color][/color]

"Martin" <x@y.com> wrote in message
news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl...
..[color=blue]
>
> Let me say that I do love VB2005 as language and development platform, it
> contains everything I have missed so much in VB6. But they should have
> offered a decent upgrade path (and useful help-documentation, I can't say
> that often enough, the provided documentation is absolutely sub-standard).
>
> Martin
>[/color]

Martin, when you say the Help Documentation is sub-standard, exactly what do
you mean? Are you talking about
help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But,
otherwise, I have found the new Help
system in VB2005 to be very nice. In the first beta I tried, it was pretty
bad, but, since it was a beta, I was not
too suprised. But, the final product that I have ( Visual Studio 2005
Standard) , has very good help. And lots of
good example code. Something that earlier versions were very short on. I
really like the fact that the Help system
not only looks for information from the local drive, but, also goes out and
gets online information too. So far, I have
been pretty pleased with VB2005 and the Help system. And I have been lucky
that I do not have any legacy applications
(VB6)that need porting to VB2005. ( although, I do have a current project in
VB2003, that I plan to move to 2005)
Anyway, I would be interested in what you find lacking in the new Help
system.
james

When I want to look up information about something, I have to sift through
hundreds of pages of non-applicable garbage. The pages that do apply are
probably auto-generated with some kind of robot that analyzes their source
code.

Try and look up information about how to assign shortcut keys to tabpage
captions. In VB.COM it was pretty simple, you just put a ampersand in front
of the character that serves as hotkey. This mechanism doesn't work anymore
in VB2005, so I dive into the help-hell and try to find how to do this with
search phrases like "tabpage shortcut key" and "tabcontrol shortcut key".
None of the pages seems to give me any clue as to how to do this. Very well
possible that it was there and I overlooked it, after the 30th page with
non-applicable class structures I tend to get somewhat impatient and don't
read the page thoroughly.

The best help system was imho the one provided with VB5. There you looked up
the control or whatever you needed, got a page with interesting general
information and then links to properties, events, methods, examples, etc.
Clear and to the point.

In VB6 they provided us with MSDN, which still incorporated the old help
documentation, you just had to search a bit harder.

In my current VB2005 Team edition when I search for something I get
litterally 100s of pages on MSDN online, a bunch of pages in the "Codezone
Community", a few pages in "Questions" and most of the time 0 pages in Local
Help.

As of today my msdn online doesn't work anymore...

"Search failed
"The request failed with the error message:
"--
"<html><head><title>Object moved</title></head><body>
"<h2>Object moved to <a href=......

etc.

Well, I'd say: Good riddens!

"james" <jjames700REMOVEME@earthlink.net> wrote in message
news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl...[color=blue]
>
> "Martin" <x@y.com> wrote in message
> news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl...
> .[color=green]
>>
>> Let me say that I do love VB2005 as language and development platform, it
>> contains everything I have missed so much in VB6. But they should have
>> offered a decent upgrade path (and useful help-documentation, I can't say
>> that often enough, the provided documentation is absolutely
>> sub-standard).
>>
>> Martin
>>[/color]
>
>
> Martin, when you say the Help Documentation is sub-standard, exactly what
> do you mean? Are you talking about
> help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But,
> otherwise, I have found the new Help
> system in VB2005 to be very nice. In the first beta I tried, it was pretty
> bad, but, since it was a beta, I was not
> too suprised. But, the final product that I have ( Visual Studio 2005
> Standard) , has very good help. And lots of
> good example code. Something that earlier versions were very short on. I
> really like the fact that the Help system
> not only looks for information from the local drive, but, also goes out
> and gets online information too. So far, I have
> been pretty pleased with VB2005 and the Help system. And I have been
> lucky that I do not have any legacy applications
> (VB6)that need porting to VB2005. ( although, I do have a current project
> in VB2003, that I plan to move to 2005)
> Anyway, I would be interested in what you find lacking in the new Help
> system.
> james
>
>[/color]

I have it set to search Local First Then Online. And, I hate it when I press
F1 (the current right way; without highlighting the entire word) and the
Help search instantly swtiches to Online Generic Mode Search because it
can't find the topic in the local library. But, the topic IS in the library.
Duh! Highlighting the word and hitting F1 triggers an even *more generic*
search.... which is plain unintuitive in my opinion.

This happens all the time... wish I could remember what the last topic
was... but, it was something very simple that should not have triggered a
catch-all search.

Throw in the fact that you can't install the Library on a FileServer (as
you've been able to do for the last 10 years) and VS2005 Help is PURE
TRASH.... well, maybe that's a bit harsh. Let's just say that it's not an
"improvement" over previous incarnations.

I also agree that in terms of *VB* a better Help System has not been seen
since the VB4 (and VB5? I went straight to VB6 from 4 so I don't know) days.
It was clear and ACCURATE. VB6 MSDN Help wasn't great but at least it was
exhaustive. VS2003's Help is neither great nor exhaustive. I get more
helpful info from Google, Devx, and forums.

--
-C. Moya
www.cmoya.com
"Martin" <x@y.com> wrote in message
news:%23d%23srZBPGHA.3888@TK2MSFTNGP12.phx.gbl...[color=blue]
> When I want to look up information about something, I have to sift through
> hundreds of pages of non-applicable garbage. The pages that do apply are
> probably auto-generated with some kind of robot that analyzes their source
> code.
>
> Try and look up information about how to assign shortcut keys to tabpage
> captions. In VB.COM it was pretty simple, you just put a ampersand in
> front of the character that serves as hotkey. This mechanism doesn't work
> anymore in VB2005, so I dive into the help-hell and try to find how to do
> this with search phrases like "tabpage shortcut key" and "tabcontrol
> shortcut key". None of the pages seems to give me any clue as to how to do
> this. Very well possible that it was there and I overlooked it, after the
> 30th page with non-applicable class structures I tend to get somewhat
> impatient and don't read the page thoroughly.
>
> The best help system was imho the one provided with VB5. There you looked
> up the control or whatever you needed, got a page with interesting general
> information and then links to properties, events, methods, examples, etc.
> Clear and to the point.
>
> In VB6 they provided us with MSDN, which still incorporated the old help
> documentation, you just had to search a bit harder.
>
> In my current VB2005 Team edition when I search for something I get
> litterally 100s of pages on MSDN online, a bunch of pages in the "Codezone
> Community", a few pages in "Questions" and most of the time 0 pages in
> Local Help.
>
> As of today my msdn online doesn't work anymore...
>
>
> "Search failed
> "The request failed with the error message:
> "--
> "<html><head><title>Object moved</title></head><body>
> "<h2>Object moved to <a href=......
>
> etc.
>
> Well, I'd say: Good riddens!
>
>
> "james" <jjames700REMOVEME@earthlink.net> wrote in message
> news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl...[color=green]
>>
>> "Martin" <x@y.com> wrote in message
>> news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl...
>> .[color=darkred]
>>>
>>> Let me say that I do love VB2005 as language and development platform,
>>> it contains everything I have missed so much in VB6. But they should
>>> have offered a decent upgrade path (and useful help-documentation, I
>>> can't say that often enough, the provided documentation is absolutely
>>> sub-standard).
>>>
>>> Martin
>>>[/color]
>>
>>
>> Martin, when you say the Help Documentation is sub-standard, exactly what
>> do you mean? Are you talking about
>> help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But,
>> otherwise, I have found the new Help
>> system in VB2005 to be very nice. In the first beta I tried, it was
>> pretty bad, but, since it was a beta, I was not
>> too suprised. But, the final product that I have ( Visual Studio 2005
>> Standard) , has very good help. And lots of
>> good example code. Something that earlier versions were very short on. I
>> really like the fact that the Help system
>> not only looks for information from the local drive, but, also goes out
>> and gets online information too. So far, I have
>> been pretty pleased with VB2005 and the Help system. And I have been
>> lucky that I do not have any legacy applications
>> (VB6)that need porting to VB2005. ( although, I do have a current project
>> in VB2003, that I plan to move to 2005)
>> Anyway, I would be interested in what you find lacking in the new Help
>> system.
>> james
>>
>>[/color]
>
>[/color]

i am afraid that you are right...

"CMM" wrote:
[color=blue][color=green]
> > Why will implicit local variable typing kill VB but not C# ?[/color]
>
> I don't know how to answer that without offending anyone.
>
> I fear in five years I'll be opening a big VB application at some bank and
> see a huge mess of code with nothing but implicit type declarations..... I'd
> go crazy! I'm sure Implicit Types have their place... like when used in
> conjunction with LINQ. But, VB developers are going to abuse it... I just
> know it.
>
> For the most part (and I know this may be an over-generalization) but C#
> developers are more disciplined and adhere to more structured sets of
> standards than do VB developers.... the language practically demands it.
> It's lack of background compile- and thus full real-time full syntax
> checking and full intellisense- (I won't even get into the reliance on
> delegates and non-intuitive event handling) just force you to be. VB may be
> easier to approach... easier to maintain... but, also A LOT easier to muck
> up. VB has a bad rep that it has just in the last four years begun to live
> down. I can smell that rep coming back.
>
>
> --
> -C. Moya
> www.cmoya.com
> "Larry Lard" <larrylard@hotmail.com> wrote in message
> news:1141040057.721226.309240@e56g2000cwe.googlegr oups.com...[color=green]
> >
> > CMM wrote:[color=darkred]
> >> Oh yeah. And I totally agree with Justin's initial comments. I'd go
> >> further
> >> and say Implicit types will be VB's death-knell.[/color]
> >
> > Why will implicit local variable typing kill VB but not C# ?
> >
> > --
> > Larry Lard
> > Replies to group please
> >[/color]
>
>
>[/color]

I hope James can find the topic in the Help file... Am dying to see how I
should do it.

"james" <jjames700REMOVEME@earthlink.net> wrote in message
news:%23gU$Yl8OGHA.2124@TK2MSFTNGP14.phx.gbl...[color=blue]
>
> "Martin" <x@y.com> wrote in message
> news:ON7ms25OGHA.964@tk2msftngp13.phx.gbl...
> .[color=green]
>>
>> Let me say that I do love VB2005 as language and development platform, it
>> contains everything I have missed so much in VB6. But they should have
>> offered a decent upgrade path (and useful help-documentation, I can't say
>> that often enough, the provided documentation is absolutely
>> sub-standard).
>>
>> Martin
>>[/color]
>
>
> Martin, when you say the Help Documentation is sub-standard, exactly what
> do you mean? Are you talking about
> help in upgrading VB6 code to VB2005 ? If that's the case, I agree. But,
> otherwise, I have found the new Help
> system in VB2005 to be very nice. In the first beta I tried, it was pretty
> bad, but, since it was a beta, I was not
> too suprised. But, the final product that I have ( Visual Studio 2005
> Standard) , has very good help. And lots of
> good example code. Something that earlier versions were very short on. I
> really like the fact that the Help system
> not only looks for information from the local drive, but, also goes out
> and gets online information too. So far, I have
> been pretty pleased with VB2005 and the Help system. And I have been
> lucky that I do not have any legacy applications
> (VB6)that need porting to VB2005. ( although, I do have a current project
> in VB2003, that I plan to move to 2005)
> Anyway, I would be interested in what you find lacking in the new Help
> system.
> james
>
>[/color]

"Martin" <x@y.com> wrote in message
news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl...[color=blue]
>I hope James can find the topic in the Help file... Am dying to see how I
>should do it.
>[/color]

Martin, all I can say is, it has worked for me , so far. I know that a
searh in Help does bring in a lot of
hits, (nothing new, that has happened for years now) but, it seems to me ,
that the hits on the search are
much better. I have yet to have to scroll thru every hit to find what I
need. Usually the information is in
the first few hits. The only thing that I would like to see added to the
current help system, is a feature
from Google, "Search within results". that is something I have wished for
in Microsoft's
Help system ( including MSDN's website) for a very long time. In fact, if
they could include the advanced
Search features like Google has in the Help system, that would be great. (
hey, there's an idea, Microsoft
could license Google's Search engine..................not gonna happen!)
james

Ok, so where do I find how to put shortcut keys on tabpage titles?

"james" <jjames700REMOVEME@earthlink.net> wrote in message
news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl...[color=blue]
>
> "Martin" <x@y.com> wrote in message
> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl...[color=green]
>>I hope James can find the topic in the Help file... Am dying to see how I
>>should do it.
>>[/color]
>
> Martin, all I can say is, it has worked for me , so far. I know that a
> searh in Help does bring in a lot of
> hits, (nothing new, that has happened for years now) but, it seems to me ,
> that the hits on the search are
> much better. I have yet to have to scroll thru every hit to find what I
> need. Usually the information is in
> the first few hits. The only thing that I would like to see added to the
> current help system, is a feature
> from Google, "Search within results". that is something I have wished for
> in Microsoft's
> Help system ( including MSDN's website) for a very long time. In fact, if
> they could include the advanced
> Search features like Google has in the Help system, that would be great.
> ( hey, there's an idea, Microsoft
> could license Google's Search engine..................not gonna happen!)
> james
>
>[/color]

Results of 10-second (literally!) research using Google vs 30-minute
research using VS' Help:

Your answer found through Google Groups (not sure if it applies to VS2005).
http://groups.google.com/group/micro...a1f0127acca2d1

A workaround also found through Google
http://www.codeproject.com/vb/net/Mn...TabControl.asp

Try typing in "tabpage accelerator" in VS's Help and see if you get the same
kind of results.
VS2005's fancy "Online" did bring up similar results but not without showing
a litany of irrelevant red-herrings first.

--
-C. Moya
www.cmoya.com
"Martin" <x@y.com> wrote in message
news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl...[color=blue]
> Ok, so where do I find how to put shortcut keys on tabpage titles?
>
> "james" <jjames700REMOVEME@earthlink.net> wrote in message
> news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl...[color=green]
>>
>> "Martin" <x@y.com> wrote in message
>> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>>I hope James can find the topic in the Help file... Am dying to see how I
>>>should do it.
>>>[/color]
>>
>> Martin, all I can say is, it has worked for me , so far. I know that a
>> searh in Help does bring in a lot of
>> hits, (nothing new, that has happened for years now) but, it seems to me
>> , that the hits on the search are
>> much better. I have yet to have to scroll thru every hit to find what I
>> need. Usually the information is in
>> the first few hits. The only thing that I would like to see added to the
>> current help system, is a feature
>> from Google, "Search within results". that is something I have wished
>> for in Microsoft's
>> Help system ( including MSDN's website) for a very long time. In fact, if
>> they could include the advanced
>> Search features like Google has in the Help system, that would be great.
>> ( hey, there's an idea, Microsoft
>> could license Google's Search engine..................not gonna happen!)
>> james
>>
>>[/color]
>
>[/color]

Well, as Martin's answer will show you,,,,,,,,,,,you cannot. At least not
without extending the tabcontrol and adding the function yourself. I did not
say that the new Help was 100% better. And I didn't say it would be better
for everyone.
I said "I" like it and it works for "ME". I haven't had the need (yet) for
shortcut keys on a tabcontrol. If I do, I now know
where to look . (Martin's second link.........which I downloaded.)
I have only said that "I" feel that the new Help is an improvement over the
old system. And that is the way "I" feel about it.
Like everyone else, I have an opinion and I expressed it. The new help
system has worked better for me than the older
system had................so far. I am sorry that it doesn't meet your
needs. One thing for sure, I don't limit myself to just using
the included help system. I also use Google's Groups Search and the MSDN
website too. Unfortunately, with something as
large and complex as Visual Basic and the Framework(s) have become,
multiple help resources have become a must.
james

"Martin" <x@y.com> wrote in message
news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl...[color=blue]
> Ok, so where do I find how to put shortcut keys on tabpage titles?
>
> "james" <jjames700REMOVEME@earthlink.net> wrote in message
> news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl...[color=green]
>>
>> "Martin" <x@y.com> wrote in message
>> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>>I hope James can find the topic in the Help file... Am dying to see how I
>>>should do it.
>>>[/color]
>>
>> Martin, all I can say is, it has worked for me , so far. I know that a
>> searh in Help does bring in a lot of
>> hits, (nothing new, that has happened for years now) but, it seems to me
>> , that the hits on the search are
>> much better. I have yet to have to scroll thru every hit to find what I
>> need. Usually the information is in
>> the first few hits. The only thing that I would like to see added to the
>> current help system, is a feature
>> from Google, "Search within results". that is something I have wished
>> for in Microsoft's
>> Help system ( including MSDN's website) for a very long time. In fact, if
>> they could include the advanced
>> Search features like Google has in the Help system, that would be great.
>> ( hey, there's an idea, Microsoft
>> could license Google's Search engine..................not gonna happen!)
>> james
>>
>>[/color]
>
>[/color]

"Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl...
:
: My thoughts on this....
:
:
http://msdn.microsoft.com/vbasic/Fut...b9overview.asp

I've taken an opportunity to review the material (thanx to the OP for the
link) and I don't have the same reactions.

First, I should note that these changes do not apply to VB only. There is
also a link to the future of C# and I can't help but notice that the
features being commented on here are being included in both languages. These
features are changes at the framework level and are not changes to specific
languages. At least, that's my take.

Any down side to these changes will impact VB and C# equally and if VB code
will become littered with bad code blocks, C# will be just as likely to have
the same result. That said, I'm not so sure these changes will necessarily
produce bad code.

Here is the link to the C# document (Word .doc file)

http://download.microsoft.com/downlo...cification.doc

: My thoughts:
:
: 1. Regarding Implicit types, I don't use type declaration for the
: benefits of performance. It's for the benefit of clarity of purpose when
: reading code. The first thing I do with neophyte developers is turn
: Option Strict On to help them understand why they do what they do. With
: this, I can't stop people from writing garbly gook.

I don't see where implicit typed local variables is a bad idea. What's wrong
with the following?

Dim Title = "Dr."
Dim GivenName = "Joseph"
Dim OtherName = ""
Dim FamilyName = "Bleaux"
Dim NameSuffix = "Jr."
Dim NickNames() = {"Doc", "Joe", "Junior"}
Dim DateOfBirth = "UKNOWN"
Dim DateOfDeath = "UKNOWN"
Dim CauseOfDeath = "UNKNOWN"

We are clearly defining 9 objects of type String (including an array of
strings). As the documentation states, these are precisely equivalent to the
following:

Dim Title As String = ""
Dim GivenName As String = ""
Dim OtherName As String = ""
Dim FamilyName As String = ""
Dim NameSuffix As String = ""
Dim NickNames() As String = {"Doc", "Joe", "Junior"}
Dim DateOfBirth As String = "UNKNOWN"
Dim DateOfDeath As String = "UNKNOWN"
Dim CauseOfDeath As String = "UNKNOWN"

In C#, the equivalent declaration would be:

var Title = "";
var GivenName = "";
var OtherName = "";
var FamilyName = "";
var NameSuffix = "";
var NickNames = new String[] {"Doc", "Joe", "Junior"};
var DateOfBirth = "UKNOWN";
var DateOfDeath = "UKNOWN";
var CauseOfDeath = "UNKNOWN";

C# programmers will have a slightly more difficult time of things (they
should be used to that by now) because var is not a keyword as Dim is in VB.
If 'var' has been defined as a type and is in scope, then the compiler will
be creating 9 objects of type var for the above instead of String objects
(assuming that the above would compile at all). I find in interesting to
note that this syntax causes C# to take on something of a VB look and feel:

Dim Title = ""
var Title = "";

Dim someObject = New SomeObjectType
var someObject = new SomeObjectType();

Hmmmm...

While I find the For / Next syntax to be a little odd visually, I still
think it serves a handy purpose. As before, what is wrong with this?

For Each Dim Item In MyCollection
Console.WriteLine(Item.ToString())
Next

Variable "Item" has a scope limited to the For block and whose type is
clearly discernible. I have no use for the variable outside the For block
(and couldn't access it if I did) and all I *really* need to know is how to
use the object when I get it. Knowing the full name of the object doesn't
affect any resulting code I write or the behavior that is generating.
Normally, I'd have to have something along these lines

For Each Item As MyCollectionItem In MyCollection
Console.WriteLine(Item.ToString())
Next

And finally as I understand it, type safety is not being violated here. In
every case, objects are being assigned a specific type and implicit casts
are still rejected. As far as I can tell, the following should be rejected
by the compiler:

Dim I = 0
Dim S = 2.0
I = S

I'm defining an Integer (I) and a Single (S). I would expect the compiler to
object to the third line in the same manner that it does today:

Option Strict On disallows implicit conversions from 'Single' to
'Integer'.

I = S
~

The objection to this syntax is not clear to me. How does explicitly
defining the type in any of these expressions improve the code (either from
the perspective of readability, type safety, or just plain good programming
practices)?

There is one related feature to this that I find particularly intriguing:
the new object initializer syntax. I see this as a way to generate dynamic,
custom purpose constructors by the consumer of a given class. I think this
has a lot of potential.

Returning to my earlier example, let's say I define the following
pseudo-class:

Public Class Person
Public Property Title As String
Public Property GivenName As String
Public Property OtherName As String
Public Property FamilyName As String
Public Property Suffix As String
Public Property NickNames() As String
Public Property DateOfBirth As String
Public Property DateOfDeath As String
Public Property CauseOfDeath As String
End Class

I'm currently limited in how many different constructors I can expose.
Perhaps:

Sub New()
Sub New(FamilyName As String)
Sub New(FamilyName As String, GivenName As String)

Etc.

What I can't do is something like this:

Sub New(FamilyName As String)
Sub New(GivenName As String)

So if I want to use this class and populate certain fields, I would need to
do something along the following lines:

Dim P As New Person("Joseph", "Bleaux")
With P
.Title = "Doctor"
.Suffix = "Jr."
.DateOfBirth = "1/2/1950"
.DateOfDeath = "3/4/2006"
.CauseOfDeath = "Cancer"
End With

With the new syntax, I can effectively define my own custom purpose
constructor:

Dim P As New Person( _
.Title = "Dr.", _
.GivenName = "Joseph", _
.FamilyName = "Bleaux", _
.Suffix = "Jr.", _
.DateOfBirth = "1/2/1950", _
.DateOfDeath = "3/4/2006", _
.CauseOfDeath = "Cancer")

I like that.

: 2. No conflcit on XLING. I may not use it, but it doesn't hurt anything,
: and there could be real beneifts to it.
: 3. Nullable types. I think this is a really good idea if it integrates
: with SQL Server well.
: 4. I think I will like the Query Comprehension features, because I think
: it makes understanding certain intents clearer.
: 5. "Because extension methods are intended mostly for library designers,
: Visual Basic does not offer direct language syntax support for declaring
: them." - This kind of comment has always bugged me, and probably rubs all
: VB developers who are serious about the language wrong. It reveals a "red
: headed stepchild" attitude toward the language, as if C# is the "real
: thing". If you really talked to VB developers in the field, I would
: imagine what they want more than anything is just a one to one feature set
: with C#.

Here is the C# documentation commenting about the same thing:

Note

Extension methods are less discoverable and more limited in
functionality than instance methods. For those reasons, it is
recommended that extension methods be used sparingly and only
in situations where instance methods are not feasible or
possible.

Extension members of other kinds, such as properties, events,
and operators, are being considered but are currently not
supported.

I don't see the bias against VB in this. If C# has slightly better support
for this (and that's not clear to me), it isn't substantively so.

Now it does appear that C# is getting some features missing from VB (if I'm
reading the document correctly). One seems to be support for "Lambda
expressions" which I gather are "anonymous methods". Both VB9 and C#3 are
including support for "anonymous types" but that is evidently different from
"anonymous methods". For whatever reason, C# will have this but VB won't
(and perhaps I'm misreading the documentation - either way, I don't see
where VB programmers are being patronized by these changes).

: But this aside, I don't really like the extension concept because it feels
: too much like multiple inheritance and might have similar issues
: associated with it in terms of maintainability of code.
: 6. Nested functions I can see real benefits to, but it does make VB
: feel quite a bit like ML. But this could really go along way to making
: some things really easy to understand.
: 7. Relaxed Delgates. Dislike this for the same reason I don't like
: implicit type conversion.
: 8. Dynamic interfaces. Ditto.
: 9. Dynamic identifiers. More of the same.
:
: I guess my conclusion is I like some, but overall because of the
: destruction of clear typing, I have to give it a thumbs down. These sorts
: of things should be done sparingly in clear code, so sparingly that
: programmers should have to understand the intricacies of reflection before
: they are given a license to do them. I feel VB9 legislates bad habits and
: practices we gave up prior to VB.NET.
:
: My gut tells me that this is really all about upgrading the tremendous
: share of VB5 and VB6 users to .NET who so far not made the transition. I
: imagine upgrading a VB6 application to VB9 will be much simpler than any
: other .NET upgrade prior. But for those of us who have made the
: transition, I think the lack of typing is bad policy. It may simply be
: time for me to byte the bullet on curlies and semicolons
:
: --
: Justin Weinberg
: MCAD/MCSD .NET

I don't believe this has anything to do MS with trying to code down to VB
programmers nor does it strike me as being targeted at getting VB5/6
programmers to make the move to VB.net. From what I can tell, both C# and VB
are taking on virtually the same changes with pretty much the same end
result. As I stated above, I really think these changes are framework driven
and are not targeting any particular language.

Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.

To answer your questions about implicit types:
While Strings might be obvious, and it might seem obvious that
Dim s = 1
is an Integer.
But, is it obvious that later in the method
s / 2 will produce the results you might later expect if Option Explicit is
Off or was removed by some other developer in the code's chain of custody?
or that
Dim s = 1.0
is a floating point single, floating point double, or a decimal type.
or that
Dim s = GetFormattedNumer()
returns a stringbuilder and not a number or a string

The use of it in For/Loops is even more ingratiating.

From what I've read the C# community already has come out against overusing
implicit type declarations. They're pretty good with not adopting bad
habits. The fact that implicit types encourage laziness is something that
has incredible potential for abuse.

--
-C. Moya
www.cmoya.com
"_AnonCoward" <abcdef@uvwxyz.com> wrote in message
news:UT1Nf.27332$915.4559@southeast.rr.com...[color=blue]
>
> "Justin Weinberg" <jweinberg@_spammyoff_mrgsoft.com> wrote in message
> news:uklfXglOGHA.1312@TK2MSFTNGP09.phx.gbl...
> :
> : My thoughts on this....
> :
> :
> http://msdn.microsoft.com/vbasic/Fut...b9overview.asp
>
>
> I've taken an opportunity to review the material (thanx to the OP for the
> link) and I don't have the same reactions.
>
>
> First, I should note that these changes do not apply to VB only. There is
> also a link to the future of C# and I can't help but notice that the
> features being commented on here are being included in both languages.
> These
> features are changes at the framework level and are not changes to
> specific
> languages. At least, that's my take.
>
>
> Any down side to these changes will impact VB and C# equally and if VB
> code
> will become littered with bad code blocks, C# will be just as likely to
> have
> the same result. That said, I'm not so sure these changes will necessarily
> produce bad code.
>
>
> Here is the link to the C# document (Word .doc file)
>
> http://download.microsoft.com/downlo...cification.doc
>
>
> : My thoughts:
> :
> : 1. Regarding Implicit types, I don't use type declaration for the
> : benefits of performance. It's for the benefit of clarity of purpose
> when
> : reading code. The first thing I do with neophyte developers is turn
> : Option Strict On to help them understand why they do what they do. With
> : this, I can't stop people from writing garbly gook.
>
>
> I don't see where implicit typed local variables is a bad idea. What's
> wrong
> with the following?
>
> Dim Title = "Dr."
> Dim GivenName = "Joseph"
> Dim OtherName = ""
> Dim FamilyName = "Bleaux"
> Dim NameSuffix = "Jr."
> Dim NickNames() = {"Doc", "Joe", "Junior"}
> Dim DateOfBirth = "UKNOWN"
> Dim DateOfDeath = "UKNOWN"
> Dim CauseOfDeath = "UNKNOWN"
>
>
> We are clearly defining 9 objects of type String (including an array of
> strings). As the documentation states, these are precisely equivalent to
> the
> following:
>
>
> Dim Title As String = ""
> Dim GivenName As String = ""
> Dim OtherName As String = ""
> Dim FamilyName As String = ""
> Dim NameSuffix As String = ""
> Dim NickNames() As String = {"Doc", "Joe", "Junior"}
> Dim DateOfBirth As String = "UNKNOWN"
> Dim DateOfDeath As String = "UNKNOWN"
> Dim CauseOfDeath As String = "UNKNOWN"
>
>
> In C#, the equivalent declaration would be:
>
>
> var Title = "";
> var GivenName = "";
> var OtherName = "";
> var FamilyName = "";
> var NameSuffix = "";
> var NickNames = new String[] {"Doc", "Joe", "Junior"};
> var DateOfBirth = "UKNOWN";
> var DateOfDeath = "UKNOWN";
> var CauseOfDeath = "UNKNOWN";
>
>
> C# programmers will have a slightly more difficult time of things (they
> should be used to that by now) because var is not a keyword as Dim is in
> VB.
> If 'var' has been defined as a type and is in scope, then the compiler
> will
> be creating 9 objects of type var for the above instead of String objects
> (assuming that the above would compile at all). I find in interesting to
> note that this syntax causes C# to take on something of a VB look and
> feel:
>
> Dim Title = ""
> var Title = "";
>
> Dim someObject = New SomeObjectType
> var someObject = new SomeObjectType();
>
> Hmmmm...
>
>
> While I find the For / Next syntax to be a little odd visually, I still
> think it serves a handy purpose. As before, what is wrong with this?
>
>
> For Each Dim Item In MyCollection
> Console.WriteLine(Item.ToString())
> Next
>
>
> Variable "Item" has a scope limited to the For block and whose type is
> clearly discernible. I have no use for the variable outside the For block
> (and couldn't access it if I did) and all I *really* need to know is how
> to
> use the object when I get it. Knowing the full name of the object doesn't
> affect any resulting code I write or the behavior that is generating.
> Normally, I'd have to have something along these lines
>
>
> For Each Item As MyCollectionItem In MyCollection
> Console.WriteLine(Item.ToString())
> Next
>
>
> And finally as I understand it, type safety is not being violated here. In
> every case, objects are being assigned a specific type and implicit casts
> are still rejected. As far as I can tell, the following should be rejected
> by the compiler:
>
>
> Dim I = 0
> Dim S = 2.0
> I = S
>
>
> I'm defining an Integer (I) and a Single (S). I would expect the compiler
> to
> object to the third line in the same manner that it does today:
>
> Option Strict On disallows implicit conversions from 'Single' to
> 'Integer'.
>
> I = S
> ~
>
> The objection to this syntax is not clear to me. How does explicitly
> defining the type in any of these expressions improve the code (either
> from
> the perspective of readability, type safety, or just plain good
> programming
> practices)?
>
>
> There is one related feature to this that I find particularly intriguing:
> the new object initializer syntax. I see this as a way to generate
> dynamic,
> custom purpose constructors by the consumer of a given class. I think this
> has a lot of potential.
>
>
> Returning to my earlier example, let's say I define the following
> pseudo-class:
>
> Public Class Person
> Public Property Title As String
> Public Property GivenName As String
> Public Property OtherName As String
> Public Property FamilyName As String
> Public Property Suffix As String
> Public Property NickNames() As String
> Public Property DateOfBirth As String
> Public Property DateOfDeath As String
> Public Property CauseOfDeath As String
> End Class
>
>
> I'm currently limited in how many different constructors I can expose.
> Perhaps:
>
> Sub New()
> Sub New(FamilyName As String)
> Sub New(FamilyName As String, GivenName As String)
>
> Etc.
>
>
> What I can't do is something like this:
>
> Sub New(FamilyName As String)
> Sub New(GivenName As String)
>
>
> So if I want to use this class and populate certain fields, I would need
> to
> do something along the following lines:
>
> Dim P As New Person("Joseph", "Bleaux")
> With P
> .Title = "Doctor"
> .Suffix = "Jr."
> .DateOfBirth = "1/2/1950"
> .DateOfDeath = "3/4/2006"
> .CauseOfDeath = "Cancer"
> End With
>
> With the new syntax, I can effectively define my own custom purpose
> constructor:
>
> Dim P As New Person( _
> .Title = "Dr.", _
> .GivenName = "Joseph", _
> .FamilyName = "Bleaux", _
> .Suffix = "Jr.", _
> .DateOfBirth = "1/2/1950", _
> .DateOfDeath = "3/4/2006", _
> .CauseOfDeath = "Cancer")
>
>
> I like that.
>
>
> : 2. No conflcit on XLING. I may not use it, but it doesn't hurt
> anything,
> : and there could be real beneifts to it.
> : 3. Nullable types. I think this is a really good idea if it integrates
> : with SQL Server well.
> : 4. I think I will like the Query Comprehension features, because I
> think
> : it makes understanding certain intents clearer.
> : 5. "Because extension methods are intended mostly for library designers,
> : Visual Basic does not offer direct language syntax support for declaring
> : them." - This kind of comment has always bugged me, and probably rubs
> all
> : VB developers who are serious about the language wrong. It reveals a
> "red
> : headed stepchild" attitude toward the language, as if C# is the "real
> : thing". If you really talked to VB developers in the field, I would
> : imagine what they want more than anything is just a one to one feature
> set
> : with C#.
>
>
> Here is the C# documentation commenting about the same thing:
>
> Note
>
> Extension methods are less discoverable and more limited in
> functionality than instance methods. For those reasons, it is
> recommended that extension methods be used sparingly and only
> in situations where instance methods are not feasible or
> possible.
>
> Extension members of other kinds, such as properties, events,
> and operators, are being considered but are currently not
> supported.
>
>
> I don't see the bias against VB in this. If C# has slightly better support
> for this (and that's not clear to me), it isn't substantively so.
>
>
> Now it does appear that C# is getting some features missing from VB (if
> I'm
> reading the document correctly). One seems to be support for "Lambda
> expressions" which I gather are "anonymous methods". Both VB9 and C#3 are
> including support for "anonymous types" but that is evidently different
> from
> "anonymous methods". For whatever reason, C# will have this but VB won't
> (and perhaps I'm misreading the documentation - either way, I don't see
> where VB programmers are being patronized by these changes).
>
>
> : But this aside, I don't really like the extension concept because it
> feels
> : too much like multiple inheritance and might have similar issues
> : associated with it in terms of maintainability of code.
> : 6. Nested functions I can see real benefits to, but it does make VB
> : feel quite a bit like ML. But this could really go along way to making
> : some things really easy to understand.
> : 7. Relaxed Delgates. Dislike this for the same reason I don't like
> : implicit type conversion.
> : 8. Dynamic interfaces. Ditto.
> : 9. Dynamic identifiers. More of the same.
> :
> : I guess my conclusion is I like some, but overall because of the
> : destruction of clear typing, I have to give it a thumbs down. These
> sorts
> : of things should be done sparingly in clear code, so sparingly that
> : programmers should have to understand the intricacies of reflection
> before
> : they are given a license to do them. I feel VB9 legislates bad habits
> and
> : practices we gave up prior to VB.NET.
> :
> : My gut tells me that this is really all about upgrading the tremendous
> : share of VB5 and VB6 users to .NET who so far not made the transition.
> I
> : imagine upgrading a VB6 application to VB9 will be much simpler than any
> : other .NET upgrade prior. But for those of us who have made the
> : transition, I think the lack of typing is bad policy. It may simply be
> : time for me to byte the bullet on curlies and semicolons
> :
> : --
> : Justin Weinberg
> : MCAD/MCSD .NET
>
>
> I don't believe this has anything to do MS with trying to code down to VB
> programmers nor does it strike me as being targeted at getting VB5/6
> programmers to make the move to VB.net. From what I can tell, both C# and
> VB
> are taking on virtually the same changes with pretty much the same end
> result. As I stated above, I really think these changes are framework
> driven
> and are not targeting any particular language.
>
>
> Ralf
> --
> --
> ----------------------------------------------------------
> * ^~^ ^~^ *
> * _ {~ ~} {~ ~} _ *
> * /_``>*< >*<''_\ *
> * (\--_)++) (++(_--/) *
> ----------------------------------------------------------
> There are no advanced students in Aikido - there are only
> competent beginners. There are no advanced techniques -
> only the correct application of basic principles.
>
>
>
>[/color]

Oh well, this turned out to be a bad example, because this is no longer
possible. But I'm glad to hear I'm not the only one with this opinion about
the help documentation.

"james" <jjames700REMOVEME@earthlink.net> wrote in message
news:O7rOWsIPGHA.1360@TK2MSFTNGP10.phx.gbl...[color=blue]
> Well, as Martin's answer will show you,,,,,,,,,,,you cannot. At least not
> without extending the tabcontrol and adding the function yourself. I did
> not say that the new Help was 100% better. And I didn't say it would be
> better for everyone.
> I said "I" like it and it works for "ME". I haven't had the need (yet)
> for shortcut keys on a tabcontrol. If I do, I now know
> where to look . (Martin's second link.........which I downloaded.)
> I have only said that "I" feel that the new Help is an improvement over
> the old system. And that is the way "I" feel about it.
> Like everyone else, I have an opinion and I expressed it. The new help
> system has worked better for me than the older
> system had................so far. I am sorry that it doesn't meet your
> needs. One thing for sure, I don't limit myself to just using
> the included help system. I also use Google's Groups Search and the MSDN
> website too. Unfortunately, with something as
> large and complex as Visual Basic and the Framework(s) have become,
> multiple help resources have become a must.
> james
>
> "Martin" <x@y.com> wrote in message
> news:%23W69pAHPGHA.536@TK2MSFTNGP09.phx.gbl...[color=green]
>> Ok, so where do I find how to put shortcut keys on tabpage titles?
>>
>> "james" <jjames700REMOVEME@earthlink.net> wrote in message
>> news:OjVlR4GPGHA.3896@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>>
>>> "Martin" <x@y.com> wrote in message
>>> news:exGRuzFPGHA.2012@TK2MSFTNGP14.phx.gbl...
>>>>I hope James can find the topic in the Help file... Am dying to see how
>>>>I should do it.
>>>>
>>>
>>> Martin, all I can say is, it has worked for me , so far. I know that a
>>> searh in Help does bring in a lot of
>>> hits, (nothing new, that has happened for years now) but, it seems to me
>>> , that the hits on the search are
>>> much better. I have yet to have to scroll thru every hit to find what I
>>> need. Usually the information is in
>>> the first few hits. The only thing that I would like to see added to
>>> the current help system, is a feature
>>> from Google, "Search within results". that is something I have wished
>>> for in Microsoft's
>>> Help system ( including MSDN's website) for a very long time. In fact,
>>> if they could include the advanced
>>> Search features like Google has in the Help system, that would be great.
>>> ( hey, there's an idea, Microsoft
>>> could license Google's Search engine..................not gonna happen!)
>>> james
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

"CMM" <cmm@nospam.com> wrote in message
news:%23TTqVpKPGHA.2624@TK2MSFTNGP12.phx.gbl...
:
: To answer your questions about implicit types:
: While Strings might be obvious, and it might seem obvious that
: Dim s = 1
: is an Integer.
: But, is it obvious that later in the method
: s / 2 will produce the results you might later expect if Option Explicit
: is Off or was removed by some other developer in the code's chain of
: custody?
: or that
: Dim s = 1.0
: is a floating point single, floating point double, or a decimal type.
: or that
: Dim s = GetFormattedNumer()
: returns a stringbuilder and not a number or a string
:
: The use of it in For/Loops is even more ingratiating.
:
: From what I've read the C# community already has come out against
: overusing implicit type declarations. They're pretty good with not
: adopting bad habits. The fact that implicit types encourage laziness
: is something that has incredible potential for abuse.
:
:
: --
: -C. Moya
: www.cmoya.com

<snip for space>

I've debated submitting this response as I'm really not adding anything to
the discussion but I've come to the conclusion I agree that implicit types
are not a good idea. I've just reach this conclusion for a different reason.

You seem concerned that this will encourage laziness and lead to abuse.
Perhaps, but I don't think that is all that great of a concern. Your
statement that the "C# community already has come out against overusing
implicit type declarations" implies (at least to me) that it isn't implicit
typing that is the issue, but overuse of the mechanism. When all is said and
done, the variable is being instantiated as a specific type with all the
safeguards that entails. I may not know that "Dim s = GetFormattedNumer()"
will set s to a StringBuilder object, but I am still constrained to using s
identically as if I'd explicitly declared the variable type up front.

That said, the more I play with this, the less I'm liking it. What struck me
at first as being a convenient shorthand now seems more like a maintenance
headache. I may know as the original coder what my intentions were for the
following:

Dim s = GetFormattedNumer()

But as someone coming after the fact to maintain the code, it isn't nearly
so obvious. In fact, I'll run into that problem even if I'm the original
coder returning to the code six months later. I recognize now that every
time I come across an implicit type statement, I will have to mentally
discern the assignment type. It could cost me in time and additional bugs in
the code if I misread the type. The following may be equivalent, but the
second statement is much clearer:

Dim I = 1
Dim I As Integer = 1

So, yeah - on further reflection, I agree that implicit typing is not that
good of an idea after all.

Ralf
--
AA #2250
-------------------------------------------------------------
* ^~^ ^~^ *
* _ {| |} {| |} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
-------------------------------------------------------------
Nature is the canvas of creation and evolution but one of
the brushes. Religion points to the mind of God; Science
reveals its unfolding. The subjective apprehends knowledge
while the objective facilitates understanding.

In all things, yin and yang - ever flowing, one into the
other; always overtaking, always overtaken.

I agree with you wholeheartedly... you hit the nail on the head much better
than I did.
Indeed, the problem is overuse I think. Implicit typing while convenient in
*some* situations, should not become a "standard practice." I am terrified
that- in the VB community- it will become so.

However, if you look at the LINQ stuff and how that works (IMO it's very
B.A.S.I.C. "statement" - like.... which we've lost a lot of in VB.NET like
"Open file For Input As Access... or many of the screen drawing statements)
implicit typing is very useful and makes more sense.

--
-C. Moya
www.cmoya.com
"_AnonCoward" <abcdef@uvwxyz.com> wrote in message
news:1fZNf.51095$no3.31361@tornado.southeast.rr.co m...[color=blue]
>
> "CMM" <cmm@nospam.com> wrote in message
> news:%23TTqVpKPGHA.2624@TK2MSFTNGP12.phx.gbl...
> :
> : To answer your questions about implicit types:
> : While Strings might be obvious, and it might seem obvious that
> : Dim s = 1
> : is an Integer.
> : But, is it obvious that later in the method
> : s / 2 will produce the results you might later expect if Option Explicit
> : is Off or was removed by some other developer in the code's chain of
> : custody?
> : or that
> : Dim s = 1.0
> : is a floating point single, floating point double, or a decimal type.
> : or that
> : Dim s = GetFormattedNumer()
> : returns a stringbuilder and not a number or a string
> :
> : The use of it in For/Loops is even more ingratiating.
> :
> : From what I've read the C# community already has come out against
> : overusing implicit type declarations. They're pretty good with not
> : adopting bad habits. The fact that implicit types encourage laziness
> : is something that has incredible potential for abuse.
> :
> :
> : --
> : -C. Moya
> : www.cmoya.com
>
>
> <snip for space>
>
> I've debated submitting this response as I'm really not adding anything to
> the discussion but I've come to the conclusion I agree that implicit types
> are not a good idea. I've just reach this conclusion for a different
> reason.
>
>
> You seem concerned that this will encourage laziness and lead to abuse.
> Perhaps, but I don't think that is all that great of a concern. Your
> statement that the "C# community already has come out against overusing
> implicit type declarations" implies (at least to me) that it isn't
> implicit
> typing that is the issue, but overuse of the mechanism. When all is said
> and
> done, the variable is being instantiated as a specific type with all the
> safeguards that entails. I may not know that "Dim s = GetFormattedNumer()"
> will set s to a StringBuilder object, but I am still constrained to using
> s
> identically as if I'd explicitly declared the variable type up front.
>
>
> That said, the more I play with this, the less I'm liking it. What struck
> me
> at first as being a convenient shorthand now seems more like a maintenance
> headache. I may know as the original coder what my intentions were for the
> following:
>
>
> Dim s = GetFormattedNumer()
>
>
> But as someone coming after the fact to maintain the code, it isn't nearly
> so obvious. In fact, I'll run into that problem even if I'm the original
> coder returning to the code six months later. I recognize now that every
> time I come across an implicit type statement, I will have to mentally
> discern the assignment type. It could cost me in time and additional bugs
> in
> the code if I misread the type. The following may be equivalent, but the
> second statement is much clearer:
>
>
> Dim I = 1
> Dim I As Integer = 1
>
>
> So, yeah - on further reflection, I agree that implicit typing is not that
> good of an idea after all.
>
>
> Ralf
> --
> AA #2250
> -------------------------------------------------------------
> * ^~^ ^~^ *
> * _ {| |} {| |} _ *
> * /_``>*< >*<''_\ *
> * (\--_)++) (++(_--/) *
> -------------------------------------------------------------
> Nature is the canvas of creation and evolution but one of
> the brushes. Religion points to the mind of God; Science
> reveals its unfolding. The subjective apprehends knowledge
> while the objective facilitates understanding.
>
> In all things, yin and yang - ever flowing, one into the
> other; always overtaking, always overtaken.
>
>[/color]

Not to offend anyone, but . . . a thousand years ago some ostensibly
intelligent people were having a similar discussion about how many
angels could dance on the head of a pin.

Don

On Fri, 3 Mar 2006 15:04:38 -0500, "CMM" <cmm@nospam.com> wrote:
[color=blue]
>I agree with you wholeheartedly... you hit the nail on the head much better
>than I did.
>Indeed, the problem is overuse I think. Implicit typing while convenient in
>*some* situations, should not become a "standard practice." I am terrified
>that- in the VB community- it will become so.
>
>However, if you look at the LINQ stuff and how that works (IMO it's very
>B.A.S.I.C. "statement" - like.... which we've lost a lot of in VB.NET like
>"Open file For Input As Access... or many of the screen drawing statements)
>implicit typing is very useful and makes more sense.[/color]

Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

re: Some thoughts on VB9

Similar Visual Basic .NET bytes

/bytes/development

/bytes/it

/bytes/about