|
I've been reading pages and pages of the old posts here, and it seems people are using OnPaint to do the drawing at times.
In Class Wizard (VC++5), when I select WM_PAINT message the info box explicitely says:
"Indicates a window frame needs repainting (do NOT use for views)
So this means, they don't want us to override it in View class? For this reason, I have only used OnDraw so far to draw EVERYTHING. Am I missing something here? Whats the difference between OnPaint and OnDraw?? Thank you.
|
|
|
|
|
OnPaint is a WM_PAINT handler. OnDraw is an MFC construct that lets you use the same code for drawing on the screen and printing. Notice how OnDraw has a CDC* paramter - MFC sets up the device context correctly for you and passes that to OnDraw.
So yes, OnDraw is the right function to use.
--Mike--
http://home.inreach.com/mdunn/
#include "buffy_sig"
|
|
|
|
|
ahh I see. Thanks, that's clear. So I just ignore WM_PAINT OnPaint then, and get on with OnDraw. It's puzzling though, when people talk about OnPaint... They might just as well say OnDraw in the first place if thats what they're referring to by OnPaint or WM_PAINT...
Thanks again.
|
|
|
|
|
If you use OnPaint, you can select when the device context is called, by moving the call to CPaintDC. This is useful because there is no point in double buffering if you draw to your memDC and the screen has been blanked by CPaintDC - you still get flicker.
The alternative is to do your double buffering in OnPrepareDC, which is called prior to OnDraw and the DC from OnPrepareDC is passed to OnDraw. However, as a lot of examples use OnPaint, it's hardly surprising that a lot of people use it as well ( myself included from time to time ).
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
So, there's no point in double buffering in OnDraw?? What I've done so far is to use memDC to do rendering then BitBlt to pDC, and also override WM_ERASEBKGRND to prevent erasure of background.
So what I should do is to use OnPaint instead, don't override OnEraseBkgrnd, and draw using memDC (backbuffer) then at the VERY last minute I call CPaintDC (causing screen blank) to get dc for BitBlt?
|
|
|
|
|
I'd use OnPrepareDC, which passes to OnDraw, but caling PaintDC at the last possible moment in OnPaint will give the same result. Of course, if you've overridden OnEraseBackground then all should be fine anyhow, but it's less messy to let OnErase do it's job ( or your version of it's job, for example to draw a texured background ) and set the rest up accordingly.
Jonathon
|
|
|
|
|
I see - I never knew those various methods.
I hated messing with OnEraseBkgrnd so I guess I'll do that OnPrepareDC way. That sounds a lot cleaner and more "decent" way to do it.
Thanks!
|
|
|
|
|
I personally use OnErase to only draw to the area not covered by my bitmap ( when someone maximises ) and use OnPrepareDC to draw the bitmap. I don't think there is one *right* way of doing things ( hence the variety of methods available ), but if just using OnPRepareDC suits your current application it is certainly the easiest way to go.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
There's one drawback associated with painting in OnPrepareDC. If your view is derived from CScrollView, you call OnPrepareDC before converting from device to logical coords, and vice versa. Complex drawing code may slow things down - DP/LP conversion is usually done during mouse-related events, when user draws the selection rectange for example.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Well... I guess I'll go back to the good ole OnDraw & Erase combo, that might be best after all.
>I'd say this is the right way. I'm using it without any problems.
>Do you have any special requirements?
There's a frame along the client, which I draw nearly always... It just occured to me, I could draw that in OnErase for "erase" purposes.... what an idea. Kill 2 birds with 1 stone, Why didn't I think of that before?
|
|
|
|
|
> So, there's no point in double buffering in OnDraw?? What I've
> done so far is to use memDC to do rendering then BitBlt to pDC,
> and also override WM_ERASEBKGRND to prevent erasure of background
I'd say this is the right way. I'm using it without any problems. Do you have any special requirements?
OnPaint without overriden OnEraseBkgnd will cause flicker - moving CPaintDC will only reduce the effect.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Hi,
while creating a DLL, When I was trying to put some dialog boxes and compile it, I got an error "Unidentified identifier IDD_DIALOG".
My question is that how can i pack resources in a DLL using MFC?
|
|
|
|
|
Partial answer to a tough question (and I'm stretching my knowledge here) but I think the app invoking the DLL needs to know about the resource template for the dialog as well as the resource defines. You will need to include a resource header that defines IDD_DIALOG, and also the .rc file that contains the dialog template.
As a simple test, I made a test DLL that exported a fn that invoked a dialog (as opposed to exporting a CDialog based class) and had no success showing it until I added the .rc file for the DLL into the apps Resource Includes (on the View menu).
I don't think this is very robust though, as resource ID conflicts are bound to occur in a large project - you might want to be careful about the 'exported' ids. I think the idea is to use at least 2 .rc files on the DLL side. One that can be included by consumer apps that has stuff they need, and one to hold DLL internal version info etc.
MFC has several .rc files that are included by standard apps depending on what resouces (e.g. font dilaog) they need. I think there is an advantage here in that you can override templates in your app to customize common dialogs etc. Not something I do everyday. 
|
|
|
|
|
I have a problem regarding char*'s and character arrays....
Firstly to use strcat it seems I have to use a character array:
char ret[64] = "";
If I use a char* as the strcat argument it just doesnt like it!
But the function needs to return a char*. If I do;
return ret; (as declared above)
then I get an error (returning address of local variable).
I tried to get around this by doing:
char ret[64] = "";
char* tmp;
tmp = &ret[0];
This seemed to work fine, it passes the pointer, but when I try and cout
the value (ie cout << returnedValue; ) in my main function it just outputs
a load of garbage. I checked that the pointer is pointing to the right thing
before returning it and it is, so Im just thinking the area of memory could be
messed up in that short space of time...I have attatched the code in case im not
being clear!
Thanks
Any help appreciated
Code:
char* TicTacToe::formatForPrinting() {
char ret[32] = "";
for ( int rows = 0; rows < BOARD_SIZE; rows++ ) {
for ( int cols = 0; cols < BOARD_SIZE; cols++ ) {
if( gameBoard.position[rows][cols] == 1 ) {
strcat(ret,"X");
strcat(ret," ");
}
else if ( gameBoard.position[rows][cols] == 2 ) {
strcat(ret,"O");
strcat(ret," ");
}
else if ( gameBoard.position[rows][cols] == 0 ) {
strcat(ret,"-");
strcat(ret," ");
}
}
strcat(ret,"\n");
}
char* tmp;
tmp = &ret;
return tmp;
}
int main() {
// Create game object
TicTacToe* game = new TicTacToe;
char* b;
cout << "You are X, the board is currently:\n";
b = game->formatForPrinting();
cout << b << "\n";
return 0;
}
|
|
|
|
|
You are not allocating memory on the heap for the object. The memory you are trying to use is in the local stack defined for the block you are in for that function call. Either dynamically allocate memory for the array, or better, define your char array on the call side, and pass it in to the formatForPrinting call. BTW, why aren't you using CString - it handles all that for you?
|
|
|
|
|
I tried:
char* ret = new char[32];
i presume this is what you mean by dynamically allocating memory.... This results in a load of junk in the array elements which arent used, presuambly because its not initialised. Although it does pass the right thing back as well.
Is it the done thing to allocate the memory on the call side then? I guess thats a better way of doing things..
I might start using CStrings. I have tried to avoid them so I wont have any problems if I go to another platofrm (arent CString just VC++).... I also thought in the long run it might be better if I had the increased control, do you disagree with this?? Im begining to think its more trouble than its worth...
Thanks for your help
Ben
|
|
|
|
|
Well, if you don't like the garbage in it, you can always fix that with ZeroMemory, or memset. As to the your other concern, I think that if you want to do all of your own string type operations without help from MFC, you would be well advised to either, preferably, use the STL string class, or, cook up your own well defined string class. Not wanting to be enslaved to MFC is understandable, but you should be sure that you really need to go to the extra effort of not making it dependent on MFC. Otherwise, you are just makeing extra work for yourself for no good reason.
|
|
|
|
|
If portability is a concern, then use std::string from the STL.
But I think that's just avoiding the issue, which is you just don't understand pointers and memory management yet. (That's not a knock on you; it is a tough subject.) Eventually, if you program C/C++, you will have to use them and understand them.
--Mike--
http://home.inreach.com/mdunn/
#include "buffy_sig"
|
|
|
|
|
Hello, the codegurus around the world.;)
I guess that one mistake is
char* b;
b = game->formatForPrinting()
should be
string.h
.....
int len = strlen (game->formatForPrinting);
char *b = new char[len + 1];
strcpy (b, game->formatForPrinting);
However, I didn't check this at my code, so...
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
Hi all,
I want to know what is best way to appending text in last of editbox ?
m_Edit1.GetWindowText(pString, 50);
strcpy(pAll, pString);
m_Edit1.SetWindowText(pAll);
do you have better idea ???
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hello, the codegurus around the world.;)
CString sBaseString, sNewString(" This is the text appended!");
m_Edit1.GetWindowText(sBaseString);
sBaseString += sNewString;
m_Edit1.SetWindowText(sBaseString);
or
UpdateData(FALSE);
sBaseString = m_strEdit1;
sBaseString += sNewString;
m_strEdit1 = sBaseString;
UpdateData(TRUE);
However, I didn't check this at my code, so...
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
Hi,
can you write it by using of LPSTR instead CString ?
Thanks ...
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hello, the codegurus around the world.;)
I will give you some references.
WINUSERAPI
int
WINAPI
GetWindowTextA(
HWND hWnd,
LPSTR lpString,
int nMaxCount);
WINUSERAPI
int
WINAPI
GetWindowTextW(
HWND hWnd,
LPWSTR lpString,
int nMaxCount);
#ifdef UNICODE
#define GetWindowText GetWindowTextW
#else
#define GetWindowText GetWindowTextA
#endif // !UNICODE
<br>
typedef LPSTR LPTCH, PTCH;
typedef LPSTR PTSTR, LPTSTR;
typedef LPCSTR LPCTSTR;
typedef CHAR *LPSTR, *PSTR;
Other hint is to search "Data type" of Platform SDK: Win32 API of MSDN help.
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
How can i monitor the time that the connection is taking, meaning that if i have opened a connection to the net and i want to timelimit it lets say for 5 minu. how can i do it?
thanks,
|
|
|
|
|
kick off a timer and kill the connection when it expires?
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
