TextOut() to a DialogBox ???
in [MFC]
|
From: Peter Olcott on 24 Mar 2010 13:15 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... > For all practical purposes, NONE. It is really bad style > to write directly on a dialog > box. I already know that. My purpose is to minimize development time for code that will only be used for testing purposes. > > If you want text on a dialog box, place a static control > there and use SetWindowText to > tell it what to display. I don't think that will work because I need to specify every detail of the text, its font, foreground color, et cetera. In any case this is all moot now anyway. I am simply bitblt-ing my memory bitmap to the window. > > Developing the style of writing directly to a dialog box > surface will eventually uncover a > large set of problems, none of which you want to deal > with. > joe This is only for internal testing purposes. > > On Tue, 23 Mar 2010 14:54:04 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>What are the options for directly writing text to a >>DialogBox? >> > 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 13:56 Peter Olcott wrote: > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in > message news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... >> If you want text on a dialog box, place a static control >> there and use SetWindowText to >> tell it what to display. > > I don't think that will work because I need to specify every > detail of the text, its font, foreground color, et cetera. > In any case this is all moot now anyway. I am simply > bitblt-ing my memory bitmap to the window. > >> Developing the style of writing directly to a dialog box >> surface will eventually uncover a >> large set of problems, none of which you want to deal >> with. >> joe > > This is only for internal testing purposes. Then even more the reason to just use the IDE and controls as to not waste time learning something you will never use anyway - like Intel Chip Caches. :) -- HLS
From: Peter Olcott on 24 Mar 2010 14:46 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ufF$nt3yKHA.928(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > >> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >> message >> news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... > > >>> If you want text on a dialog box, place a static control >>> there and use SetWindowText to >>> tell it what to display. >> >> I don't think that will work because I need to specify >> every detail of the text, its font, foreground color, et >> cetera. In any case this is all moot now anyway. I am >> simply bitblt-ing my memory bitmap to the window. >> >>> Developing the style of writing directly to a dialog box >>> surface will eventually uncover a >>> large set of problems, none of which you want to deal >>> with. >>> joe >> >> This is only for internal testing purposes. > > Then even more the reason to just use the IDE and controls > as to not waste time learning something you will never use > anyway - like Intel Chip Caches. :) > > -- > HLS Apparently the test the you proposed and I adapted showed that Cache is more effective than I thought it would be.
From: Peter Olcott on 24 Mar 2010 16:39 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ufF$nt3yKHA.928(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > >> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >> message >> news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... > > >>> If you want text on a dialog box, place a static control >>> there and use SetWindowText to >>> tell it what to display. >> >> I don't think that will work because I need to specify >> every detail of the text, its font, foreground color, et >> cetera. In any case this is all moot now anyway. I am >> simply bitblt-ing my memory bitmap to the window. >> >>> Developing the style of writing directly to a dialog box >>> surface will eventually uncover a >>> large set of problems, none of which you want to deal >>> with. >>> joe >> >> This is only for internal testing purposes. > > Then even more the reason to just use the IDE and controls > as to not waste time learning something you will never use > anyway - like Intel Chip Caches. :) > > -- > HLS Here is an interesting note that I don't understand. A slight revision (to make it a little less CPU intensive, thus more memory intensive) only actually achieves 21 MB per second of the 12 GB / second maximum RAM speed. (RAM speed reported by MemTest86). 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];
From: Joseph M. Newcomer on 24 Mar 2010 17:15
Where is this code found? Presumably it is an OnPaint handler. It is really bad code. I have no idea why you the the BkColor should be RGB245, 245, 245); in fact that is nonsense. At the very worst it should be SetBkCollor(::GetSysColor(COLOR_3DFACE)) so you follow the end user's color scheme (right now it is hardwired to your scheme, which may not be mine). But SetBkMode(TRANSPARENT) would be a better choice. But don't write to a dialog surface! As already pointed out, use a static control and draw on it if you need custom drawing. Also, RGB(0,0,0) should be ::GetSysColor(COLOR_WINDOWTEXT) so you follow my choice of colors, not yours. ANd I presume the 45,45 coordinates are for a toy example, since in a real application you would never want to hardwire numbers lke that. It is considered good practice to NOT use literal strings as you have done, but store the string in a variable, so you don't have to hardwire numbers like "14". More below... On Tue, 23 Mar 2010 16:34:09 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"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? >> > >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) ) ) *** Why not CPaintDC dc(this); There is no reason you needed a raw HDC here, and CPaintDC would be a better choice for the OnPaint handler (which is where this code had BETTER be, in spite of the fact you neglected the essential information of what function it was in!) Note that ::BeginPaint ONLY works in an OnPaint handler! So if you aren't in an OnPaint handler, there is no way this code can be considered correct. *** > ::MessageBox(this->m_hWnd, L"BeginPaint() failed", >L"error", NULL); *** NEVER use ::MessageBox in an MFC program; ALWAYS use AfxMessageBox. **** > SetTextColor(hdc, RGB(0, 0, 0) ); **** As indicated, RGB(0,0,0) is a really poor programming style; the correct code would have been dc.SetTextColor(::GetSysColor(COLOR_WINDOWTEXT)); **** > SetBkColor(hdc, RGB(245, 245, 245) ); ***** It would be best to have done dc.SetBkMode(TRANSPARENT); but if you MUST set the color, it would have been dc.SetBkColor(::GetSysColor(COLOR_3DFACE); **** > ::GetClientRect(this->m_hWnd, &rect); *** THis was completely silly; the correct code would have been CRrect rect; GetClientRect(&rect); there is no need to use ::GetClientRect, use this->, or use the raw API here for ANYTHING; because you are using 'this', it indicates that this is a function in your CWnd class, so CWnd::GetClientRect works without all this low-level folderol! Note since you are programming in C++ you don't have to use the obsolete C syntax of putting declarations at the top of the block. **** > if (!TextOut(hdc, 45, 45, L"this is a test", 14) ) *** As already pointed out, this is poor style, to draw on a dialog; the use of a hardwired number, 14, is exceptionally poor programming style, and the correct approach would have been to have placed a CStatic where you want the text to appear, give it a control ID other than IDC_STATIC, bind it to a control variable (for example, "c_Text"), and then have written c_Text.SetWindowText(_T("this is a test")); which is how most Windows programmers would have written it. There is no reason to ever draw anything on a dialog box, and bad practice to do so. Note that you would not have ANY code in the OnPaint handler of the dialog, which is how it should be, and you could call SetWindowText anywhere you want in the dialog code, not just in the OnPaint handler. In fact, it would be poor practice to do anything in the OnPaint handler. The gratuitous OnPaint handler you get from MFC is completely silly now, and applied only to Windows NT 4.0. **** > ::MessageBox(this->m_hWnd, L"TextOut() failed", >L"error", NULL); **** The correct approach here is AfxMessageBox(_T("TextOut() failed"); there is no reason to use ::MessageBox. You seem to think that if you use one raw API function anywhere you must use nothing but raw API functions EVERYWHERE. Not true. **** > ::EndPaint(this->m_hWnd, &ps); **** By using a CPaintDC, you would not need the ::EndPaint call. But since you should not have an OnPaint handler at all, the whole thing is pointless. joe **** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |