Related
When I debug a unit-test with Visual Studio 2017, all the console output is logged and I can examine it by clicking the "Output"-link in the result box of the unit-test (I'm using the built-in Test-Explorer).
However, since I do log a lot to console at runtime which is even color coded so important stuff is more visible, I can't see this color coded output using the "Output"-link, because it's just plain black text on white background.
Is it possible that Visual Studio shows all the output directly in a console window when debugging the tests so I see the output as I would see it when actually running the application outside of a test?
You cannot (or it is very tricky at least) open a console window from a unit test - I've tried with the top 2 answers from the following post, and they didn't work: Show Console in Windows Application?
You can make the Debug.Write... methods write to the Console when you are running/debugging the application itself (not the unit tests) with this code, though:
ConsoleTraceListener listener = new ConsoleTraceListener();
Debug.Listeners.Add(listener);
Any calls to Debug.Write... methods after this code will also output to the console.
Standard output is the only way to display the test output, when we use some output method in our test like Debug.WriteLine(); Console.WriteLine(); etc.
I also tried to change the font of the test output but it seems there is no that option is VS 2017, even someone though someone mentioned this before:
Is there a way to change the Font used in the VS2012 Test Output Window?
Similar case discussed in this thread, even some reply claimed that we could manually launch the console window, but they are 100% sure about it.
If you really need change the font or the color of the test output, in Visual Studio you go to Help -> Send feedback to VS developing team to provider your suggestion .
My custom Windows shell context menu handler works like a charm, for all Windows versions from XP to 7, but on Windows 8, 8.1 and 10, installing it breaks the Win+X menu (sometimes called "Power user menu", or "Quick Access menu", or "WinX menu"): when hitting Win+X, the menu is displayed as expected, but its items do not work anymore (nothing happens when I click on them), except for the last four items at the bottom which still work as expected ("Search", "Run", "Shut down/Sign out", "Desktop"):
I quickly found out on Google that it was a well known issue for a great number of shell extensions that were not "compatible" with Windows 8/10. But sadly, I only found application users talking about this issue and its "solutions", and no developer talking about this. And the two "solutions" proposed by these users were:
Unregistering this shell extension
Uninstalling the app that registered this shell extension (which leads to solution 1...)
See for example this, this, or this to read people talking about this issue.
Note: my shell extension is applied for the * file type, which means all files.
Several days later, I found the cause of this issue in the shell extension source code, so I thought it would help other developers to share it on StackOverflow, as a self-answered question (I didn't find this question). See answer above.
I first looked at the shell extension sample code provided by Microsoft (which doesn't cause this issue), compared it with my code, and progressively replaced parts of my code with Microsoft's code and testing it after each replacement.
I found out that what prevents power-user menu to work is what you return in method InvokeCommand() from IContextMenu interface: if your extension cannot handle the given verb, it shall always return E_FAIL so that Windows tries with other implementations of IContextMenu (see Microsoft documentation for more details). It seems that when a power-user menu item was clicked, Windows first called my extension (* file type), then since it didn't return E_FAIL for this unknown verb, Windows thought that my shell extension has processed this event, so it didn't process it through the nominal power-user menu callback.
By the way, three things seem very weird to me:
Why does Windows even try to process this power-user menu event with a shell file extension? Is this menu coded using the same design/mechanism as any other Explorer's file contextual menu?
Why does this bug didn't produce more side-effects yet? I mean this should have broken the whole shell extension system right from the beginning, no?
Why do so many applications has this bug? (meaning why so many applications do not return E_FAIL as expected?). It's been a while now that I've written this code, I can't really remember where it comes from, but I guess it comes from a Microsoft sample or any Microsoft employee tutorial (far too Microsoft-oriented to be coded by yourself). If it's the case, that may answer the question why so many shell extensions cause this issue...
I would be interested if someone has some ideas to share about this subject!
By the way, I hope my post can help other developers. When looking at the new Microsoft example that works like a charm, I was first afraid having to rewrite all my shell extension from their sample without knowing what was wrong in my code!
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.
I'm facing some troubles still while learning, so I guess it tends to get worse once I play with the big kids: warnings in dynamics aren't as precise and informative as VS's, there are no mouse-over tips, and exceptions to show me exactly where I've got it wrong.
I'm just too used to Visual Studio, it's intellisense and all the tools (dynamics is quite new when compared to Visual Studio)
More than solving simple code issues, i'd like to learn how to solve upcomming ones i might have in code not written by me or anything else i'd solve in 3 minutes in Visual Studio, as well as tips on how to survive in dynamics ax without all the Visual Studio tools.
The code editor in Dynamics AX has some intellisense, typing the name of a table or class variable followed by . or :: will give you a list of fields or methods available for that item. After you type the ( to start a method call, a tooltip pops up with parameters available on that method. When starting a new line, you can right click and List Tables, List Classes, List Types, etc. Most of those commands are also available via Shortcut Keys. Note that the intellisense only works if all the code in the method up to the location of your cursor is syntactically correct.
Make sure you have updated the cross reference in your development environment (Tools/Development tools/Cross-reference/Periodic/Update). With an updated cross reference, you can right click an any table, field, class, method, extended data type, or enum in the AOT and choose Add-Ins/Cross-reference/Used by to see where that item is used in the system.
You can also use Tools/Development tools/Code explorer to view the source to the application with all types, variables, and methods turned into hyperlinks so you can click to go right to the definition of that item.
Another useful tool is Application hierarchy tree, available either under Tools/Development tools, or on the right click Add-Ins menu. This will show you the class hierarchy, so you can easily see, for example, that SalesFormLetter derives from FormLetter, which derives from RunBaseBatch.
In the editor, you can highlight text and right click to Lookup Properties/Methods or Lookup Definition.
If you are trying to track down where in the system a particular infolog message is generated there are two strategies to use:
Set a breakpoint on the first line
of the method Info.add(). Then when
you run the code generating the
message, you will pop into the
debugger as soon as the infolog is
generated. You can then look at the stack
trace in the debugger to see where the code is that
generated the message.
Run Tools/Development
tools/Label/Label editor and search
for the text of the message. Select
the Label ID of the message, then
click Used by to see where that
message is used in the system.
There is also http://www.axassist.com/ which extends intellisense and many other extensions
What these guys said already is very interesting and helpful.
I'd like to add that within AX in real life you are probably working with multiple contexts. e.g. Code running in the client, code running in server, code running in p-code and in IL, COM integrations, Enterprise portal and so on.
My point is, if you want to figure something out through debugging, you must first understand where the code(s) you'd like to debug is running.
Knowing that is important because you might have to allow debugging or give permissions in multiple places.
Examples:
Windows AD debugging users (add yourself)
Allow debugging on client
Allow it on server
Disable IL if you want to use MorphX, otherwise attach the process in VS.
Allow World Wide Web Publishing Service to interact with desktop for EP.
One last thing, you are starting to work with ax right now, perhaps you will need to work with AX7(Dynamics 365 for Operations). This version of the system works only with visual studio. It is still x++, but you have a lot of the things VS provides you.
Take a look on EditorScripts Class,On AX Editor you can use it by right click and choose "Scripts". It is a kind of intellisense that can make by your self, for example: here is my in-line comment whenever I type "mycom" and press "tab"
public void template_flow_mycom(Editor editor)
{
xppSource xppSource = new xppSource(editor.columnNo());
int currentline = editor.currentLineNo();
int currentcol = editor.columnNo();
Source template = "//Partner comment "+date2str(today(),123,2,1,3,1,4, DateFlags::FormatAll )+" at "+time2str(timenow(), 1, 1)+" by MAX - Begin\n";
template+=strRep(" ", currentcol)+ "\n";
template+=strRep(" ", currentcol)+ "//Partner comment "+date2str(today(),123,2,1,3,1,4, DateFlags::FormatAll )+" at "+time2str(timenow(), 1, 1)+" by MAX - End\n";
editor.insertLines(template);
//move cursor to the empty line between the comments
editor.gotoLine(currentline+2);
editor.gotoCol(currentcol+4);
}
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As much as I generally don't like the discussion/subjective posts on SO, I have really come to appreciate the "Hidden Secrets" set of posts that people have put together. They provide a great overview of some commonly missed tools that you might now otherwise discover.
For this question I would like to explore the Visual Studio .NET debugger. What are some of the "hidden secrets" in the VS.NET debugger that you use often or recently discovered and wish you would have known long ago?
One of my favorite features is the "When Hit..." option available on a breakpoint. You can print a message with the value of a variable along with lots of other information, such as:
$ADDRESS - Current Instruction
$CALLER - Previous Function Name
$CALLSTACK - Call Stack
$FUNCTION - Current Function Name
$PID - Process ID
$PNAME - Process Name
$TID - Thread ID
$TNAME - Thread Name
You can also have it run a macro, but I've never used that feature.
You can right-click an object in the Watch window and click Make Object ID.
It will assign that instance an ID number, allowing you to see, in a complicated object graph, which objects refer to the same instance.
For .net applications System.Diagnostics has lots of useful debugging things. The Debugger class for example:
Debugger.Break(); // Programmatically set a break point
Debugger.Launch(); // Launch the debugger if not already attached
Debugger.IsAttached // Check if the debugger is attached
System.Diagnostics also has lots of good attributes. The two I've used are the debugger display attribute for changing the details put into the locals window and the step through attribute for skipping code you don't care about debugging:
// Displays the value of Property1 for any "MyClass" instance in the debugger
[DebuggerDisplay("{Property1}")]
public class MyClass {
public string Property1 { get; set; }
[DebuggerStepThrough]
public void DontStepInto() {
// An action we don't want to debug
}
}
As a web developer who works with Web Services that are within the same solution as my front-end code most of the time, I found the ability to "attach" to a process to be a HUGE time saver.
Before I found this hidden gem, I would always have to set a breakpoint on some front-end code that called a web service method and step into it. Now that I know about this trick/feature I can easily set breakpoints on any part of my code that I want to which saves me loads of time and effort.
$exception in the watch window will show the exception that is currently being processed even if you don't have a catch that assign the Exception instance to a named variable.
The threads window, from Debug -> Windows -> Threads. You can Freeze and Thaw threads, and switch the active thread. This is awesome when debugging or replicating an issue with a multithreading application.
You can drag & drop the yellow "Next Statement" arrow to another place. When the program resumes, it will resume execution at that statement. You can add it to the toolbar, a blue arrow called Set Next Statement, but it's not there by default.
You can "undo" the navigation you did, like scrolling, going to another file, or jumping to a reference. The shortcut is ctrl-- (control minus.) That way you can jump into a function, examine the code there, and go back to where you were without looking.
Conditional breakpoints.
You can load windbg extensions into the Visual Studio debugger and use them from the immediate window.
As posted in another post Sara Ford is doing a current series on the VS debugger.
Her blog is the best source of VS tips: http://blogs.msdn.com/saraford/archive/tags/Visual+Studio+2008+Tip+of+the+Day/default.aspx
This is kind of an old one. If you add a watch expression err,hr, then this will hold the result of GetLastError(), formatted as an HRESULT (VC++ debugger only).
You can drag current line cursor (yellow arrow) up and down your code when execution is paused.
Additionally, in order to enable this during pause on exception you have to click "enable editing" on exception details first.
You can also make VS break on handled exceptions by checking one's of interest under:
Debug->Exceptions : Thrown column
Some useful shortcut keys.
F11 to step into a method.
Shift-F11 to step out of a method.
F10 to step over a method.
Things I use often:
Click the menu item "Debug | Exceptions" (or Ctrl-D, E for short) and you can enable breaking at the time that any exception is thrown, or choose to not break on certain exceptions.
You can set up the debugger to download some of the framework source code and symbols from a MS server and step into the framework code. (Some libraries, like System.ServiceModel, are not yet available). It in the Options windows under Debugging. See MSDN How-To.
You can use the VS.NET debugger to debug Javascript running in IE. You just need to install the IE javascript debugger, and enable javascript debugging in IE's settings. Then on a JS error it will pop up a "do you want to debug" dialog box, and you can choose to debug in VS.NET.
You can open and place a breakpoint in a source file if the file belongs to another solution (external file). The debugger can still hit the breakpoint. No need to open another Visual Studio instance to debug the external file. Helpful in debugging web services which you source to. This works as long as all the sources are current and compiled.