|
I just discovered, quite by accident, that if you drag the hairline at the right end of the value property of the list box that displays the names and values of the MsBuild macros, the hairline keeps moving to the right even when you drag outside the bounds of the control. Thus, you can keep dragging until it is sufficiently wide to show the end of the property of interest, such as, in my case, $(ProjectDir).
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
My hair line has moved on it own, revealing more of the head property
|
|
|
|
|
LOL
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
This works great for Task Manager to see really long command line paths.
You can do it multiple times such that the width of the column can be many times wider than the width of your monitor.
|
|
|
|
|
englebart wrote: This works great for Task Manager to see really long command line paths.
You can do it multiple times such that the width of the column can be many times wider than the width of your monitor.
That's good to know for reference.
Making columns wider than my monitor wasn't the part that surprised me, though. The aspect that did was that dragging continued to work even as the mouse pointer went beyond the border of the containing window.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
This is known as "Mouse Capture". Native Windows and dotNET apis are available.
Same effect if you press a native command button with a mouse but do not release it. You can roam the mouse all over the place, but if you come back to the button it will depress again. The button captured the mouse. Pretty standard for any dragging operation.
That all being said, resizing beyond the borders is not very intuitive. It seems like you are breaking a rule or something.
|
|
|
|
|
englebart wrote: This is known as "Mouse Capture". Native Windows and dotNET apis are available.
That all being said, resizing beyond the borders is not very intuitive. It seems like you are breaking a rule or something.
I know that in principle, although I had forgotten the technical term for it, since I try to stay away from UI design, because it is neither my forte nor fun for me. When possible, I'll leave that to others who are more skilled than am I.
In any case, I don't recall noticing other mouse capture events that persisted beyond the border of the window in which they commenced, and I agree that the behaviour is counter-intuitive.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Double-clicking the hairline should be enough
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Double-clicking the hairline should be enough
That works in many contexts, and I use it frequently, though I can't remember whether I remembered to try it in the Visual Studio/MSBuild macros window.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
It's something I often forgot to add when using a DGV or listview, but it is a nice feature to have
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Frustratingly I suspect it is limited to a little less that 2147483647 pixels though....
|
|
|
|
|
Just wait until your app contains a list view, and you record in the registry the last column sizes. The fun begins when you forget to verify that the registry values actually exist when you retrieve them, and you set your list view column widths to rather large 32-bit random values. Windows is perfectly happy to do it, and tell your drawing code to draw a cell that is 16 pixels tall and 8 parsecs long.
Software Zen: delete this;
|
|
|
|
|
Only eight parsecs?
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Well... It's not the Kessel run!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Forogar wrote: Well... It's not the Kessel run
I had to look that one up. I at least had a clue about the size of a parsec. It took a bit of noodling for me to grok that Solo was bragging about covering the distance "in only 12 parsecs." Once I read about them being unable to travel in straight lines, that part made sense, and I suspect the same holds for Warp drive.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: Once I read about them being unable to travel in straight lines They made a point of addressing that in the movie Solo[^].
Software Zen: delete this;
|
|
|
|
|
Okay, so I rounded off a little.
Software Zen: delete this;
|
|
|
|
|
Au contraire! This little exchange has been both enlightening and fun. Moreover, if you can cover the distance in only 8, you've bested Han Solo by a full third.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
This has been part of Windows since at least 3.1 (pre-32 bit). I'm not surprised you didn't know about this as I have to constantly teach this trick to my users (and developers).
|
|
|
|
|
In general terms, I know that. I've used Windows since almost day 1, and I don't recall ever seeing a drag work when the mouse pointer moves outside the boundaries of the windows that has the focus. That's good to know, so long is it doesn't make the thing 3 parsecs wide.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
foo.TryGetValue("bar", out object value);
var somestr = value.ToString();
Sort of defeats the purpose of the try when foo doesn't have the key "bar" or even if it does, the value might be null.
If I show this to the person who wrote it, do you think they'll suggest a try-catch block to not break the rest of the code?
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Brilliant! Promote this programmer to management so they don't write code that breaks the system with random null reference exceptions.
|
|
|
|
|
At least he tried
|
|
|
|
|
A classic case of "when a little knowledge is a dangerous thing". They understood that they needed to use TryGetValue() but not how to use it.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Prolog has the notion of "fail" and handles this gracefully (Visual Prolog in the example below):
facts % key_value lookup table
key_value : (string Key, integer Value).
predicates
tryGetValue : (string Key) -> integer Value determ.
clauses
tryGetValue(K) = V :-
key_value(K, V), % FAILs here if undefined key_value/2
!.
|
|
|
|