This question is specifically regarding the property get/let code in a class module but I think that the solution will be applicable to any subroutine.
There must be a property that tells vba to step over a function in break mode automatically (even when pressing the step into key/F8). Obviously such a thing exists for built in VB subs, classes and functions since the debugger doesn't step into them but I can't find a way to apply it to my code. What is it?!
It will make my life much easier when debugging.
Along with Shift+F8, there is also a button on the Debug toolbar.
Bonus Round:
If you forget to press Shift, and end up inside of the class anyway, you can Step Out by pressing Ctrl+Shift+F8
And go backwards by right clicking on the line you want to go back to and selecting "Set Next Statement".
One last note, the reason the debugger doesn't step into the "built in" classes is because that code is not written in VBA. It is hidden behind the COM Interop wall and written in an entirely different language all together.
If I understand correctly what you're asking, you need to step over instead of step into.
Try Shift+F8 instead of just F8.
Related
Have created a Macro - multiple subs, functions and forms for Solidworks.
I'm sure the code is dubious but it works when I force it to start in main()
When I add a button in Solidworks to start the macro it defaults to a different sub, which appears to be alphabetical, I get a similar behaviour starting the macro from the editor.
It appears all the subs listed are the ones with no arguments passed in.
Could anyone please guide me on why this happens? I'm sure I could frig a way around by renaming the subs, but don't realy want to.
It appears I was to impatient, again!
When adding the macro button in Solidworks you are given the choice of choosing the sub to run ... as Method
I’m working on a project in access with a series of existing modules. There’s amain module that runs the whole thing, but often there are errors and to troubleshoot sometimes i want to pick a specific subroutine and run that by itself. The problem is, sometimes when i click run>run sub/userform sometimes it gives me a list of subroutines to pick from and sometimes it just runs the whole thing and i can never tell which it’s going to do before i click it. Does anyone know why this could happen? Is it where I’m putting my cursor or something?
Ok, now this works?
well, any code in a code module? You can place your cursor in that code, or even in the debug window, just type in the name of the routine. So, F5 to run the code, or you can as noted even call the code in the routine from the debug window.
eg:
Call MyTestSub("John")
Or if the routine does not have any parameters, then just type into the debug window this:
MyTestSub
HOWEVER!!!
If you open code for a form? Then you can't use F5 to run that code, and if you do, then your get that prompt. The reason for this is rather complex, but a "form" represents what we call a "class object". And you can't just "run" such code, you a have to first create a instance of that class. And even more complex?
Well in theory, you can actually ahve the SAME form open 5 times!!! (and have 5 instances of the form running! So F5, or even just typing in the sub name DOES NOT work for a class module, and that includes code inside of the form.
So, how to debug such code? Well, in most cases, you have to launch the form, and then in code behind, set a break-point. Now go click the button, or whatever.
You can also in theory call + run the code in a form, and you would do it this way:
Call Forms("Test").Mytest
but, the form would have to be open. So, you can't just run code inside of a class module, or forms code module. They are "special" and work different from a standard code module. As a result, F5 to run such code does not work. In fact, the form has to be loaded first. But, even then, hitting F5 inside of forms code modules does not work. You can put in break points, and single step code (and often form events can make that debug process quite a challenge).
I was wondering if there was a way to pass UDF's instantly instead of "Entering" the function during step-through debugging. I commonly use functions that I know are fully working, and I often don't want to enter each one when I'm debugging. This is even more annoying when you pass multiple functions as arguments and have to enter each one before you get a return.
This question came from me frequently using things such as Application.WorksheetFunction.functionName and wanting to create a function that did the same exact thing and would also pass instantly, but with a shorter name.
Is there an option in VBA or perhaps an Application.Setting or Option Setting that I could use for this? The difficulty here would be that I only want this on some functions, not all..
Thank you
1) Put a breakpoint after your function as shown below:
2) Debug using F8 till the line with "myFunction".
3) Press F5 to jump to the breakpoint (by executing the current code).
You can put multiple breakpoints and jump multiple times to the next breakpoint using F5 in your code.
This is an IDE question for Visual Basic 2008 Express Edition. It might be a bug in the IDE, or maybe it's my fault somehow?
My main form is named frmMain and in my application's properties I have set frmMain as my startup object. All of that seems like what a lot of software engineers do.
But while debugging I hit Ctrl + Break, as I have done for years, and I get an behavior in the IDE that I wasn't expecting. Upon doing so, I get the green background text and the green arrow indicating in a tooltip:
This is the next statement to execute when this thread returns from the current function.
Even if I didn't have the designer document open, it automatically opens frmMain.Designer.vb in the editor and hihglights line in green. The line is of course: Partial Class frmMain which is line 2 of the file. (Yes, it's highlighting the second line of the designer-generated code.)
frmMain seems to have fully loaded and it's my startup object. As far as I know, there shouldn't be a "next statement to execute" at all because code should be idle. I don't want to see the Designer.vb document... I want to edit my own code.
What's causing this? Even though my form is behaving just fine, could there somehow be an unfinished aspect of loading the form such that it is "not returning" from a function?
The Visual Basic compiler will add an entry point in your form. The entry point is the standard main function or "shared sub main", which in turn contains the code "application.run(new form)". Since this is compiler generated code there is no source location, so the Visual Basic editor highlights the class definition.
The clue to this is in the call stack. Notice the Main().
Shared Sub Main()
Application.Run(new frmMain)
End Sub
I found the answer on my own:
I checked the "Enable application framework" checkbox in the solution's properties, and all is well!
I believe this issue arose when I was working on experimental code in which I had desired to make Sub Main my startup object. I had cleared the checkbox because doing so is necessary to use Sub Main.
When the experiment didn't pan out I reset the startup object back to frmMain, and my app worked fine. However I had not re-checked the box. I hadn't noticed the change in the IDE behavior for several days (when I needed the more standard behavior) so I had not observed any correlation.
Although checking that box is definitely the solution, it's still not exactly clear to me is what the heck this box actually does, other than cause me to spend a lot of time on StackOverflow.com! ;-)
To others who encounter a similar situation, I'm now quite confident that my settings were not corrupt, and if you're using the Express edition, please don't be mislead by MS documentation which may lead you to believe it's the "Just My Code" option. This option cannot be changed in the Express versions. (But it's not because you can't turn it on -- It's because you can't turn it OFF in Express!)
Thanks to everyone for your efforts.
I'm going to guess that it is trying to show you the equivalent of:
Application.Run(new frmMain)
This is the code that gets generated to startup your form. But in VB.NET this code gets burried. Create a Main() function and change your startup type to that with this line in it and repeat the process. You'll see it highlight Application.Run. That is the method that contains your Windows message pump loop.
I am debugging a VB.NET forms program which calls into properties and methods of a class which is part of the same project.
I put a break point in the form code but when I step through, it does not step into the class code.
Am I missing a setting?
Pressing F11 will take you into the method definition. F10 will step over. F5 will jump to the next break point. Or simply continue with the execution of your application until the application meets another break point on it's execution path.
This can can also be achieved by using actions located on the toolbar and in the context menu when using right click.
Make sure that you are pressing Step Into, not Step Over.