I must be dumb or something

[James]

I am new to vb.net (I am an old vb6 programmer). I cannot figure out
an easy way to watch variables. In vb6 all I did was right click and
could chose to stop execution when a variable chances as well as how
extensive a "universe" (context) I want it to watch. In .net I must
work in debug mode but I do not see how to stop execution when a
variable changes nor controlling how brad a context I wish to watch.

Any help would be appreciated

 

[geo039]

Try inserting a breakpoint on a specific line and hovering over a
variable or using the locals window when the execution runs through
your application

 

[James]

Thanks but in VB6 you could globally moitor the variable and it would
stop when the value changes so you do not need to know where to place
the stop

Excellent for debugging so i cannot image that MS would drop this
feature


If I knew where the vOn 16 Nov 2006 08:44:15 -0800, "geo039"

 

[RobinS]

I don't think this is available in VB2005, and I really miss it, too.
Either the old functionality isn't in there, or I don't know how to do it.
I've seen this question posted multiple times over the past few weeks,
and nobody ever responds, so I think it isn't in there.

Out of desperation, you could change the variable to a property,
and attach a change event to it. If you don't know how to do that,
re-post and I'll see what I can come up with.

Of course, then you have to take the whole thing back out afterwards.
(Or leave the property in, it wouldn't hurt anything.)

Robin S.
p.s. Old is a state of mind.

 

[James]

Thnaks. This is the first info I got, and I would appreciate if you
could explain how to change a variable to a property and attach a
change event.

PS When I can't find a feature that used to be there I do not think it
is a state of mind but that I am loosing my mind!

PSS Did they also remove the Last Position command that I used to
place on the toolbar also?

 

[RobinS]

Easy stuff first, "Last Position", I assume, is the command
that went to the last place you were. You can hit Ctrl-Hyphen.

Also, you can add those back to your toolbar. Right-click on
the toolbar and choose Customize. Select the <Commands> tab.
Go down and click on <View> in the left window.
Find the "Navigate Backward" and the corresponding
"Navigate Forward" buttons on the right-hand side.
Drag them up and put them on your toolbar somewhere.

I'll post some code about the property changed event stuff
later; I'll have to dink with it and make sure I get it right.

Robin S.

 

[James]

Thanks. I looking forward to your next post

Easy stuff first, "Last Position", I assume, is the command
that went to the last place you were. You can hit Ctrl-Hyphen.

Also, you can add those back to your toolbar. Right-click on
the toolbar and choose Customize. Select the <Commands> tab.
Go down and click on <View> in the left window.
Find the "Navigate Backward" and the corresponding
"Navigate Forward" buttons on the right-hand side.
Drag them up and put them on your toolbar somewhere.

I'll post some code about the property changed event stuff
later; I'll have to dink with it and make sure I get it right.

Robin S.

 

[Gadget]

Thanks but in VB6 you could globally moitor the variable and it would
stop when the value changes so you do not need to know where to place
the stop

Excellent for debugging so i cannot image that MS would drop this
feature


If I knew where the vOn 16 Nov 2006 08:44:15 -0800, "geo039"

This has been changed now to be breakpoint related rather than variable
related. Just click on the left of the window to set a breakpoint, then
right click the breakpoint and select the condition you want to test for.

I know this seems less powerful than a global "Has this variable changed"
type of monitoring, but variables are handled very differently in .NET to
VB6.
If you have a variable that is used global enough to justify this type of
monitoring then it may be better defined as a property, which would also
allow you to put breakpoints on the set method and will act exactly the
same as the old VB6 monitoring.
You can change any variable to a property, so it's easy to reproduce this
method of debugging.

Cheers,
Gadget

 

[James]

Yes but you could also monitor properties of controls (which are
always global) so say when text1.txt changed you could stop the
porgram. Can you do that now?

 

[Chris Dunaway]

This has been changed now to be breakpoint related rather than variable
related. Just click on the left of the window to set a breakpoint, then
right click the breakpoint and select the condition you want to test for.

The problem with this method is that the variable may be changed in a
place that is different that where you place the breakpoint, so it may
never be hit! I think the OP wants his code to break at the point
where a variable changes, and as Robin pointed out, this is not
available in VS2005 except in native code.

 

[RobinS]

No problem. It'll be late today, or some time tomorrow.
Overbooked today. I haven't forgotten you.

Robin S.
--------------------------------------

 

[James]

Thanx

No problem. It'll be late today, or some time tomorrow.
Overbooked today. I haven't forgotten you.

Robin S.

 

[Gadget]

Yes but you could also monitor properties of controls (which are
always global) so say when text1.txt changed you could stop the
porgram. Can you do that now?

As I said, variables are handled in a very different way now, so there is
no built in debugger method, but you will almost certainly find an
OnXXXChanged event on most third party components that is fired when XXX is
modified, and put a breakpoint there.

Incidentally, controls are not always global. This is a decision you make
at design time, and you can set in the component properties. Even then, the
form on which a control exists is not global, as unlike VB6 there is no
Form1.TextBox1, only myinstanceofForm1.TextBox1.
Besides which, I don't believe any of my developers would ever be daft
enough to write something like myinstanceofForm1.TextBox1.Text = "Fred
Bloggs" from another form! You would expect to see a 'CustomerName'
property added to the Form1 and the value set via that, or preferably a
'Customer' property that takes a Customer object, and that method sets all
the TextBox's etc.
This sort of 'improved' coding technique is much easier in .NET than it
ever was in VB6, and makes the need for "What changed this property?" type
features largely redundant.

I know that there are times when I want to know, for example, who is
setting the Text property of TextBox1 to say "Bog Off", so I just open the
form code and search for "TextBox1.Text =", and place a breakpoint on each.

It's certainly not as simple or friendly as the VB6 equivalent, but to be
honest I've never missed it since first moving to .NET.
Many of these 'nice' VB6 features encouraged very bad practices such as
'global' writing to variables and controls, which is also why VB6 got such
a reputation as a 'bodge' programming language. I worked with VB for 10
years, so I know exactly how easy it is to write a very bad program in VB6.

Interestingly enough, this type of issue is the main reason I always
recommend VB6 based companies move to C# instead of VB.NET, as it removes
the tendency for developers to persist badly structured coding techniques
into the new environment

This is not any sort of a 'This is better than That' type of posting, it's
just an observation, and in my opinion a semi-justification of Microsoft's
decisions regarding the .NET debugging environment.

Cheers,
Gadget

 

[James]

You raise some excellent points. Thank you. Hopefully you can teach
an old dog( me) some new tricks. Again thanks.

 

[RobinS]

I think it's unfair to say that C# promotes better coding
practices than VB. It's completely dependent on the programmer.
Because VB was so much easier to learn than C++, a lot of
people were able to pick it up and start programming without
learning the foundations of best practices and so forth.
That's hardly the fault of the language.

I used to use global variables in VB6, and I don't any
more since moving to .Net. So apparently VB6 programmers
*can* learn to do things the right way.

One of my pet peeves is people who don't name the same
field with the same root all through an application. So
you can have ProductCode, Product_Code, ProdCd, ProductCd,
etc., or you can use ProductCode, ProductCode_Temp,
ProductCode_forOrders, etc. I just about pulled my hair
out trying to get a couple of people who worked for me
to understand the benefit of being able to find all of
the places where a field was used. Grrrrr.

All of that said, I still miss the ability to have
an automatic breakpoint when the value of a variable
changes anywhere.

One more comment: You can certainly obfuscate better
in C# with all those pesky semicolons and curly braces
and parentheses. ;-)

Robin S.
-------------------------------------------------

 

[RobinS]

I have a program that does some directory searching,
and it uses an field called TestCount that is defined
as an integer, and then calls into a recursive routine
using that field.

I took out the definition of TestCount as integer,
and added a property to my code.

Private _TestCount As Integer
Public Property TestCount() as Integer
Get
Return _TestCount
End Get
Set(ByVal value as Integer)
If _TestCount <> value Then
_TestCount = value 'Put breakpoint here.
End If
End Set
End Property

I put a breakpoint on the line noted above.
Every time the variable is set, like

TestCount += 1

it does it through this property, and stops
at the breakpoint.

I don't know what kind of variable you are looking at.
If it is one used in one module or class, you'd want
to add the property there.

The other thing you could do is raise an event
instead of putting in a breakpoint, and handle it
somewhere. I can figure this out if you just
really want to do it, but it seems kind like
beating a dead horse.

If you are trying to track changes to the information
in a control, like a TextBox, that's a whole different
ball of wax -- most controls offer a change event
that you can subscribe to.

Does that help?

Robin S.
-------------------------------------------

 

[Gadget]

I think it's unfair to say that C# promotes better coding
practices than VB. It's completely dependent on the programmer.
Because VB was so much easier to learn than C++, a lot of
people were able to pick it up and start programming without
learning the foundations of best practices and so forth.
That's hardly the fault of the language.

I don't think it's unfair, but it's certainly a controversial subject
I think it's undeniable that with VB6 it was very easy to write a very bad
application, and relatively tricky to write a well structured application
(lack of inheritance and other OO concepts), while with C++ it was so
difficult to write *anything* that only more advanced developers tended to
attempt it.
It's a fact that there was an enormous number of low-skilled developers
writing very poorly coded programs in VB6 by 2002, which shows how good VB6
was at bringing programming to the masses, but it did introduce a problem
when VB was made more structured. So how do you train these people to code
in a structured manner? If all you have is a hammer then everything looks
like a nail, so for so many developers whose skill was their VB6 knowledge
it was far easier to try and apply those 'skills' unchanged to VB.NET, and
perpetuate the poor programming techniques.
That is why I suggest people move to C#, not because it's a better language
(as it's almost identical in all but syntax), but because it encourages a
mindset shift. I was a VB6 developer, learnt C# from a book, then spent 1
year using exclusively VB.NET (because the VS2002 VB.NET editor was so much
nicer than the C# one), then moved to C# when VS2003 came out with a much
better C# environment and I realized it was more concise when doing
strongly object oriented code.
Hence I am not a C# zealot, and am happy to use whatever is best for my
requirements

Cheers,
Gadget

 

[RobinS]

Well, that's fair enough, I do understand how a lot of people
are out there who can't really program well. I guess the difference
would be how many of them want to. When I moved to .Net, I stayed
with VB because I still think it's easier to read then C#, and I
can see more LOC because I don't have all those lines that
are blank except for curly braces. ;-) It was important to me
to embrace the new technology, so I learned how to do that in an
appropriate manner.

I would argue that someone could write code just as bad code in C#
as they can in VB, but this may be something we won't ever agree on.
I think it was harder to get into trouble with VB6 then it was
with C++ *because* it's more removed from the complexities.

The great thing is, we don't have to agree with each other. I
can go on writing structured code in VB, you can go on writing
structured code in C#, and we'll both continue to work.
Ain't it great?

Robin S.
------------------------------------------------

 

[James]

Thanks

 

[Gadget]

Well, that's fair enough, I do understand how a lot of people
are out there who can't really program well. I guess the difference
would be how many of them want to. When I moved to .Net, I stayed
with VB because I still think it's easier to read then C#, and I
can see more LOC because I don't have all those lines that
are blank except for curly braces. ;-) It was important to me
to embrace the new technology, so I learned how to do that in an
appropriate manner.

I would argue that someone could write code just as bad code in C#
as they can in VB, but this may be something we won't ever agree on.
I think it was harder to get into trouble with VB6 then it was
with C++ *because* it's more removed from the complexities.

The great thing is, we don't have to agree with each other. I
can go on writing structured code in VB, you can go on writing
structured code in C#, and we'll both continue to work.
Ain't it great?

Oh absolutely, and in fact our current main application was written in
VB.NET, and I simply ran it through a VB.NET->C# converter and... yes, it's
still well structured!
If most VB6 programmers coded well structured code then we would never
behaving this conversation
Interestingly enough, VB.NET is easier to read because you have a VB6
background, as it was for me. I now find it unfamiliar and find c# easier
to read. My father has never used either so which would he prefer? Neither,
because he doesn't care, so I'm not big on the old "this is more readable"
arguments

Anyway, interesting discussion, but back to the grindstone for me... 34degC
outside here today, so think I'll stay in the office for a while

Cheers,
Gadget