Debugging Step Into, Over, Out within VB6 IDE closes the class window - debugging

I am experiencing very strange behavior within VB6 IDE whenever the break point hits(Step Into, Out, Over), the class is closed and makes it impossible to debug. Then within window-Cascade i can re-open the class but again when break point hits, the class is closed. Can anyone help please.

Step execution does sometimes behave that way. The reason is that VB is event driven and when an event occurs, then the code behind that event will run, and your code that you are stepping through might NOT be the code that gets run, so things change and code runs while your PAUSED code is still on hold.
When I encounter that I overcome it by using debug.print to send my monitored variables' current values to the OUTPUT window, or if you need more elaborate capability, write a sub that sends the data to a local text file and then invoke that sub as needed, passing into the variables ( and labels ) that you want displayed.
Once debug.print or a logging routine is in place then run the code WITHOUT pauses or breaks. The debugging output will tell you what is happening, in what order etc, so no need to stop the code or risk altering the order of execution.
Be sure to include lots of 'context' data such as : 'Entering SUB_XYZ, Param values are A, B, C... NOW at line 99 in SUB XYZ.... NOW in TRUE side of IF TEST # 1....
Include time stamps on all outputs.
Put your tracing logic only around the suspected problem area, expand from there only as needed.
It's a pain, but it works.

I finally resolved this issue and problem was within Display settings within windows 10. Basically if I apply vertical settings by placing both screen vertically 2nd on top of first then this issue happens,if i apply horizontal settings then this issue does not happen.
problematic settings with vb
settings that does solves debugging issue. VB is so weird and old cannot cope with display settings

Related

Create a visual studio breakpoint that pauses for one second and then continues

The topic says it all. Sometimes i just want to take a quick look and then continue, especially when a code line get hit several times. Can i automate the press-manually-f5-to-continue-after-a-second?
Right click on a breakpoint an select "When Hit...":
You can run a macro like this:
Sub Sleep1s()
System.Threading.Thread.Sleep(1000)
End Sub
Or you can call 11 times {System.Threading.Thread.Sleep(90)} in the message. (Because VS debugger doesn't allow for expression to run for more than 100 ms).
But sleeping this way will block the main IDE UI thread. I don't know is it acceptable for you.

Using VBScript to control an MMC object

Alright, so, I'm working on a script to execute some commands in an MMC Snapin, and I'm not very experienced with doing this kind of scripting, but i've made a lot of progress...the problem I am having, is if I create a new object every time the script runs, it will massively delay my overall script while the snapin and everything in it loads(which can take as long as five minutes). If it could load the snapin content once and then just take control of it as needed, and only create a new object IF there's not one open already, I'll save a massive amount of time when I run the script sometimes 100 times in a day.
The problem is, I'm not entirely certain how to achieve this. I thought, after some research, that it would be GetObject, but when I do
Dim objMMC
Set objMMC = GetObject("", "MMC20.Application")
It seems to create a new mmc window with no snapins loaded, rather than get the existing one with snapins loaded that I want.
Any advice? Am I just totally off base here, using completely the wrong command, or is there some simple change that I can make to fix this?
Edit:
Is there some weird workaround way I could achieve this, like storing an object to a temporary file so i can at least reuse it through a single session.
I'm in a weird situation where I am trying to add functionality to a powershell script and couldn't find a way to do it directly in powershell, so i'm setting up a vbscript to do one piece of it and calling the vbscript from powershell. I already had to do a lot of research to figure out how to do it in vbscript(and i'm still not sure about all of it) so i guess before i go any further, I'll try to figure out if this is even viable(in vbscript or c# or c++ or any other language someone could suggest)...
What i want to do, overall, is check if an MMC window is open that contains a DHCP snapin. If so, assign it to a variable. If not, create one.
Then it will read from a csv or txt file, and use the values to determine what node to navigate to within the snapin(DHCP>ServerName>IPv4>ScopeName>Scope Options).(I've mostly solved this part in vbscript, but don't know how to do it in C++ or C#)
Finally, I need to be able to execute a right-click menu item to "configure options", navigate the tabs of the popup that comes up, enter a value, and apply the changes/hit ok to close the popup. Worst case, If I can't do it "normally" by actually sending commands to the objects themselves, this part I can do with imitating keystrokes, but i don't want to do that if it's avoidable because it's sloppy.
Then, I basically will just need to somehow alert the powershell script that i'm "finished" so it can continue, or give an alert if there's an error.
I'm not asking anyone to walk me through all this, I just want to know if any of those steps aren't viable as i've described them, especially if I'm going to have to switch to c++ or c# to achieve the first part and therefore relearn the commands needed.
... and only create a new object IF there's not one open already ...
No, this is not possible in VBS, you need to do
Dim objMMC
Set objMMC = WScript.CreateObject("MMC20.Application")
if I create a new object every time the script runs, it will massively delay my overall script
In this case is the VBS the wrong language, you need to use C# or C++ executable.

How to use netBeans debugger to run for an amount of time

I rarely used the netbeans debugger but I have this bug in my program which I'm trying to get to the bottom of. Basically my program searches a binary file (4.5gb) for a seqeunce of bytes and writes it to file. However, the programm always stalls at this specific point in the file when reading near halfway of the file (~2gb). They way I using the debugger if putting a breakpoint and keep "continuing" the debugger until it reaches that point in the file but it's going to take forever to reach the 2gb mark. I'm guessing there's a better way to use the debugger which I'm not aware of. Any suggestions?
Netbeans supports conditional breakpoints. If you add a breakpoint via the menu "Debug / New Breakpoint" (or just hit Ctrl+Shift+F8) you can specify a condition (either how often the breakpoint has to be hit until it execution is halted on this breakpoint or an expression).
You could keep a count of how much data you have processed, and add an if() block which checks whether you are up to the 2GB mark. Put a dummy command inside the if() block, and add a breakpoint on the dummy command; this will only be reached when you have processed sufficient data.

is there a way to track the values of certain variables after the end of a program in visual studio?

i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.

How can I force VB6 to enter the debugger from the execution of a program without a break point?

I'm trying to watch the execution of a VB6 app and I'm running into an issue because once I enter the debugger and then hit Continue, it no longer lets me step through the code until I hit another break point. I want to be able to execute a program without stepping through something until I hit a point where I want to watch it execute. Ideally this would be something to the effect of holding a key down while I pressed a button to 'step into' that function.
Thanks in advance!
[EDIT]: I'm aware that I can use break points to stop the execution. To be more clear, the problem is that I don't know where the execution is going to, so I can't set the break point there (because I don't know where there is). That's why I essentially want to be able to say, 'after this next thing that I do, break, no matter what'. It sounds like this functionality does not exist, but I'm still keeping my fingers crossed.
While the code is running, press ctrl+break (or the 'VCR pause' button in the IDE) then press F8 (or choose 'Step Into'from the Debug menu in the IDE) to continue running the app. The next action will cause execution to break.
Note that the which causes the break will not always be the one you hoped it would be. Particularly annoying is the _MouseOver event which prevents you from doing a mouse down or a timer firing quckier than you can perform your action. Some breaks may even be fatal as regards running your app e.g. where Windows messages have been hooked (subclassing). Also consider there may not be an event handler in code (yet) for your action where it can break. But usually this technique identifies where you should be setting your breakpoint.
There is a Stop statement available for use in VB6 that will drop to the debugger when the statement is executed from code running through the IDE. (Just be sure to remove the all of the Stop statements from the code when compiling a release build.)
There are several techniques you can use.
These two have been mentioned
Using F8 and Shift-F8 to step through the program
Adding Stops (and later removing)
Others
Use a global variable to create a collection. Use it as a stack and have the subroutines you are interested in push and and pop strings. Conversely don't pop anything and you will get a trace.
Use Watches to monitor and break at selection conditions. You can setup just about any condition to break.
Make a Global String and have your procedures set when you enter them. Monitor it through a Watch.
Use Debug.Print in your code. Also Unlike Stop you can leave these in without effecting the production code.
Use the File System Object to create a text file to act as a log.
Sometimes problem only occurs in the Complied version then you need to use MsgBox or log to a text file. MsgBox can alter the behavior of complex user interactions with forms.
These are all techniques I used in debugging an application. If I had to monitor an application I would use Debug.Print. If that doesn't do the trick compile then log to a text file.
If you have something really complex going on then I recommend moving all your code out of the events into classes implementing a Command Pattern. Your commands classes should interact with the form through and interface.
In the Execute method of the command classes you will something like
<save the current state>
<Do your original code>
<save the modified state>
<push the command onto a stack>
What will happen is that you wind up with a list of all the commands you have executed (even things like mouseover) with the state they encountered and the modified state. You can then examine each object in turn to see what is happening. This is nearly the equivalent of creating Undo/Redo
Note however things like MouseOver can push a lot of classes on the command stack so you will have to structure your tests carefully or be overloaded with information. Remember you can always skip pushing the command onto the stack.
The downside of using commands is that you gone beyond debugging into redesigning. You will to decide whether the problem is worth doing this.
You can press the F8 key to step through the code line by line. Alternatively, you can press SHIFT-F8 to step through line by line.
F8 will step you in to a function, where SHIFT-F8 will step you over the function. If you click on the DEBUG menu in the VB IDE, you will see other options too.
EDIT:
You can also put a permanent break point in your code by using:
Debug.Assert False
By doing it this way, the 'breakpoint' is saved in your code. When you compile the app, debug code is ignored.

Resources