Is there a way to change the watch window depth in vscode so that I don't get "System.Collections.Hashtable", and instead actually see the Hashtable?
Related
When a DataTip is open while debugging in Visual Studio it appears the only way to get to a specific object property is scrolling with the mouse.
This can get very cumbersome as some objects can have hundreds of properties and scrolling to a property near the bottom takes a long time.
Yes, I know I can scroll faster if I hover the mouse over the bottom edge and pin a property once I found it but it can still take a long time to get to the property and pin it.
I've tried various combinations with Ctrl and Alt but what ever key I press the DataTip is promptly closed...
Once the DataTip has focus, you don't have to use the mouse. You can use the PgUp/PgDn (Page Up/Page Down) keys on your keyboard. But you're right: There is not a way to get to the end of the list or to get to items that start with a certain letter. When I need to do that often I take one of two approaches:
If possible, I create a [temporary] variable assignment after the code-line of interest and ensure that the variable gets assigned to the property of interest.
Create a watch variable and interact with that.
Open an Immediate Window and paste a copy of the object-instance name in question. Once in the Immediate Window, IntelliSense is available as soon as you type the "."--you can then type the letter of the property in question and drill-down as needed more quickly.
(Probaby the best tip!)
Open (and keep open for convenience) a Debug | Windows | Autos and/or Debug | Windows | Locals window. Those windows simplify navigating variables near the code break or in the current module--and they even seem to retain their tree-node-expanded state in some cases while debugging. More information is available here: https://msdn.microsoft.com/en-us/library/bhawk8xd.aspx
You could use the oz-code as an extension tool which could help you search the properties or variables easily.
Search in debug mode inside an object
I use the default terminal.app
I use cmd+d command to split panes so I can look at the part of the code while using another command.
This annoying bug comes up when de-splitting the panes.
What it does is that it basically reduces the vertical length of the terminal, so that after de-split, terminal is not filling my screen vertically.
Is there any solution to this?
Any true solution is going to have to depend on a bug fix. But this works for me:
Set the window default size in Preferences/Profiles/Window.
Assign a shortcut key to Window/Return to Default Size.
You could also use the inspector that you get with Shell -> Show Inspector.
When I open any console window, be it PowerShell or the Command Prompt, it always appears on the far left side of my left monitor. This is waaay too far from my eyes and where I'd like it to be. It doesn't matter if I drag it to the center or exit or close the window, it always reappears in the bad location.
Is there any way to get it to reliably appear where I left it?
Follow this:-
Open cmd.exe or Powershell.exe
Right Click top frame and select Properties
In the Layout tab, find an option for Window Position
Uncheck Let system position window;
Enter your choice and .... smile :) .....
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
I'm in VS2010, on a breakpoint. How can I cause a datatip to be displayed for a given variable/expression w/o using my mouse to hover it?
That can't be done, exactly, but you can get the same result by selecting the variable you want to watch (using ReSharper's Ctrl + Alt + →/← can speed this up), and pressing Shift + F9, which will raise "QuickWatch" modal window with the datatip contained within.
If you prefer, you can also go into Options->Keyboard and bind the Debug.AddWatch to a different keyboard shortcut, and use that instead of Shift + F9, and then your variable data will persist in the Watch window so you can come back to it later (as suggested here)
You can also do this by opening the command window (Ctrl + Alt + A) and typing Debug.AddWatch variable_name.
While you can pin multiple windows in VS it will be a somewhat cumbersome experience and you will have to over it.
I personally use visual studio plugin called Oz Code, that automatically annotates all the local variables and intermediate results so I don't have to chose which variables to pinpoint.
The results looks something like this:
Will adding a watch not be suitable? When you hit your breakpoint the relevant details of the variable will be shown in the watch window.
Perhaps I have misunderstood what you're trying to achieve here!
You can click the 'pin' icon to force any datatip to stay open, and it will update to the current contents when you hit the breakpoint.
I don't know of a way to open a specified tip without pinning it, however.
The Locals and Autos windows might be helpful as they show all local variables, (they even show the return value of called functions!).
Note however that they show directly only variables in scope, so if you need a detail property that it is not yet menotioned in the code you can drilldown using the →/← keys, however if it is already mentioned in the code in the current scope then you should be able to see it directly in the Autos window.