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).
Related
I can run a macro under forms, but when I look at the code behind the form, I am not able to step through it all.
I hit the line
Dat = [Forms]![frmMenu]![dtmDate]
and get the error:
Is there a way to resolve this so I can continue to test each step of the macro?
I opened the code with ALT + F11.
I am trying to pinpoint the queries which cause the macro to take so long to run.
You can't hit f5 to run + debug code in a form. You can do this for a standard code module, but not for what we call a class module.
If you wish to debug/step code in a form? Launch the form (normal view). Then go to the code behind, say a button click, and now you can set a break-point.
So, single step, or debug of forms code requires you FIRST load the form as normal. (you can't thus use f5 to run such code). But, you CAN debug as per above.
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 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.
Using Access 2010 I cannot step into the code I have written for a form in Access.
Shouldn't I be able to step through it using the F8 key?
Does this indicate a damaged install of Access?
There are several conditions required for F8 to work.
You cannot be in a forms code module and hit F8 – it will not work since forms code is a class module.
If the code module is a class module, then again you cannot hit F8 when looking at code in that module (so a forms code module, and a code module that is a class object will not work.
Eg these:
Also if you hit F8 inside of a SUB or function that requires “parameters” then again F8 will not work. (since parameters are required).
So code in a class module will not work with F8 since you need to create an “instance” of that class object in code. Of course any routine (function/sub) that creates an instance of the class object will THEN allow F8 to step though such class object code.
And for a form, if you introduce a break line, or place a stop command in the code, then when the code runs, and encounters the breakpoint (or stop command), then at THAT point in time since a “instance” of the object exists, then F8 to single step will work.
So the difference between code/objects that must be instantiated before F8 works needs to be keep in mind.
Thus again, you can use F8 inside of forms code modules (they are class objects), but ONLY when an instance of the object (in this case a form) ahs been created and is running. So F8 can step though such code, but F8 cannot be used to start+run+debug such code until such time an instance of the object has been created.
So function/sub cannot have parameters, and cannot be in a form since such modules are class modules, and as noted you cannot use f8 inside of a class module either.
Try ALT+F11, then F8. Not my normal procedure. I found it by experimentation - pressing keys to see what happens.
You could force and error, like "mxgbox whatever" at the beginning of your class module. When VBA shows you the error message box you can click on "debug" and then continue with F8.
Bring up the VB Editor by hitting Alt+F11 then you can enter a break into any code on a code line - that way the code will stop there, and you can use F8 to step through or F5 to resume and run.
Oh, and if you don't know, you can enter a break by clicking the side panel or by pressing F9 on a particular line.
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.