TextOut() to a DialogBox ???
in [MFC]
|
From: Geoff on 25 Mar 2010 19:06 On Thu, 25 Mar 2010 16:21:58 -0500, Joseph M. Newcomer <newcomer(a)flounder.com> wrote: >Sadly, if we look at everything from Enron to the latest set of bank failures, ethics was >not a priority in business schools. "Screw everyone, as long as YOU win!" seems to have >been the message instead. And lock in those stock options early. Along with Resum� Building for CEO's and Fast-Track Back Stabbing for Upwardly Mobile Executives.
From: Tom Serface on 26 Mar 2010 12:23 Amen and amen. Only you should revise what you said to say, "everyone makes stupid mistakes every day". I think that's part of what programming is all about. The smart people work with communities or peers to make sure the stupid mistakes turn into smart programs. Tom "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:z66dnZWjfISxUTHWnZ2dnUVZ_hudnZ2d(a)giganews.com... > It is well known in this industry that sometimes completely obvious things > are not obvious to the one looking at them. I developed this code on the > command line and had an incorrect theory about what was occurring, this > theory indicated that a debugger would not help. > > It remains to be true that no degree of intelligence prevents one from > making stupid mistakes. Everyone makes a stupid mistake once in a while.
From: JustBoo on 28 Mar 2010 11:46 On 3/23/2010 9:09 PM, Peter Olcott wrote: > Personally I really hate dealing with tedious little details, [...] > I really can't stand debugging my own code, that is why I take very > extreme measures to prevent bugs from occurring in the first place. > I carefully design every single line of code, and check the design > many times before I even try to compile it. Most of the code that I > write mostly works the first time with only the most trivial logic > errors. Ding! Check Please! Wow, look kids, a rare and perfectly preserved Professional Troll from 1999. Classic. See how he has created numerous (yet totally useless) posts by yanking peoples chains. Well done, Mr. Troll, well done. I put instant coffee in a microwave oven and almost went back in time. -- Steven Wright
From: Peter Olcott on 28 Mar 2010 12:32 "JustBoo" <Boo(a)boowho.com> wrote in message news:sRKrn.36361$9b5.27405(a)newsfe01.iad... > On 3/23/2010 9:09 PM, Peter Olcott wrote: >> Personally I really hate dealing with tedious little >> details, > [...] >> I really can't stand debugging my own code, that is why I >> take very >> extreme measures to prevent bugs from occurring in the >> first place. >> I carefully design every single line of code, and check >> the design >> many times before I even try to compile it. Most of the >> code that I >> write mostly works the first time with only the most >> trivial logic >> errors. > > Ding! Check Please! > > Wow, look kids, a rare and perfectly preserved > Professional Troll from 1999. Classic. See how he has > created numerous (yet totally useless) posts by yanking > peoples chains. Well done, Mr. Troll, well done. Just because a statement may be unbelievable does not logically entail that this statement is not a verifiable fact, time will tell. > > I put instant coffee in a microwave oven and almost went > back in time. > -- Steven Wright >
From: Liviu on 29 Mar 2010 01:44
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... > "JustBoo" <Boo(a)boowho.com> wrote... >> On 3/23/2010 9:09 PM, Peter Olcott wrote: >>> Personally I really hate dealing with tedious little details, [...] >>> I really can't stand debugging my own code, that is why I take very >>> extreme measures to prevent bugs from occurring in the first place. >>> I carefully design every single line of code, and check the design >>> many times before I even try to compile it. Most of the code that I >>> write mostly works the first time with only the most trivial logic >>> errors. >> >> Ding! Check Please! [...] > > Just because a statement may be unbelievable does not logically > entail that this statement is not a verifiable fact, time will tell. Just curious, but how long a time would one expect before it "tells"? Looking at the recent "memory read speed test" code you posted in this thread, and referring strictly to the "most trivial logic errors" (not the deeper confusion of what you were trying to measure and match) but... it took two painfully obvious corrections before the thing even ran. Then, you had a couple more naivetes which just happened to cancel out, writing a loop with no side effects, but forgetting to "#define _SECURE_SCL 0" so that the loop wasn't optimized away altogether (but then contained std::vector bounds checking code which did not belong in a "raw speed' test). Later, there was at least one other correction from another group where you posted a followup, about that odd rand()*rand() idea. And the above doesn't even begin to nitpick on "boring details" such as whether you think that your latest "GetRandom" really returns a random uint32 (hint: no, just the lower 30 bits are random), or that "(double)(Max * 4)" might overflow, and what you really wanted was "(Max * 4.)". But of course, I trust that you were well aware of these, and the other hardcoded constants in the code were carefully and purposely chosen to work regardless. Also, that your "real code" never ever has any such problems, and you are just routinely teasing the newsgroups to check whether anyone was paying attention ;-) Liviu |