|
>> In Visual Studio, more width is nice, but split over 2 screens is annoying (to me), unless the two screens are doing different tasks.
Yes, the 24" is for VS (and at present it's enough), one of 19" is to run debugged application, there is also another point to consider (other then debugging opportunity), if you run your app in a 24 or 30" you can be inchs-addicted and forget the real end user point of view (we are developing for them).
Of course this is a developer point of view..
|
|
|
|
|
Davide Zaccanti wrote: if you run your app in a 24 or 30"
30"?!?!? I wish!!!
|
|
|
|
|
Couldn't have said it better myself. Breakpoints are visible when you hit them and so is that email from the business users telling me how great the new feature is working(sic).
Mike Devenney
|
|
|
|
|
Davide Zaccanti wrote: In Visual Studio it's mandatory if you want to debug an application
Bollocks! I've been programming *in* visual studio from all the way back in the early MFC C++ days up to the modern c# days and this is a fallacy.
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
I also start with C4 (and all others until C7 and first C++ version, then restarting from VC++ 1.00), and I was working in a 14" BW monitor in DOS mode.. I still have all 3 manuals of original C 5.0 ( around 1985 )
But I've just finished to debug a function in a library the must write in real time over a video source; believe me, it's impossible to debug in a single monitor, or use softice even if you have a giant 42"... And when you have 4..6 hours of debug sessions and in monitor one the app, in monitor 2 the source with ASM code, registry, stack and so on if you need to find on google you'll search another PC (but you cannot do copy&paste) or the third monitor..
Of course if workink in VS is drop items and link db fields or design database I can agree.. Sore in VB or similar problems of low level routine are less usual..
It's the same as printing Visio DB schema, if you have a serious db you need to ask someone with a plotter... puzzle are not so neat.
Cheers.
|
|
|
|
|
There is *always* a rare case that can be found to contradict any rule, but it still doesn't apply to the vast majority of developers out there.
To say one can't debug in VS without a second monitor is wrong, to say *you* personally can't debug without a second monitor may be true but you have to realize you're working on something a little more obscure than the majority. 
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
John C wrote: I've been programming *in* visual studio from all the way back in the early MFC C++ days up to the modern c# days and this is a fallacy.
Debug WM_PAINT handlers much? 
(yeah, yeah, i get it, there are plenty of scenarios where side-by-side debugging does little good... But anything where a screen refresh changes the scenario is very much more difficult without it)
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
I agree. Maybe it's because I only build server side and desktop apps (i.e. no games, medical imaging software, multimedia apps, etc.)
Also, saying 24" (or 30") without specifying the resolution doesn't make any sense to me. I happen to love my single 24" 1920x1280 Dell LCD.
/ravi
|
|
|
|
|
In my case it works perfectly and it is much more comfortable in normal applications as you can have the help system on one screen and the developing environment in the other one (speaking about two screens).
But In some cases, it is almost impossible to debug without at least two screens:
- I'm using one specific application that allows me to program a PLC that is PC based. That editor/programming environment allows me to place breakpoints.
- I'm using the VC++ to make the GUI of the application the operator of the machine will use.
- I need to be able to view the changes in the GUI and into the PLC app and into the code at the same time in order to be able to test everything just before testing into the real machine and risk to crash something.
In that case I can promise you it is much more easy to do it with multiple displays.
PS: moreover the way the data is shared between the VC++ app and the PLC app hangs the VC++ editor and the PLC editor if too much time has passed in the debugging stage. Something about the real time needs of the PLC system...
I AGREE WITH YOU IN THE FACT THAT IT IS A FALLACY: it is not mandatory, but it is not only a matter of being a wannabe "into the matrix style" (at least not in all the cases), in my case for example, I use it and I take a lot of advantage from that.
I've been a long time programming alone here and all the help has been welcome... You should try it, I'm sure that you will think "why on earth I've not used it before"... I've gained a lot of time.
As an example:
When you program, you don't have to remember the variable name that you must access in the PLC app as you can see it while you are writing the C++ code...
|
|
|
|
|
Yup, I don't disagree with you at all, someone else brought up a very similar case and as I said before there are always edge conditions that don't disprove for the majority of the cases. I fully understand that and I would do similar in your case but I would shut off the other monitors when not using them for that special case while I was working as they would be too distracting.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
I agree with you but multiple screens very seldom are a necessity for programmers (I like sci-fi games too  ). I use 3 20.1" wide screens at the office (and i'm gonna add a fourth one soon) but i'm working on mechanical and engineer software like Tekla structures (Xsteel), AutoCAD and some other common apps at the same time. Multiple monitors although laghable by many, can really relief you of pain, stress and boost your productivity to the roof.
My boss although reluctant to invest to them is now starting to see things from a whole different perspective as his requests are being served faster and more efficiently.
I can understand how that may confuse people as it can get a while to get used to but in the end it will make them work better, especially if their job requires fast response and continuous interaction with many software applications at a time.
Cheers ....
|
|
|
|
|
micmanos wrote: especially if their job requires fast response and continuous interaction with many software applications at a time.
Most programmers are fooling themselves if they think continually interrupting what they're working on to go to something else is more productive than focusing on one task at a time. I say most because there are some very (extremely) rare cases where the task at hand of programming involves more than one screen but it's so rare as to be firmly the exception rather than the rule. Every modern study of human computer interaction bears out that you can't be productive when presented with too many different things to work on at the same time.
"The great pleasure in life is doing what people say you cannot do."
- Walter Bagehot
|
|
|
|
|
I am constantly referencing an object model and/or data model while coding...it's nice to have them visible on screens, rather than ALT-TABing between them.
|
|
|
|
|
I agree with what you say.
We cannot multi-task as a programmer because writing code requires ones highly focused attention. I do a little programming on occasion and i can relay to your point of view. Programming however is only a small part of what computers are used for today. Most companies use software and computers to run their business rather than be the business. This means that information & data handling very often require manual interaction between different apps and that's where the ease of having a large work area is of use. Now, multiple screens have the advantage of splitting the desktop and using more than 1 maximized apps so it's mostly personal preference.
My conclusion (not expecting anyone to relay though) is that being in this forum, certainly means that most of us are involved in programming as the major work in our jobs but compared to what the rest of the world uses computers for, i'd say that we're the exception.
|
|
|
|
|
Supposedly MS did a survey just a few years back that dual monitors boosted productivity for an average user by 15%. And I can see why, most users have difficulty dealing with overlapping windows and just maximise the apps window to avoid confusion. Two monitors, two maxmised applications, big productivity boost.
But I've also met plenty of people who hate multiple monitors, they seem to be of the "Where's my teletype" brigade.
I am convinced that lobotomising users will make little to no difference.
|
|
|
|
|
|
You need your computer box outfitted with neon's, and a glowing keyboard before your at the helm of a spaceship... duh... everyone knows that!
|
|
|
|
|
When an application crashes, the keyboard need to emit a shower of sparks. Instead of a BSOD, the monitors just explode.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
|
I started out on 24x80 and 16x64 ascii display terminals. Multiple screens at current high resolutions provides a flexibility I could not even have imagined in 1976. We've come a long way.
That said, I do have to admit that, being a creature of habit, my tendency is all too often to do program editing in a command window using VI! 
|
|
|
|
|
My first dual monitor experience was on my 286 - when upgrading from Hercules MGA to VGA. (Yay!) They worked at different memory adresses, and luckily monitors weren't compatible, and extra luckily, Turbo Pascal 5 supported that: I could have the debugger on one monitor, and the applicaiton run on the other. It was marvelous!
Actually took me a while to realize that it wasn't great only back then, and I actually could afford it easily (and stop envying all the guys with e-peen monitor setups )
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
I like not having to use punch-cards. After that everything is gravy.
|
|
|
|
|
geoffs wrote: being a creature of habit, my tendency is all too often to do program editing in a command window using VI!
I do that too, and I am not a creature oh habit. Worked with various IDEs, and came to conclusion that none of them beats vi(m) for code editing tasks.
|
|
|
|
|
I had to fix some problem which occure on a program with multiple screens. If the prog was on the secondary screen minimized, and got restored on the first one. 
I like me second screen a lot: I can read the help or compare bigger chunks of code.
Greetings from Germany
|
|
|
|
|
I have been using multple screens for about 8years now (i Think, actually my first forray was back in 1994 when i attached a Hurcules mono monitor to me vga based system and used it to show debug information) my first setup was a 20" + 17" crt. I have now progressed to 2 x 20" lcd's.
I have found dual monitors for programming to be a great boon as I can run Visual studio full screen on one monitor and have the help, firefox (with Code project of course!) on the other and when debugging i would have the application under debug on the second monitor which is quire handy esp if you need to see the what the application does when stepping through code.
The other senario that I find makes dual monitors usefull is if you need to refer to other source code files while editing another, here you can have a second text editor (e.g. Ultra Edit or Notepad++) running on the second monitor.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
