When one steps into the debug function with multiple input parameters, it is a quite a time waster to enter and leave a copy constructor of each input parameter. Most often than not, these copy constructors are trivial (increase the reference counter), and what a developer really want is to "step right into function", and skip debugging through of input parameters creation,
be it a call to a copy ctor, or a call to a function which creates the instance of parameter object.
Is there a way in a Visual Studio to configure the debugging in a such way, as to avoid the debugging of the construction/copy construction
of the parameters and to go right to the function's body?
alt-shift-F11 in Visual Studio 10 or higher brings up a list of all the functions that will be called and you can select the function you would like to go directly to. I find this incredibly useful, but unsure if you are using VS10 or an earlier version.
Related
I was doing practice questions for the rpa asociate exam and came across a question I was unsure on how to answer.
Suppose you have some arguments from an invoked workflow. Some are out arguments, some are in and some are in/out. The question asked which types of arguments supported being mapped to variables and which supported being mapped to hard coded values.
I didn't find much on the documentation expect a generic paragraph on arguments as a whole that said that you could map them to both variables and hard coded values regardless of direction.
TL;DR - If you hardcode a value to an Out or In/Out, the Out value produced cannot map to the Out argument and will not be used further down the line.
While it is probably allowed by UiPath Studio to add hardcoded values to Out or In/Out arguments, it would effectively break your automation by the nature of what an Out argument actually does.
When thinking through it, if you were to add a hardcoded value as the result of an Out or In/Out argument, all work done while the workflow is invoked would not be passed back to the invoking workflow when it is finished, since the out value produced is not able to replace a hardcoded value. An In argument, on the other hand, would work just as well whether the value is a variable or hard-coded, since that value is no longer needed as soon as the workflow that is being invoked starts (however, in most cases, it is probably still best practice to use a variable even for an In).
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
Is there a way to perform the opposite of the "Extract Method" refactor in Visual Studio?
I have a legacy codebase that has ~50 very short, private functions that are only used once each, and I have been tasked with inlining them.
If an automatic inline refactoring isn't possible, is it possible to reduce the amount of time it takes to inline these function calls? My current workflow is:
Copy the code in the function.
Find where it is called.
Replace the function call with the copied code.
Replace local variable names from the function.
Delete the function.
The refactoring you are looking for is called "Inline Method".
While Visual Studio does not provide this refactoring out of the box, you can get access to it (and many other useful refactorings) by installing the Jetbrains ReSharper extension for Visual Studio.
With the extension installed, all you need to do is click on the method declaration or method call, and invoke the 'Inline Method' refactoring. This will automatically inline all occurrences of the method and delete it.
You might consider collecting the functions into a header file and decorating them with inline. I realize this is not exactly an answer to what you asked, but may be a better solution to your problem because this way the compiler would perform the inlining (if it sees fit).
It depends on the situation, but keeping the function definitions might lead to clearer code, thus might be of value even if called only once.
This is also quicker and less error prone than manual "inline method" refactorings.
I'm trying to simplify my debugging tasks and I had an idea which could increase my debugging speed.
Suppose I have a value, say 2.8651 that appear in the code at a moment I do not know.
I'm wondering if it was possible to create a super breakpoint which would stop at the first time one of the variable takes this value.
I recall that I do not know which variable takes the value.
I could know it by spending some time on the debugger but I'm lazy.
I'm not really familiar with VBA for VS. I guess, a solution would be to create a macro which would loop along local variable at each line of the code execution. It'd stop when the condition localVariable == 2.8651 is verified.
Thank you for your answers!
There's no such thing as a super breakpoint for a block of code. There are two options to achieve what you want:
Place a conditional breakpoint on each line with a variable assignment. Right-click the breakpoint and click Condition... to specify when it should break.
Place a single conditional breakpoint in the code block and check all the required variables in the condition.
As you suggested, you can place a single breakpoint with a macro, by right-clicking the breakpoint and select When Hit.... However, I highly doubt that it's possible to control the breakpoint from the macro, so this wouldn't work.
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.