From: Joseph M. Newcomer on
Drawing anything on a dialog surface is usually bad practice.

The translations to MFC are trivial; ::BeginPaint => CPaintDC dc(this);
and everything else is trivial changes to use CDC methods.
joe


On Tue, 23 Mar 2010 20:29:37 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>All I was looking for is a conversion of this Win32 syntax
>into MFC syntax.
>This too is now moot. I don't use TextOut() to the
>DialogBox, instead I paint my memory bitmap to the
>DialogBox.
>
>"Liviu" <lab2k1(a)gmail.c0m> wrote in message
>news:eOjuMDvyKHA.5936(a)TK2MSFTNGP04.phx.gbl...
>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
>> news:e7qdnQgVv-FOrjTWnZ2dnUVZ_gmdnZ2d(a)giganews.com...
>>>
>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
>>> news:JpqdnVXVF9zAgTTWnZ2dnUVZ_iydnZ2d(a)giganews.com...
>>>>
>>>> What are the options for directly writing text to a
>>>> DialogBox?
>>
>> Same as for TextOut'ing to any other window.
>> What have you tried, and how did it not work?
>>
>> See also http://support.microsoft.com/kb/141863 for a few
>> different options - replace BitBlt with TextOut, of
>> course.
>>
>>> Now I only need a way to convert this from clumsy Win32
>>> to cleaner MFC:
>>>
>>> RECT rect;
>>> HDC hdc;
>>> PAINTSTRUCT ps;
>>> if (!(hdc = ::BeginPaint(this->m_hWnd, &ps) ) )
>>> ::MessageBox(this->m_hWnd, L"BeginPaint() failed",
>>> L"error", NULL);
>>> [...]
>>
>> You must be half way there ;-) since "this->m_hWnd" is
>> definitely
>> not Win32 API and looks very much like clumsy MFC already.
>>
>> Btw, not directly relevant to your question, but using
>> ::MessageBox
>> with L"" strings is inconsistent, and an error waiting to
>> happen (next
>> time one changes the unicode settings). Either use
>> ::MessageBoxW
>> with L"", or ""MessageBox with _T("").
>>
>> Liviu
>>
>>
>>
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
See below...
On Tue, 23 Mar 2010 23:09:05 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote:

>
>"Liviu" <lab2k1(a)gmail.c0m> wrote in message
>news:OypYNBwyKHA.4492(a)TK2MSFTNGP05.phx.gbl...
>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
>> news:Uoudnfsmrcno5TTWnZ2dnUVZ_vydnZ2d(a)giganews.com...
>>>
>>> http://groups.google.com/group/microsoft.public.vc.mfc/msg/2aa003e71f5a1b38?hl=en
>>> It is the CDC that has the default bitmap.
>>
>> The HDC, to be precise.
>>
>> Anyway, that is very different from what you said, then
>> misattributed
>> to Joe for having said. The distinction was the point of
>> the exercise.
>> http://groups.google.com/group/microsoft.public.vc.mfc/tree/browse_frm/thread/c84953c13066a4f3/4b4e98102ea69979?hl=en&rnum=11&_done=%2Fgroup%2Fmicrosoft.public.vc.mfc%2Fbrowse_frm%2Fthread%2Fc84953c13066a4f3%3Fhl%3Den%26#doc_4b4e98102ea69979
>>
>>
>>
>
>Personally I really hate dealing with tedious little
>details, the only reason that I can be good at software
>development is my continued focus on the big picture gist of
>things. This makes me very good at architectural (and other
>levels of) design, and lousy at debugging someone else's
>code.
****
If you hate dealing with tedious little details, you are in the wrong profession.

Seriously, if you look at what makes an MVP, we all are obsessed with making sure those
tedious little details all work correctly. Just read anything Tom Serface, or Giovanni
DiCanio, or I write, or any other MVP,, and all we're discussing are the fiddly little
details. Big picture is cool, but what makes it WORK are all those fiddly details. And
in 47 years of programming, in a variety of languages on a variety of platforms, I've
found that this is the difference between the successful programmer and the wannabe; the
successful programmers know all the fiddly little details that make things really run, and
run right, and run optimally, in whatever environment they are working in.

I became an expert in Chained Channel Control Words on the IBM/360 architecture. I could
write entire programs in CCWs. I could make I/O devices stand up and tapdance.

I knew infinite details of the PDP-11 Unibus protocol. I could tell you more about the
PDP-11 interrupt system than most people wanted to hear.

One day, I worked with another guy at CMU and we deep-sixed the high-bandwidth
communication project by reading the schematics and demonstrating that as designed the
device would deadlock and hang under certain timing conditions that could not be
controlled and predicted. This saved tens of thousands of dollars that would have been
wasted on a piece of hardware that could never be made to work correctly as designed. He
traced the read circuitry while I traced the write circuitry and we then looked at each
other and said "this will never work!" and then spent another four hours showing that not
only could software put it into this unusable state, but once in it, the state could not
be detected or reset.

I knew how VAX caches worked, and DECSystem-20 caches worked.

I was the Master of the JSYS on DECSystem-20.

You don't succeed in this business without being a walking encyclopedia of trivia. Big
pictures don't matter if you can't make them work on real systems.
joe
****
>
>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.
>
****
But it only works up to your design limits. The recent discussion of multithreading shows
that the if the elegant design fails to account for reality, it isn't a very good design.
Real designs have to be flexible. Historically, the only other person I ever knew that
said this wrote code that worked the first time; but he was months late on delivery
because while the rest of us were debugging real code that mostly worked, he was still
thinking about his code. And it was horrendously slow; when I measured it, and pointed
out the problems, he told me not a line could be changed because all the decisions were
interacting and comitted, and on one line could not be changed without disrupting the
entire application. We call that "fragile code". In robust code, you can replug entire
modules without anyone noticing the change. So we were stuck with the horrible
performance, because the code was so complex no one else could understand it. But he
never did any debugging on the machine; it was all desk debugging.
joe

Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on
Peter Olcott wrote:

>
> const uint32 size = 100000000;
> std::vector<uint32> Data;
> uint32 Max = 0x3fffffff;
>
> void Process() {
> clock_t finish;
> clock_t start = clock();
> double duration;
> uint32 num;
> for (uint32 N = 0; N < Max; N++)
> num = Data[num];
> finish = clock();
> duration = (double)(finish - start) / CLOCKS_PER_SEC;
> printf("%4.2f Seconds\n", duration);
> }
>
> Another thing that I don't understand is that it crashes
> when
> num = Data[num];
> is replaced by
> num = Data[N];


Divide and conquer! 99.9999999999999999% (ok, 99.0567%) of the time,
a GPF (General Protection Fault) is because you are basically
referencing protected memory that doesn't belong to you. This is
part of the reason for virtualization - to manage the memory
references to help protect against buggy applications killing others.

The reference or pointer could be due to miscalculation or corruption
called Buffer Overflow or UnderFlow or just plain Clobbering.

This is a buffer overflow:

char peter[10]; // 9 bytes + null
char hector[10]; // 9 bytes + null

// off by one, one byte flows over to hector.
strcpy(peter,"1234567890");

Buffer overflow is the typical error with most bugs, and the one
hackers try to create in the stack.

Buffer underflow is the opposite, maybe by miscalculating a pointer:

strcpy(hector - 2, "1234567890")

These are harder to see because you underflowing hector by putting two
bytes at the end of peter. Peter still has a length of zero because
the first byte is NULL.

In any case, a GPF is about accessing memory that does not belong to
you. It is protected memory, hence the term General Protection Fault.

--
HLS
From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:%23%23NVo15yKHA.264(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>>
>> const uint32 size = 100000000;
>> std::vector<uint32> Data;
>> uint32 Max = 0x3fffffff;
>>
>> void Process() {
>> clock_t finish;
>> clock_t start = clock();
>> double duration;
>> uint32 num;
>> for (uint32 N = 0; N < Max; N++)
>> num = Data[num];
>> finish = clock();
>> duration = (double)(finish - start) / CLOCKS_PER_SEC;
>> printf("%4.2f Seconds\n", duration);
>> }
>>
>> Another thing that I don't understand is that it crashes
>> when
>> num = Data[num];
>> is replaced by
>> num = Data[N];
>
>
> Divide and conquer! 99.9999999999999999% (ok, 99.0567%)
> of the time, a GPF (General Protection Fault) is because
> you are basically referencing protected memory that
> doesn't belong to you. This is part of the reason for
> virtualization - to manage the memory references to help
> protect against buggy applications killing others.
>
> The reference or pointer could be due to miscalculation or
> corruption called Buffer Overflow or UnderFlow or just
> plain Clobbering.
>
> This is a buffer overflow:
>
> char peter[10]; // 9 bytes + null
> char hector[10]; // 9 bytes + null
>
> // off by one, one byte flows over to hector.
> strcpy(peter,"1234567890");
>
> Buffer overflow is the typical error with most bugs, and
> the one hackers try to create in the stack.
>
> Buffer underflow is the opposite, maybe by miscalculating
> a pointer:
>
> strcpy(hector - 2, "1234567890")
>
> These are harder to see because you underflowing hector by
> putting two bytes at the end of peter. Peter still has a
> length of zero because the first byte is NULL.
>
> In any case, a GPF is about accessing memory that does not
> belong to you. It is protected memory, hence the term
> General Protection Fault.
>
> --
> HLS

So here is the rest. I use a very comman pattern that
eliminates the off by one error.
allocate(size)
N = 0; N < size; N++

Why does the code below crash?

#include <stdio.h>
#include <stdlib.h>
#include <vector>
#include <time.h>

#define uint32 unsigned int
const uint32 size = 100000000;
std::vector<uint32> Data;
uint32 Max = 0x3fffffff;


void Process() {
clock_t finish;
clock_t start = clock();
double duration;
uint32 num;
for (uint32 N = 0; N < Max; N++)
num = Data[num];
finish = clock();
duration = (double)(finish - start) / CLOCKS_PER_SEC;
printf("%4.2f Seconds\n", duration);
}



int main() {
printf("Size in bytes--->%d\n", size * 4);
Data.reserve(size);
for (uint32 N = 0; N < size; N++) {
uint32 Random = rand() * rand();
Random %= size;
// printf("Random--->%d\n", Random);
Data.push_back( Random );
}

char N;
printf("Hit any key to Continue:");
scanf("%c", &N);

Process();

return 0;
}




From: Hector Santos on
Peter Olcott wrote:

> void Process() {
> clock_t finish;
> clock_t start = clock();
> double duration;
> uint32 num;
> for (uint32 N = 0; N < Max; N++)
> num = Data[num];
> finish = clock();
> duration = (double)(finish - start) / CLOCKS_PER_SEC;
> printf("%4.2f Seconds\n", duration);
> }
>


All I can see is that you have an uninitialized num variable. When
not initialized it can be an random number including one that exceeds Max.

So initialize it:

uint32 num = 0;
for (uint32 N = 0; N < Max; N++)
num = Data[num];

and see if that solved it for you.

Under Windows, it doesn't have a idea of "Load High" or "Load Low"
some mainframe folks are use to where your process memory will be
guaranteed to be non-zero (high) or zero (low). In C/C++ *natural
or native type* variables MUST be initialized before referenced
otherwise you will intermittent issues. It didn't happen before only
because you lucked out the memory was still low, it wasn't dirty and
num started at zero. But it was bound to rear its head once dirty,
and there again, it had to be a reference out of range or into
protected memory.


--
HLS