I have been getting this error message when I step into some methods
Do you want to continue being notified when an Automatic step over occurs?
I usually answer Yes and I get taken to the line I want to step to.
However, I just pressed No (cause I was tired of the dialog box always popping up). When I did that it skipped a lot of code I wanted to step through. Now when I step into my method it is skipping my method (and jumping to the finally block because the method I am trying to step into is throwing an exception).
How can I change my answer back to Yes?
I would prefer it never ask me (default showing the code), but if faced with the choice of it skipping the code I need to see, or having a NagBox, I will take the NagBox.
I'm blissfully unaware of this. Try Tools + Options, Debugger, "Step over properties and operators" checkbox. If that's not it, document the key you press.
If I understand this message correctly, code is always skipped - regardless of your choice.
It's like "Hey, just a heads up, I am going to skip some code. Do you want me to notify you next time?" Yes/No
Uncheck Tools + Options, Debugger, "Step over properties and operators" and that will fix this issue.
For anyone who is still interested in this, I was able to solve my stepping into a function by doing the following
Tools -> Options -> Debugging -> General
and then unselect
Require source files to exactly match the original version
Related
Anybody knows guys is there a possibility to trace a code in Netlogo statement by statement, like using F7 or F8 in C/C++,...
Generic longer comment:
/*
So as the comments above say, there is not a debugger but there are work-arounds.
Replayable random-seeds and many print statements help. I define v-print routine to print if a "verbose" switch is TRUE, so I can put in lots of v-print statements, sometimes one per line of code, but shut them all off until needed with one interface switch.
For many Netlogo users, judging by the questions, this is the first programming language they have ever used. So there is some generic advice like "take small steps and do sanity checks often, expecting that something will go wrong."
But maybe the best and hardest advice is to learn enough Git and GitHub to set up a repository and "SAVE COMMENTED VERSIONS OFTEN", because otherwise it is a losing proposition to try to debug tangled code with multiple errors that you have been trying random changes on to see if they help. Some times you need to fall back to the prior last-good version and work forward from there again step by step looking for where it breaks. Working forward is easy. Debugging backwards is hard.
Debugging code with one error is much easier than debugging code with multiple errors.
Decades ago I used to repair analog televisions. I loved rich people because they called as soon as one thing was wrong. Poor people waited until the set was full of errors then called. I've seen similar behavior in programmers continuing to code hoping that prior errors will somehow magically go away. Slow is fast.
GitHub has been a life-saver a few times when I accidentally deleted a section of code in the editor and didn't notice I'd done it. It's easy to have lines of code highlighted and then type a word while not looking at the screen. Then you go crazy with code that worked yesterday and doesn't work today and you "didn't change anything".
Using GitHub to restore a prior version, or simply doing a differences ( "diff" ) between the current version and prior version shows what changed.
*/
When I use an enum in a switch statement in C#, I am used to add a debug break statement to the Default case to prevent adding items to the enum which are not covered by the switch. During debugging, the code will then break if it hits the Default case.
Now I am programming a beckhoff PLC and want to do the same in a CASE .. OF ELSE ...END CASE in STL. Is this possible and/or normal in PLC programming?
I don’t think you can. Also it wouldn’t be desirable to stop a PLC program and prevent it from executing machine relevant code.
Instead you could use the ADSLOGSTR function to log to the event logger. Or show a message box. This will work in both TC2 and TC3.
You can set breakpoints when you are in online-mode, but as pboedker pointed out as soon as the breakpoint is reached (unless you have a special configuration, but this is another subject) your ethercat master will timeout, your safety module will produce a com error and your drives will need a reset aswell.
If you don't have real hardware and an ethercat master attached in your project you can use breakpoints without any worries.
I personally take another approach.
I always build a separate Debug-Visualization in the plc together with a special Debug FunctionBlock which helps me to track bugs in the project.
In your case for example I would simply call a special method of the Debug-FunctionBlock with an errror code and a string when the program flow reaches the default-case.
The error code and the string would then be visualized in the Debug-Visualization.
Even if it's a little more effort than simply calling adslogstr I would rather implement a separate Debug-FunctionBlock for 3 reasons:
You need more logic than simply calling adslogstr anyway because if by any chance adslogstr is called cyclically, you end up spamming the event logger.
Reuse in other projects
You can expand the Debug-Visualization to a Test-Suite if needed, which can come in handy
You can find more info about the beckhoff visualization here:
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/3523377803.html&id=
Breakpoints are possible like Filippo said. You can prevent outputs from being reset during breakpoint by setting KeepOutputsOnBP (see this: https://stackoverflow.com/a/52158801/8140625).
You could also set error/warning/note message to your Visual Studio when that happens by using ADSLOGSTR(see this: https://stackoverflow.com/a/51700613/8140625). So add a ADSLOGSTR call to your CASE ELSE with appropriate message and you will see it in error list / TwinCAT console.
Edit: Somehow missed pboedkers answer, he already answered the ADSLOGSTR.
I like the solution of Filippo. Is could be easy to change the behavior of the debug function in the future without touching the code to much.
I was thinking to much in the C# solutions :)
Thank!
I need some help with selecting a value from a dropdown list. The dropdown is a WebElement, and the flow works well up to the point where the value should be selected.
My code is as follows:
.Browser("Browser").Page("PageName").WebElement("DropDownList").Click
.WebList("ListOfItems").Select(itemToSelect)
Note: itemToSelect is the name of the item that needs to be selected from the list, which is being passed as a parameter within the function.
When running the code, I get an unspecified error.
The weird thing is that before the error is thrown, I can see the value being selected from the list in the browser, as upon selecting it, some fields in the form change. Also, if I press "Skip" in the error message panel, the process goes on as if nothing happened.
I am certain the error comes from .WebList("ListOfItems").Select(itemToSelect) but I do not know what to do in order to fix it.
Try this code.It works for me.
StrAllItems = Split(Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetRoProperty("all items"),";")
For intCounter = Lbound(strAllItems) to Ubound(strAllItems)-1
If Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetItem(intCounter)= "SomeValue" Then
Browser("name:=.*").Page("title:=.*").WebList("name:=.*").Select (intCounter)
Exit For
End If
Next
Please let me know if this help.
If the test behaves correctly and you're just getting an superfluous error you can just ignore this specific error. It's best of course to understand where the error comes from, you should probably contact MicroFocus support but in the meantime you can turn off error handling for the offending line.
Browser("Browser").Page("PageName").WebElement("DropDownList").Click
On Error Resume Next ' turn off error handling
Browser("Browser").Page("PageName").WebList("ListOfItems").Select(itemToSelect)
On Error Goto 0 ' turn error handling back on
BTW, I changed your code a bit to make it valid, I assume this is what your code really looks like.
Possible timing issue: You might need to wait for the hole list to appear before you select the item.
Often, the item exists, but the app is still updating its GUI.
Whenever you access the GUI with UFT while the app is not idle (f.e. not ready for user input because it is still updating its HTML), you might get all kinds of strange results, including unexpected errors, hangs, instability.
So how do you wait for the list to be complete? I don't know, because it heavily depends on the way your app is refreshing its GUI. You need to explore that, and integrate some synchronization code that waits for the right condition to be met.
Unfortunately, this is a hell of a job sometimes.
A suitable workaround (and a good way to verify if my hyphothesis is correct) might be to insert a large delay between the first click and the list item selection click. (A quick way to do a similar thing is to single-step through the code.) If that does not generate any error or issues, you can be pretty sure it is what I describe, and you can experiment with lower delay durations to find a good value.
Thanks to everyone for your replies.
The issue turned out to be due to the object not being added well to the repository.
It was eventually fixed by adding it properly.
I'm not sure how to really put my question into words so let me try to explain it with an example:
Let's say my program runs into some weird behavior at a specific action. I already find some code which is the cause of this weird behavior. When disabling this sequence I don't run into this behavior. Unfortunately, I need this code because something else is not working then.
So, what I gonna do next is figuring out why something is going different when that code excerpt is active.
In order to better understand what's going on I sometimes want to run the whole action including the 'bad code' and sometimes without. Then I can compare the outcome, for example what happens in the UI or what my function returns.
The first approach which comes to my mind is to run my program with the code enabled, do whatever I want, then stop my program, comment out the code, recompile and run again. Um... that sounds dumb. Especially if I then again need to turn on that code to see another time the other behavior, and then again turn off, and on, and off and so on.
It's not an option for me to use breakpoints and influence the statement order or to modify values so that I run or not run into if-statements, for-loops etc. Two examples:
I debug a timing critical behavior and when I halt the program the timing changes significantly. Thus, the first breakpoint I can set must be at the end of the action. 1
I expect a tooltip or other window to appear which is 'suppressed' when focus is given to VS. Thus, I cannot use any breakpoints at all. Neither in the beginning nor at the end of the action.1
Is there any technique in Visual Studio 2012 which allows me to mark this code to be optional and I can decide whether or not I want to run this code sequence before I execute the action? I think of something like if(true|false) on a higher level.
I'm not looking for a solution where I need to re-run my program several times. In that case I could still doing the simple approach of simply commenting out the code with #if false.
1 Note that I, of course, may set a breakpoint when I need to look into a specific variable at a certain position (if I haven't written the value into output) but will turn off breakpoints again to run the whole action in one go.
In the Visual Studio debugger you can set a breakpoint right in front of your "code in question". When the code stops at that point, you can elect to let it continue or you can right-click on any other line and select Set Next Statement.
It's kind of a weird option, but I've come to appreciate it.
The only option I can think of is to add something to your UI that only appears when debugging, giving you the option to include/exclude the operations in question.
While you're at it, you might want to enable resetting the application to a "known state" from the UI as well.
I think of something like if(true|false) on a higher level.
Why "on a higher level"? Why not use exactly this?
You want a piece of code sometimes executed, sometimes not, and the switch should be changed at run time, not at compile time - this obviously leads to
if(condition)
{
// code in stake
}
The catch here is what kind of condition you will use - maybe a variable you set to true in the release version of your code, and to false sometimes in your debug version. Maybe the value is taken from a configuration file, maybe from an environment variable, maybe calculated by some kind of logic in your program, whatever and whenever you like.
EDIT: you could also introduce a boolean variable in your code for condition, initialize it to true by default and change its value using the debugger whenever you like.
Preprocessor Directives might be what you're after. They're bits of code for the compiler to execute, identifiable by starting with a # character (and stylistically, by default they don't follow the indent pattern of your code, instead always residing firmly at the left-hand edge of the editor):
#define INCLUDE_DODGY_CODE
public void MyMethodWithDodgyBits() {
#if INCLUDE_DODGY_CODE
myDodgyMethod();
#endif
myOkMethod();
}
In this case, if #define INCLUDE_DODGY_CODE was included, the myDodgyMethod() call will be compiled into your program. Otherwise, the call will be skipped by the compiler and will simply not exist in your binary.
There are a couple of options for debugging as you ask.
Visual Studio has a number of options to directly navigate through code. You can use the Set Next Statement feature to move directly to a particular statement. You can also directly edit values through the Immediate Window the QuickWatch and the tooltip that hovers over variables while debugging.
Visual Studio also has the ability to playback the execution history. Take a look at IntelliTrace to get started. It can be helpful when you have multiple areas of concern that are interacting and generating the error condition.
You can also wrap your sections of code within conditional blocks, and set the conditional variables as appropriate. That could be while you're debugging, or you could pass parameters in through a configuration file. Using conditional checks may be easier than manually stepping through code if there are a number of statements you wish to exclude.
It sometimes depends on the version of VS and the language, but you can happily edit the code (to comment it out, or wrap it in a big #ifdef 0) then press alt+F10 and the compiler will recompile, relink and continue execution as if you'd never fiddled with it.
But while that works beautifully in VC++ (since VS v6 IIRC), C# can have issues - I find (with VS2010) that I cannot edit and continue in this way with functions containing any lambda (mainly linq) statements, and 64-bit code never used to do this too. Still, its worth experimenting with as its really useful sometimes.
I have worked on applications that have optional code used for debugging alone that should not appear in the production environment. This segment of optional code was easiest for us to control using a config file since it didn't require a re-compile to change.
Such a fix might not be the end all be all for your end result, but it might help get through it until a fix is found. If you have multiple optional sections that need to be tested in combination this style of fix could require multiple keys in the config file, which could be a downside and a pain to keep track of.
Your question isn't exactly clear, which is possibly why there are so many answers which you think are invalid. You may want to consider rewording it if no one seems able to answer the question.
With the risk of giving another non-valid answer I'll add some input on how I've dealt with the issue in the past.
The easiest way is to place any optional code within
#if DEBUG
//Optional code here
#endif
That way, when you run in debug mode the code is implemented and when you run in release mode it's not. Switching between the two requires clicking one button.
I've also solved the same problem in a similar way with a simple flag:
bool runOptionalCode = false;
then
if (runOptionalCode)
{
//Place optional code here
}
Again, switching between modes requires changing one word, so is a simple task. You mention this in your question but discount it for reasons that are unclear. As I said, it requires very little effort to switch between the two.
If you need to make changes between the code while it's running the best way is to use a UI item or a keystroke which modifies the flag mentioned in the example above. Depending on your application though this could be more effort than it's worth. In the past I've found that when I have a key listener already implemented as part of the project, having a couple of key strokes decide whether to run my debug (optional) code works best. In an application without key listeners I'd rather stick with one of the previous methods.
Currently, I see a recurring error:
2013-04-18 02:35:51.583 aaah[1713:1110f] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x1fc00dc0> was mutated while being enumerated.'
In the failing background queue (I see my queues state upon the moment of a crash by pressing Command + 5) I see:
0 _pthread_kill
1 pthread_kill
And I see assembly output which I completely don't understand.
I know how to resolve this kind of array enumeration errors - I just can't understand where/how I should seek for the piece of code causing my app to crash.
I have much multi-threaded code using AFNetworking and Core Data, so I can't just remember where the crucial section might be.
Also, this error occurs not always, but from time to time, so it is difficult just to use "isolation approach", isolating smaller and smaller pieces of code, to finally identify the buggy piece of code.
So the question is:
How can I extract some more useful information from this output, or Xcode can provide me with some more verbosity level, so I could know how to resolve this annoying piece of code.
Have you tried setting an exception breakpoint? Sometimes the debugger struggles with exception handling inside blocks but it might help.
In the breakpoints navigator (one of the tabs on the left side of the window) click the plus button at the bottom of the window and select add an exception breakpoint. Then hit done.
Now when you crash, the debugger should hopefully put you right before the instant the exception was raised.
See http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html for more info.
Edit:
Based on the feedback provided in the comments, here's some more analysis:
The exception your application is raising means that you attempted to change a collection type (in this case, an NSMutableOrderedSet) inside of an enumeration block (in your case, most likely a for-loop). It looks like you're trying to remove objects in a set that you are looping over: [NSMutableOrderedSet removeObjectsInRange:inOrderedSet:]
To resolve this you should store the ranges you wish to remove and then do the actual removing once you're no longer iterating over the set. It's still going to be difficult since, as I understand it, you're not breaking inside of Objective-C code. You should look at the running threads in the panel on the left and look at what method they're currently in. That might give you a hint as to where your code is wrong.