where is the Key in TreeView.NET?

[Tark Siala]

hi
i working with TreeView in VB6, and have good Properity Named (Key)
with the Key i can goto Any Node i know hes Key.

but in VB.NET i can find the Key
please tell me where i can find the key in TreeView.Net...

 

[Herfried K. Wagner [MVP]]

First, please do not make X-posts to groups that are not related to your
question's topic.

i working with TreeView in VB6, and have good Properity Named (Key)
with the Key i can goto Any Node i know hes Key.

but in VB.NET i can find the Key
please tell me where i can find the key in TreeView.Net...

The .NET Windows Forms treeview control doesn't provide lookup by key. What
you can do is storing the key in the 'TreeNode''s 'Tag' properties and then
add the nodes to a 'Hashtable' (use the 'Tag' property's value as key and
the reference to the 'TreeNode' object as value). Then you can easily
lookup a node by its key.

 

[Mona \(Grapecity\)]

Hi Tark,

Firstly,I would like to tell you that it's a gropu for VB6 users and for any queries related to dot net u can check out the following sites
microsoft.public.dotnet.general
microsoft.public.dotnet.languages.vb

As for your query, The .NET Windows Forms treeview control doesn't provide lookup by key. What you can do is storing the key in the 'TreeNode''s 'Tag' properties and then add the nodes to a 'Hashtable' (use the 'Tag' property's value as key and the reference to the 'TreeNode' object as value). Then you can easily lookup a node by its key.

HTH

Mona

 

[Ken Halter]

Hi Tark,

As for your query, The .NET Windows Forms treeview control doesn't provide
lookup by key. What you can do is storing the key in the 'TreeNode''s
'Tag' properties and then add > the nodes to a 'Hashtable' (use the 'Tag'
property's value as key and the reference to the 'TreeNode' object as
value). Then you can easily lookup a node by its key.

Oh yeah... that's SO much better than having a Key property. So much for
".Net is more productive" eh? Gimme a break.

 

[Tom Shelton]

Oh yeah... that's SO much better than having a Key property. So much for
".Net is more productive" eh? Gimme a break.

Hmmm, so one missing property damns the whole platform... Yes, there
are couple of things that are missing, that could have been done better
- but IMHO, overall, .NET is more productive.

 

[Ken Halter]

Hmmm, so one missing property damns the whole platform... Yes, there
are couple of things that are missing, that could have been done better
- but IMHO, overall, .NET is more productive.

If were only one property then I'd say no. This is just one more case of
marketting hype lying to the public. How about this....

My.Computers.Printers.DefaultPrinter.Print("blabla")

....maybe someone in this huge crosspost list can tell me exactly how the
line above is "more productive" than VB6's

Printer.Print "blabla"

 

[Tom Shelton]

If were only one property then I'd say no. This is just one more case of
marketting hype lying to the public. How about this....

My.Computers.Printers.DefaultPrinter.Print("blabla")

...maybe someone in this huge crosspost list can tell me exactly how the
line above is "more productive" than VB6's

Printer.Print "blabla"

My is 2005, so I haven't really played much with that... But, I would
most likely not be typeing all of that anyway. See, I would probably
just add:

My.Computers.Printers to my global imports list or just type:

Imports My.Computer.Printers

At the top of my code file (depends on how often I was going to be using
it) and then all I would have to type is:


DefaultPrinter.Print ("blabla")

 

[smith]

Wow, this is a very sad thread. VB People Fighting with VB People.

We are not the competition, we are not the enemy. VB5 or 6 or 7... It's VB.

Really, it is just that simple.

The real power of Visual Basic is simplicity through abstraction. That is
what made it a big deal in 1992, and that is what lead it to officially
beating COBOL as the worlds most used programming tool in 1998. C# is just
VB with a different language style for those people who never figured out
that "Visual Basic" was lightyears evolved from "B.A.S.I.C"

This is what the whole .Net deal really is all about: The *concept* of VB.
VB folks should be the strongest supporters of the evolution of the runtime
because VB is the parent to this child.

The framework is just a runtime, just like the VBRT/VMs. Garbage Collector?
Nothing new to us in the abstract sense. Power and RAD in one? Nothing new
to us at all.

And the VB7 language is a bit different in some places, mostly
understandable though ... changes had to be made to allow VB developers to
actually get what we had been begging MS for for a lot of years.

But Msgbox is still Msgbox and Dim is still Dim.

This particular silliness of number of Dots is nothing new to any of us.
You and I could make a load of VB5/6 object models that force the VB6
user-dev have to type dots, right? That isn't anything special ... the user
of the object model simply uses WITH (and WITH or Imports in VB7). Not
worth fighting your brothers about.

The enemy to the future of VB is the division between VB dev and VB dev, and
if it continues too long then the winners will be C# and - yes it's Still
True, I got my Borland "switch now" letter yesterday - Delphi.

Pick a version or use both and let others do the same, all usage helps VB.

Just my two cents as a very long-time passionate user of Visual Basic.

Robert Smith
Kirkland, WA
www.smithvoice.com

 

[Landley]

Yuck! That has "quick and dirty" written all over it. Are you a contractor
by any chance?

From a usability point-of-view that is nasty. You would have to iterate
through all the nodes to find the key that you desire!

The best solution is to inherit the treeview, overload the Item property
allowing a key as an argument, and store keys within a collection. All you
have to do then, is return the index of key and use this index to retrieve
the node. There is obviously more work involved here, as one would have to
handle nodes being deleted, sorted etc.

I have done this and it works a treat! I have had no performance issues
with large or small treeview node collections.

Landley

 

[Tark Siala]

hi
yah VB7 not bad for New Programmer , but for old Programmer Using VB3/4/5/6
(Like me) , it's very very bad
new structure of language , Defferent Controls , Can't find Normal Old
Proberties (like Key)

i think i must Satr Learning VB from the First

 

[smith]

It's not a new language. It's VB. It is different in some ways but it's
also very much the same ... like DAO and ADO

I am, technically, an old programmer I started with MS tools with the
release of Access1.0 and my first real work with VB began shortly thereafter
with the release of VB3.

Moving from VB3 to VB4-32 was a big leap and it was hard and frustrating (do
you remember back to that?).

Moving from VB4 to VB5/6 was hard too ... remember moving from DAO to ADO?
It was not a smooth migration. It was frustrating, but it was done by
millions.

Each time the effort and pain eventually paid off in ways that we did not
see when we set out to just make the move. Each time we got closer to the
Visual Basic that we really wanted.

I have found this evolutionary step no different at all.

Honestly. For my background: www.smithvoice.com\vbfun.htm

Robert Smith

 

[Ken Halter]

It's not a new language. It's VB. It is different in some ways but it's
also very much the same ... like DAO and ADO

No one's fighting but B# is *not* VB. Try going to planetsourcecode.com
(http://www.planetsourcecode.com/vb/default.asp?lngWId=1) and just try
downloading any project (with the VB filter set) and open it in B#. Good
luck. Now, fire up VB6 and try to open a VB3/4/5 project. Except for the
16/32 bit differences it'll load and most likely run (what a concept).

Visual Fred
http://www.mvps.org/vb/index2.html?rants/vfred.htm

There are a lot of shareware authors out there. B# requires that you spend
an extra $1500 or so just so the end user can't see your source. That will
kill quite a few shareware authors. The obfuscator that ships with .Net has
been broken into 10 billion hacks by now. VB6 doesn't need obfuscated code.
Just the fact that it's compiled to native machine code means it's already
obfuscated.

The sad part of this post is... there's only one "dotnet" group in the list.

 

[smith]

Instant and complete porting of old code is a valid point ... as was instant
porting from QBasic to VB and VB3 to VB5/6.

I guess it's perception, as most things really are, Ken. And calling it B#
kinda implies that you've pretty much got your mind firmly set to a
position. I too had that position and I might even have had you beat in my
initial hatred of VB7 (http://www.smithvoice.com/adorumination.htm )

Thing is, it hit me differently back a few years when I had been reading a
lot about VB.net but not really, honestly, using it and all of a sudden (I
remember the exact moment, sitting in my office at drugstore.com when
everyone else had gome home) I noticed that probably because I was tired my
fingers were just typing the VB that they had been doing for years and when
I pressed F5 the code ran. It was a "moment".

That's when I realized that all of the scary books and posts that said "You
Can Only Use VB.Net If You Think Like A Java Developer" were rubbish. You
do have to learn a bit of the new object model ... RDO was different from
DAO ... and you will go farther faster if you have a handle on OOP to begin
with (VB5/6 classes are enough ... after all, C+ still isn't SmallTalk) but
it being a completely alien "Language" isn't the case for a lot of folks who
have taken the leap of faith.

..Net is Revolutionary to C++ people, but it is Evolutionary to VB6 people
who used VB6-OOP.

I know there are still folks who swear that ActiveX and OOP and VB6 is just
MS hype that will go away eventually, and for their jobs VB3 with VBXes
still does them fine. As I see it, my perception, having a great background
in VB6 OOP makes the move to VB7 doable and after you've done a few apps you
might start wondering, as I did, what the worry was all about. Plus you'll
probably notice that being really good at VB6 and at least functional in
VB.Net gives you a tangible edge in these transitional times.

And remember, it's not an All or Nothing issue because there's "Interop"
that lets you use .Net components with VB6 and VB6 components with .Net and
that means that porting a full mature VB6 program or system to .Net can be
done either a little at a time or even that the app can be left as-is and
VB.Net can be used to add functionality that VB6 couldn't easily do .

A great example of this is that it is truly simple to make a real Windows
Service in VB.Net, no unsuppported NTsvc.ocx and no VB forms required.
Using VS2003 you just create a VB.Net Windows Service project and fill in a
couple of properties. Then you have that Service run a VB.Net or even a VB6
exe. XCopy the files to the server, call a commandline function named
InstallUtil.exe and your service is running... a true Windows Service.
I'll grant you that that service code would not instantly port from a VB6
example ... because VB6 can't do Window Services by itself. But with this
you have the best of both versions and you did it all with VB.

I like them both, and as the link above shows I didn't start out that way.
I hope you are able to get yourself onto an Interop project some time soon
so that you too can get feel that "moment".


And if this stuff about making VB6 and VB7 work seemlessly together
interests you even a little bit, I think you'd like the book by Rockford
Lhotka (a VB6 God) called "Professional Visual Basic Interoperability: COM
and VB6 to .Net" It's not about porting or leaving VB6 behind, it's about
using both together for more VB power. It only came out with a .Net 1.0
edition but nothing in it has really changed for .Net1.1. You know Rocky's
style so you know that it's directly aimed at us professional VB people and
it's not boring or fluffy. If it's not at your local store then get it from
amazon, they have a deal on it right now becuase of the death of WROX press.
I think you'll intrigued by the potiential benefits you'll see explained in
that book.

All the best.

Robert Smith

 

[smith]

Oh, obfuscation. Another huge, huge worry when you start out. But for
*most* VB developers who do corporate work it's not really a deal-breaker,
right?

However, if you aren't a corporate dev then just don't use the free version
of Dotfusctor that comes with VS.

If you truly need obfuscation ... truly, as in you are a for-retail dev,
then go to the Standard Edition (I use that version myself when my projects
go outside a corporate environment) or to the Professional Edition. Or use
any of the other obfuscators that are out there, or even go to Thinstall
(that is a cool tool: www.thinstall.com )

Yes, they cost money but if you make money from your work then you can claim
the investment in your taxes and having the proper tools is the cost of
doing business in any business.

Look to the "real" vendors to see how they obfuscate (such as ComponentOne
of Infragistics or even the good little guy Rebex www.rebex.net. Just get
one of their controls and run it through Reflector from
http://www.aisto.com/roeder/dotnet/ and see how much code a bad person can
really steal from these reputable companies )

All the best, again

Robert Smith
Kirkland, WA
www.smithvoice.com

 

[Ken Halter]

Instant and complete porting of old code is a valid point ... as was
instant porting from QBasic to VB and VB3 to VB5/6.

I guess it's perception, as most things really are, Ken. And calling it
B# kinda implies that you've pretty much got your mind firmly set to a
position. I too had that position and I might even have had you beat in
my initial hatred of VB7 (http://www.smithvoice.com/adorumination.htm )

Well.. you've done a fairly good job of "prodding" VB6'ers over to B# but,
imo, that still doesn't mean B# is VB. Regardless. imo, B# is currently
about as useful as VB2 was (I'd say VB1 but there's already been a couple of
B# releases). As long as the framework is still running on top of the OS (as
Win3.1 still ran on top of DOS), it'll be dog slow and buggy. I prefer to
leave it to others to work with until it's mature. Let everyone else deal
with the "when I did this, the IDE crashed... but that was expected" type
problems. I have too much work (in VB6) to do. The company I currently work
for has zero interest in re-writting 20+ years worth of code just so they
can say that it't ".Net compatible". They just want something that works. It
doesn't matter one little bit if there's a ".Net" in the name. We don't do
database/web or any of the other types of apps that .Net was designed for.

fwiw, I plan on using B# to learn my way around the framework. There's very
little evidence that anything "professional" will ever be written in B#. I
can point you to dozens of component vendors that claim that their
components are "100% C# authored". Not one that I've found claims to be
"100% B# authored". B# is still as much of a "toy language" as VB was/is as
far as MS and everyone else is concerned.

btw... my reference to "B#" vs the various nicknames for "the flavor of the
month.Net" is not a put down to the language. There absolutely needs to be a
way to tell them apart. VB.Net, as people refer to it in some groups, is
already dead. There is no ".Net" in the name anymore. VB <> B#, which means
we need a way to tell them apart. VB2005 will soon be released. It's just a
matter of time before people start calling that VB5. Just try searching for
VB5 samples and you'll see a problem. Try entering ".Net" in any search
engine. The results are worthless due to the .Net domain names. B# syntax is
closer to C# than it is to VB so B# is a great name and one that we've
suggested many times.

As long as people are complaining about B# benchmark results when compared
to VB6, and I have an OS that supports VB6, I'll be using VB6.

 

[Ken Halter]

Oh, obfuscation. Another huge, huge worry when you start out. But for
*most* VB developers who do corporate work it's not really a deal-breaker,
right?

However, if you aren't a corporate dev then just don't use the free
version of Dotfusctor that comes with VS.

My point exactly.... Something that no one ever had to worry about is now a
huge worry and will cost developers dearly (so much for about 60% of the
shareware market). No thanks. I like compiled code. Gave up P-Code quite a
few years ago.

 

[smith]

C++ makes the second-fastest code out there and MASM makes the fastest ever,
right?

Well, I can make VC++ on an HT box go slower than VB for DOS on a 286
because I don't have a lot of daily experience with VC++.

You're an MVP Ken, you know that a dev's experience with a specific task at
hand is usually what makes the biggest difference. And because of your
certified qualifications and experience I'm sure that you'll agree that a
VB5 person was faster up to speed with VB6 than a person whose very first
look at code was the VB6 IDE, and extrapolating on that I think you'll give
the nod to the idea that getting some *real* experience now with VB7 is a
great way to be floored by running the same code in just a few months using
the release version of VB8. I can't make blanket statements, but I can give
this example:


"When I ran this code in my environment with ADO.NET 1.1 and Visual Studio
2003, the execution time was about 30 minutes. With ADO.NET 2.0 and Visual
Studio 2005, I had an execution time of approximately 40-50 seconds!"
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnadonet/html/datasetenhance.asp


I wish it weren't true but I really have to get to work . It's been a
great discussion and I thank you very much. (and thanks for taking a look at
my humble vb site, ther are a lot of "VBClassic" things there that I am
quite proud of)

Robert

 

[Bob O`Bob]

Oh, obfuscation. Another huge, huge worry when you start out. But for
*most* VB developers who do corporate work it's not really a deal-breaker,
right?

Amazing how easily the faulty assumptions creep in...

I'd estimate more than half the people who read that will think
that you are asserting that "most VB developers" do/did "corporate work"
And many of those readers will just accept it without evidence.

Eventually it becomes "everybody knows that..."




Bob
--

 

[smith]

Show me the numbers, Bob. ;-)

Amazing how easily the faulty assumptions creep in...

I'd estimate more than half the people who read that will think
that you are asserting that "most VB developers" do/did "corporate work"
And many of those readers will just accept it without evidence.

Eventually it becomes "everybody knows that..."




Bob
--

 

[Lloyd Sheen]

As a long time (I got VB 1 at MS show in Long Beach) VB developer I have to
say that the transition is mostly painless. I got a good book and installed
VS 2003. Within a day I was up and running. Some of the VB6 projects would
not fully upgrade to VB.NET but the info in the upgrade output gave me most
of what was required.

Things that I had trouble with :
New methods for layout. Adding new controls after a form was "complete"
was often an exercise in futility. Getting things to look right took a
procedure (manual) to get things right. Once you get the dock and anchor
then you loose much of that wonderful code used for form resize. There are
new controls for this in VB.Net 2005 so it is easier.

In VS2003 you don't have edit and continue. You can set the IDE to
allow edits but they don't take effect until you rebuild. This is another
thing fixed (at least in VB Express).

Not really trouble but exactly what the poster is talking about. We had
lots of code for filling treeviews with nodes with a key. This allow the
easy code navigation in the treeview. That and control arrays which after
using VB.NET for a year are totally out of my way of thinking right now.

Now as a big plus the DOT.NET framework provides many classes which we had
to create ourselves in VB6. This provides a cleaner interface to windows
thru managed code so less runtime errors.

And speaking of errors, as a C++ programmer as well it is good to see VB.NET
take the "try ... catch ..." error approach. This is much easier to deal
with than what was in VB6.

Just a few thoughts. I have not yet seen any reason to stay with VB6 or non
managed code. Everything including data access is faster. And I even
created an ASP.NET ecommerce site. This would have been way out of my
league using the tolls available prior to DOT.NET.

Lloyd Sheen