debugging on vb.net

A

algea

Newcomer
Joined
Sep 26, 2009
Messages
3
Hi,
İ have a problem with Vb.net development enviroments. İ have exampled a code below to show what i have encountered. When instruction pointer comes to the debug line the form hangs and dont show what setted at debug point. How can i solve this hang problem. I want fastmoving codes like i do at old Vb6 days

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

End Sub

Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
For i As Integer = 1 To 10
ListBox1.Items.Add("Line # " + Str(i)) 'Put debug point here

Next
End Sub
End Class
 
İ'm not exactly clear on what you mean. Are you saying the IDE is working fine, but the form in your applications stops updating? If so, this is normal and expected. If VB6 did any differently, that concerns me.

While your application is paused (whether you hit a breakpoint, click the pause button, or step through code) no code in your application is running. That means it can't update or draw itself. That can be inconvinient when you want to see changes in your application reflected in the UI, but if the UI kept handling messages there would be potential for all sorts of problems.

You don't want code running behind your back while you are debugging. Imagine a control that changes some data in its drawing code. Now imagine trying to debug some separate code that also deals with that data. I wouldn't like it very much if the value of variables kept magically changing on me while I was stepping through code. Or, imagine trying to debug your drawing code.

If you want the form to redraw itself while the application is paused, you can call Application.DoEvents in the Immediate window. The problem is your form needs to be visible when you do this. If you have multiple monitors this is easy, but if not you would need to de-maximize the IDE and cram both your form and Visual Studio on the screen.
 
İt is true but working with complex units only showing values are not enough
you want to see both values and their results at the same time. I have found a simple solution: "using msgbox and conditinal branching"
i really missed vb6 development enviroment tricks
also Application.doevents does not work. İ added and test this code also into code also
Are there any suggestion about the consept
 
Doing a Debug.WriteLine would be far preferable to using MessageBox calls - Debug commands do not get compiled into a release build and do not change the user experience either.

If you have a lot of these message box calls you run the risk of either forgetting to remove them all before releasing the software or while removing them you break the application in some small way by accident.
 
i could not explain my ideas or...
i start programming from vb6 and older so in some case if you sea the results and the debugging variables at the same time your work decrease with a good abstract
vb6 enviroment used to support a good balanced debugging enviroment. I have lots of methods about debugging complex methods in Vb6. But now in Vb.net the forms just hangs and no other methods can be used showing the results or the continue methods.
I ask again if there is a method to release form hang status to show the intermediate results
 
On my machine, Application.DoEvents works as described. What is it that you are trying to debug? Unless you are testing drawing code in a control you are writing, chances are there is another perfectly acceptable approach.

I remember when VB7 came out and we lost edit-and-continue. That, in combination with a new IDE, made it seem impossible to debug. After a while, though, you get used to the changes and work with them. It's not that VB6 debugging is better. DotNet is just a lot different, and a lot better in a lot of ways.

algea said:
I ask again if there is a method to release form hang status to show the intermediate results
Click to expand...
It might not seem obvious if you don't understand how drawing controls works in .Net (and most Windows applications). If a control needs to be redrawn (suppose you change the text of a label), it doesn't just redraw immediately. It queues a message that it needs to be redrawn, and when none of your code is running it will process that message. To the user this appears to happen instantly. But when your program is paused, your code can't finish and it holds up the message loop, so the redraw message can't be processed. So the simple answer is no. (Application.DoEvents processes all the messages, which is why it should force a redraw, assuming there is one pending.)

VB6 might have managed to get around this, but VB6 uses all kinds of voodoo and dark magic that DotNet doesn't.

So you can't do what you want exactly how you want, but if you want us to help you find another way to do what you want and other suggestions haven't helped yet, you can share a little info about what you would like to do and we can probably help.
 
Back
Top