By default, Visual Studio tooltips remain visible for 10 seconds and then they disappear. I find this time too short to read some of the longer tooltips. Is there a way to increase the time they remain visible?
Whenever I encounter such a problem, I just press print screen and read the text in my favorite paint program.
I never understood why the tooltip timeout is not based on the length of the content.
My understanding is that ToolTips preferences are controlled at the system display level (i.e., as part of Windows settings). As far as I know, there is still no way to lengthen the time that a tip is displayed.
I recommend Shay Erlichmen's trick of using print screen to capture the tip. Paste into a paint program and you can read the whole thing. Then close the paint program without saving.
Related
I've seen this for years with Visual Studio and would like to finally understand it.
I'll be coding in VS and I want to increase my text editor font size. My typical method is to use use CTRL+MOUSEWHEEL to increase it. As text in text editor gets bigger, so does the text in the Output Window. They're sync-ed.
That makes the output window font size larger than I want so then I go to...
Tools >> Options >> Environment >> Fonts and Colors
...change the category to "Output Window" and change the font size. And yes, that certainly works. But it has the odd side-effect of making the output window stop tracking with the code window. Now, if I use CTRL+MOUSEWHEEL to adjust the code window font size, the output window does not change.
But then, a month or two later, I will notice that they're tracking together again.
What is it that made the two track together? Is there any way to toggle that tracking on and off?
(Both windows use "Courier New" for a font, if that matters)
I have a long line that I want to select a section in the middle. In Visual Studio, it would scroll all the way to the end of the line, passing where I want the selection to end, when I move pass the text area and move all the way back when I try to move back a little. Is there a way to slow down the Visual Studio scrolling adjustment?
If you are talking about selecting text using the mouse you can get fine grained control by combining the the mouse and keyboard. This should work in any application that allows text selection, not just Visual Studio.
First click the location where you want to begin selecting text.
Next scroll to the location where you want to end selecting text and hold down Shift on the keyboard while clicking with the mouse. The block of text between the first click and the shift+click will be selected without having to worry about the selection jumping around due to scrolling.
As for actually slowing down the scrolling; I know of no way to do that. Hopefully my tip should give you an alternate way to do what you actually want.
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 want to be able to see a time stamp in the beginning of every trace in the debug window in Visual studio.
[Time stamp here] The thread 'Win32 Thread' (0xcd0) has exited with code 0 (0x0).
[Time stamp here] => CLR ProvideAssembly: AppDomainId: 1, Ref: 'msvcm90d...
Example of this is the sysinternals application - DebugView. The problem is that I can't have Visual Studio debugging, and listening with DebugView at the same time, and I am not comfortable with adding the time stamp manually to my tracers.
Since the output window text is read-only once written, there's not an easy way to do exactly what you want to do. However, it's easy to do something similar: append a timestamp line after new text is written to the output window. This will make the output window a lot more messy, but you'll get your timings.
Here's how this would work: First, create a Visual Studio Add-in or Macro which hooks the PaneUpdated event of the Outlook Window's active pane. (See this thread for how to do this with a Macro approach). Make sure to check, in the event handler, that pane.Name == "Debug" and ignore other panes. Second, when you detect new text in the debug output pane, append a timestamp line, like this:
public void AddTimestamp(DTE2 dte)
{
// Retrieve and show the Output window.
OutputWindow outWin = dte.ToolWindows.OutputWindow;
pane = outWin.OutputWindowPanes.Item("Debug");
}
catch
{
pane = outWin.OutputWindowPanes.Add("Debug");
}
pane.OutputString("[timestamp: " + DateTime.Now.ToString() + "]\n");
}
It's also possible to pre-pend a timestamp to each line, but it's a lot harder. You can't change text already in the Output window (it's read-only), but you can clear the window and you can add text. So you could use the same event-handler approach above to detect text changes, but instead of appending you could copy the current text, prepend timestamps to any lines which don't have timestamps already, clear the window, and re-add the now-with-timestamps text. The problem with this is performance once your output window gets large. So you'd probably have to implement a kind of "lazy stamping" which does the clear and insert in the background, in order to avoid killing your IDE when (as is common) 100's of lines of debug output get emitted in a short time. Also, when you clear and re-add, if you're currently selecting text in the output window, your selection is lost.
Personally, I'd just do the easy thing and append timestamp lines rather than the harder pre-pend approach. Since stuff at the end of the line is hard to see without scrolling, I'd probably ensure there was a newline before the timestamp, so the user would see each batch of one or more output lines followed by one timestamp line.
It's possible there may be a way to hook the output window before text is displayed, but I couldn't find any such extensibility point in the VS Extensibility APIs.
One more idea: you could always roll your own tool window, e.g. "Ivan's Debug Output" which listens to events coming from the real output window, and echoes new lines (with timestamps) to your own tool window. This is probably the hardest option, but should do exactly what you want.
to add a new answer to an ANCIENT question, there's an feature in the productivity power tools 2013 extension and productivity power tools 2015 extension that add a timestamp margin to the output window, no code required.
I was looking for the same functionality. Colleague of mine came up with the $TICK macro in the message field, printing out the 'current' cpu ticks.
Take a look at these tips from Simon Chapman, too.
I wanted this functionality too, so eventually I wrote an extension to do it (much like Justin Grant suggested in the accepted answer). After using it for a while, I decided that relative timestamps were even more useful to me when debugging. If folks wanted absolute timestamps, I'm sure I could add that functionality back in. Anyway, if you're interested you can check it out at niahtextfilter.com.
And to show the relative timestamps in action in a Visual Studio debug session:
The scrollbar scrolls way past the end of my class. Is there any way to adjust this? Is it just the VS convention? I can't delete the space, so it isn't carriage returns.
The reason I don't like this is that I keep accidentally scrolling past the end of my class!
I'd especially like to hear from people who actually have Visual Studio 2008 installed ;)
Either you have extra newlines (the cr/lfs Jim Anderson was talking about) in which case you can just select all the blank lines and hit delete to get rid of the extra space. The other possibility is that what you think is blank space is just the IDE letting you scroll down one page past the end of the file (until the last line of the file is at the very top of the screen). This is to let you scroll to the bottom of the file and start typing without causing the screen to scroll every time you start a new line.
Edit:
A quick glance at the other editors on my computer shows that this sort of thing is common - CodeWright will let you keep scrolling down as far as you want (pages and pages past the end of text) - although it does show the scroll bar as being all the way to the bottom when the bottom of the file is in the middle of the screen of text.
Even basic tools like Query Analyzer have this.
This is a feature (no, not a bug relabeled a "feature").
Reboot? No seriously, more information is needed.
I am guessing you have CR/LFs you you need to delete.