TextOut() to a DialogBox ???
in [MFC]
|
From: Joseph M. Newcomer on 24 Mar 2010 17:18 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 24 Mar 2010 17:39 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 24 Mar 2010 18:00 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 24 Mar 2010 18:29 "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 24 Mar 2010 18:45
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 |