Consider the block of code shown in the image below:
There is the one pesky black/'this line of code is not covered by any tests' dot.
Anyone able to shed any light on how this is not covered by any tests, considering it is referring to the closing brace of a foreach loop?
If the rest of the loop is covered (all green), surely the end brace is hit when exiting foreach?
I never used NCrunch, but from my experience with other code coverage products I would guess that you do not have a test case where the loop is exited the "regular" way without hitting the break statement.
Related
Short Question:
How do you debug a large Global.MPT file?
Currently my script crashes when I try to open it from the toolbar. It appears the usual, not very helpful, error message regarding the automation error. When this happens I start the individual components by pressing F5 in the VBA window and at the latest then I find the erroneous line.
Now my code runs as it should but I can't find the error that the compiler* has.
How do you deal with this problem?
*Is it a compiler error?
Found a Solution here.
I didn't know that you can compile the code manually.
It showed that i missed to remove a call for a deleted Sub.
I hope I can explain my specific annoyance clearly enough:
Quite some time ago, IntelliJ introduced a feature in the run console to parse the content of the output and would try to print a nice tree structure on the left. However, its default behavior of jumping to the error was very annoying. To illustrate my point:
When it starts normally, the full console output is available in the right panel. However, when things happen, or, in my case of gradle run, when I simply stop it, IntelliJ would jump to the specific block of output only with the error:
Note, in the second screenshot, that there is no scroll bar on the right side of the right panel, and thus I cannot scroll up to view the actual run logs. I have to click the left panel's top element in the tree to be able to view all logs.
The locking to a specific block of output is nice to have, but I am happy without it too, as before it was introduced. But the default jumping to that block is annoying and irritating. Almost in all cases I started and ended a run like this, I have to click the left panel to view the whole log -- this "Build cancelled" error block is of no use at all. And when it's jumping to an actual exception, majority of the time I'd need to look around its context for the cause, which requires me to re-orient myself in the log flow where the block was at. This is very counter productive for me.
I have been assuming IntelliJ should provide an option to either not jump to the error by default (leaving the full log available in the right panel), or to disable the whole console output parsing as a whole.
I have not been able to locate a setting for either of this. Does anyone know if that's possible?
We are working to fix that. Please vote and follow https://youtrack.jetbrains.com/issue/IDEA-241844
I have a program in visual basic that prints some large reports, sometimes with hundreds of pages. There is a lot of encapsulation here, but it boils down to us using the PrintDocument.Print() command to print the document. When it prints, it prints the form feed characters as up arrows (in windows 10). Is there anyway to get these to print as blanks, and just have them start a new page?
Let me know if you need anymore details. This is my first Visual Basic experience and I'm not sure what info would be useful.
Okay, I don't know if anyone else will encounter this, but I fixed it, so maybe my method will help you. There is a PrintPage event handler that fires off when you are printing, and basically it's just a matter of reading a string up to the form feed character, substringing that off to another string and then printing that other string, then culling it from the original string. Making sure you remove the vbFormFeed character from each page.
so i have got a problem programming micro:bit. I code it in internet page, then download the hex file and transfer it into the micro:bit. On the internet simulator everything works. Apparently when i transfer it to micro:bit code is not working. The code is really simple, it looks something like this.
animation repeats while variable is 0 (this part works perfectly)
A button makes the variable 1, B makes it 2 (this part works)
when variable is not 0, it breaks first animation loop. (this part also works)
then goes to second loop which repeats while variable is NOT 0 (it will never be a 0 because there is no button which makes variable 0) so it repeats for ever (this works)
in second loop, there are 2 more loops. First repeats when the variable is 1, second when the variable is 2. That makes me able to switch between these 2 loops any time i want. (Problem appears here: i am in loop 2 for example, i cant switch to first loop and otherwise.)
All these errors occurs in micro:bit robot, when code is transferred. In internet simulator code works perfectly. Is it possible to do that code in micro:bit, have i reached limit? Or is robot defective? Thanks for answers and inform me if something is not clear.
This is of course very hard to debug without seeing any blocks/code as I don't know how you are detecting the buttons being pressed when in the second loop.
However, this may be a scheduling issue due to the way you are changing the variable upon a button being pressed. Perhaps consider restructuring your blocks such that they are more event driven, utilising blocks such as on button A Pressed a bit better, infinite while loops are always best to avoid. Also, maybe consider putting a pause(100) in the while loops.
Hope this helps ;)
Edit:
OP confirmed that the pause(100) worked (see comments of this answer), demonstrating that it was a scheduling problem!
For those who are interested ;)...this is because the CPU is busy executing the while loop and doesn't have time to think about the buttons being pressed. The pause(100) allows the CPU to rest for a bit and not think about the while loop, giving it the time needed to deal with the button press. This is known as Cooperative Scheduling!
You can find out more about Cooperative Scheduling at:
https://www.microbit.co.uk/device/reactive
If your code looks like this, you will never be able to change your state variable. You'll get stuck in one of the inner loops, with no option to change the control variable.:
while (unset):
Animate
Check for button
While (set): // Intend to be stuck in this loop forever
While (one):
Do first
While (two):
Do Second
What you need is to be able to update your state:
...
While (one):
Do First
if (button_b.was_pressed()):
state = two
...
This still isn't perfect, you might want to think about what happens if the buttons are pressed in 'unusual' sequences. The simulator should be identical, but there might be something unusual about the way that button presses are handled and your code that have broken the simulator. If the simulator really is broken, you'll need to share a testcase with the micro:bit team.
I am trying to develop a little macro for PowerPoint using VBA. However, the "Development Environment" is an absolute nightmare!
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there! So I am currently using MsgBox to generate debug messages. :-(
What's also really bad is, that errors in a macro always crash PPT. So one has to wait, until it is gone and then one has to restart it again and get rid of all the Recovery attempts. This always takes ages!
If I set On Error Resume Next it doesn't crash - at least not as often - but then things just silently don't work and I can't see what and why things go wrong (unless I plaster the code with MsgBox calls, but that requires 100'000 clicks during each execution).
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode. So this debugging is driving me nuts!
Is this really the only possibility or environment to develop VBA code in? At least some idea re. debug output, anyone?
M.
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there!
At the risk of sounding insulting (which I don't intend!) do you have the Immediate window open? While in the IDE, press Ctrl+G to see if anything new appears. If so, that's the Immediate window.
What's also really bad is, that errors in a macro always crash PPT.
Not ordinarily, no. It can happen that way, of course; your code might be triggering a bug in PPT. Heaven knows, I ran into enough of that in PPT 2002 and 2007. If you're using reasonable error handling and still running into errors that crash PPT, stepping through the code as it runs should allow you at least to narrow it down to the line or two that cause the crash.
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode.
Again, no. The ActivePresentation refers to whatever presentation has focus in the app, whether it's in slide show or any other view. If your code's in one presentation and its' supposed to be acting on another, that can cause some confusion, but you simply need to switch to normal view, make sure the presentation you want to access is visible (I'd make sure not to have several in view) then Alt+F11 to return to the IDE and run your code.
All of these suggestions apply to any Windows version of PPT, going back to Office 97 (Mac? Thinks different. If you're using a Mac, mention that. There are a few differences but for the most part, everything above applies except for the Alt+F11).
If none of this seems to help on your setup, it may be time to do a repair of Office.