Hello all,
this has me quite baffled as I dont even know how to even search for a solution to this.
Basically the problem is that when I'm debugging, after I stop the code in a breakpoint, the debugger can only go line by line and seems to not be able to "Run" (with F5, just continuing executing the code) or "Run to Cursor" to execute the code until the position the cursor is.
This makes of course very difficult the debugging, especially in cases where you just want to skip over a for-loop with 300000 iterations and not go through it one by one...
I have somehow found a workaround, although not really: I can set a breakpoint at some point down the code and select "Step Out" (Ctrl+Shift+F8) and the program will execute until the next breakpoint. This is far from ideal as I need to be setting and removing the breakpoints instead of just placing the cursor where I wanted the program to go and click Ctrl+F8. This operation is something I probably do hundreds of times while I am debugging and now I just go so much slower.
I wondered if any of you encountered this problem and know how to fix it or change this behaviour?
I should mention that the issue came when I changed my computer for a new one. I'm using Microsoft Visual Basic for Applications 7.1 within MS Excel in Microsoft Office 365
Can anybody tell me if there's a way to modify Android Studio's presentation order for code completion?
Writing Dart / Flutter code and whenever I want to print() something to the console, the print() function is second in the list (behind Icons.print, of all freaking things) and I am constantly forgetting and having to undo and step down one place in the list.
It's terribly inconvenient and frustrating. There is another example that constantly drives me batty too, but I cannot remember what it is right now. Would be wonderful if there were a way to modify this in some way.
Thank you in advance, for saving my sanity!
Question 1. Details the shortcut keys
(F8): Step by step debugging. What are the special features and scene applications?
(F7): What is the difference between step-by-step debugging and F8 function? What are the special features and scene applications?
(alt+shift+F7): It can also be debugged step by step, as if you can skip the entire loop directly, what special features and scene applications are there.
(shift+F8): It feels like the end function function, but it seems to only end the loop or function, etc., and what special features and scene applications want to inform.
( alt+F9): It should be run directly to the mouse position.
(F9): Code reset, F9 seems to be reset debugging, but some people on the Internet said to enter the next paragraph of code debugging, I tried not seeming.
What is the difference between the above 6 kinds of debugging.... Especially the first two I feel no difference. I hope that good people can introduce through typical code examples and screenshots... Thanks.
Question 2.The (alt+shfit+F7) button is grayed out and cannot be used. Why? This function should be code reverse debugging!
Screenshot of the problem:
enter image description here
This has been happening increasingly, when I have a sheets.add or sheets.delete in excel VBA. After searching and searching I finally found the official Microsoft support page on it. My question is, does anyone know why I could have stepped through this code just fine over and over, and then all of a sudden it starts doing what Microsoft says it would always do, and is there a way to fix it?
Sub foo()
Sheets.add
debug.print "sheet added" 'breakpoint here
End sub
It's as simple as that. You won't be able to recreate it, because the issue I'm asking about is the fact that it doesn't happen at first. It works just fine over and over then randomly presents the error described in the linked Microsoft support page.
Check if Microsoft Visual Basic for Applications Extensibility is being referenced in the project.
You can check that in the Tools/References Menu on the Visual Basic window of the project.
Referencing Visual Basic for Applications Extensibility prevents the program having its execution suspended:
Excel helps says specifically:
A change was made programmatically to the project using the extensibility (add-in) object model. This prevents the program from having execution suspended. You can continue running, or end execution, but can't suspend execution.
You are unable to step through code when making changes to the project (dynamically eg using InsertLine etc). the code can be run but not stepped through.
Deleting certain objects including ActiveX objects actually changes the VB project. It took me some time to realize that the following line of code prevented the VBE from entering break mode:
Excel.ActiveSheet.DrawingObjects.Delete
If you can identify the code causing the issue, and the order of operations isn't important, move it to the end of your script.
Here are a few suggestions which are not fool-proof,
Firstly, verify that the error does not occur if a breakpoint is not set.
If it doesn't, try a few other things:
From the VBE Debug menu, "Compile VBA Project", it's worth a shot.
Delete the line entirely. Run the code. Then put the line back in and try again with the breakpoint.
Add a DoEvents statement after the Sheets.Add
Use a MsgBox instead of a breakpoint on a Debug.Print. With the message box displayed, attempt to manually break using ctrl+fn+End. (At this point, "breaking" isn't necessary but it would be interesting to see whether you can break this way)
Put a breakpoint on Sheets.Add instead; practically speaking, there's no reason to put the breakpoint on a Print statement if you can just put it on the preceding line.
Are there any Addins? If so, disable all of them and re-enable one at a time, testing to see which one may contribute to the error.
Yet another Excel/VBA glitch.
When it happens to me when I click a button running a macro:
I first try to directly run the macro from VBE,
if it fails, then I put a breakpoint at the first instruction of the macro,
if it still fails, I try both,
or, after clicking the button and breaking on the first breakpoint, I do a single step (SHIFT F8) and then I can let debug run freely as usual (F5).
And so far I don't get this error anymore.
Probably not foolproof either but worth a try.
Ran into the same issue, and (as far as I can tell) the only relevant answer here is Answer 5 (i.e. the one provided by Chrisb).
I've been working with vba for (too many) years now, and never encountered this until I had a project that needed vba to delete ActiveX controls. In my case, the 'ActiveX controls' were a spurious result of data copied in from a web page.
Additionally, there appears to be a way around the issue. Using the following code (versus, e.g. deleting the ActiveX as a shape), seems to circumvent the issue:
On Error Resume Next
ActiveSheet.OLEObjects.Visible = True
ActiveSheet.OLEObjects.Delete
On Error GoTo 0
I say 'appears' and 'seems' above as implementing the above solved the issue for me. However, before I implemented same, I had made other code changes and I have not yet fully regression tested for all possible other reasons the problem was resolved. :)
This has happened to me multiple times and this solution works for me.
Run a different macro within the same VBA project.
Then go back and run the same macro that is causing the pop-up message to appear. The message should no longer appear.
I want to get a better idea how a program I have operates, and rather than print the code out and try to see which method calls which method, it'd be easier to just run a debugger that steps through every line.
But manually putting a breakpoint on every line seems a bit laborious.
Is there any option to step through every line of the program as it runs(without manually putting in all the breakpoints)?
So that I could then see, ah MainActivity launches and runs onCreate and I could see it running through the code of onCreate how it then goes to a fragment class's onCreateView method.. and so on.. I want to see who is calling who as it happens and step through.
You don't need to add breakpoints on each line. Just add a breakpoint to the entry point of your application and then simply use the step-in and step-out buttons of the debugger to execute the code line by line.
In order to prevent the debugger from stepping through the code that wasn't written by you, go to File > Settings > Debugger > Stepping and then on the right, click the plus icon with the question mark that says Add Pattern to add the following patterns:
android.*
dalvik.*
com.android.*