|
That's the second part of what I wrote earlier. You have to remember the coordinates to which you last drew the line. Then on a mouse move you redraw it again at the old location to erase it and draw it at the new location.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
I know the principle of the procedure.I use the SetRop2() function to realize it.But which parameter should I select? R2_NOT? Or R2_XORPEN?Almost all parameter I had test.None looks like correct.
And I've another question.I wrote message processed module associate to mousemove to draw line.But when the window is restore from behind other window,the line dispeared.Why?How can I resolve it?
Please help me!If you resolve my question,I can buy some gift for you if you want.;)
|
|
|
|
|
R2_NOT will work, it simply inverts the background pixels and ignores the pen.
R2_XORPEN will work better, as it lets you controlly the visual result better, using a dashed pen for example.
If it isn't looking correct I suspect you are not redrawing over the previous line exactly.
Things you draw during mousemove are not permanent. Your application needs to redraw everything, including the newly added line, when handling WM_PAINT as well.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
I have laboriously coded around this little problem for years and I know that the solution is quite simple. But I am resistant to change and hate having to delve into documentation.
I am getting that "class already defined" error message when I include the same header file in more than 1 source file.
Here is what is happening:
ClassX - a user defined class
Window1 - the apps main window
Window2 - a modal dialog box invoked from Window1
Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)
Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file
But it can't because it throws that error "C2011: 'ClassX' : 'class' type redefinition" error
Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?
If the compiler knows that the class is already defined, then why does it need the header file in both places?
|
|
|
|
|
Terry O`Nolley wrote:
Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)
Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file
Declare the ClassX header file in Window1's and Window2's cpp files and not in the h files. make sure you include this header *before* you include te header file for Window1/Window2. So Window1.cpp would ne :-
include classx header
include window2 header
include window1 header
...
and window2.cpp wopuld be :-
include classx header
include window2 header
...
Regards
Nish
Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live
|
|
|
|
|
Thanks Nish.
This brings me to a problem though - since Window2 needs a member variable of ClassX (because that member variable will be filled in by Window1 after instantiating Window2 but before calling DoModal()) doesn't the #include ClassX.h need to go before the class definition for Window2?
|
|
|
|
|
|
How would you resolve the issue I was having without using preprocessor directives?
I seemed to have been caught in a Catch-22.
WHen I followed your example, it didn't give an error relating to duplicate class definitions, but I got errors for an undefined keyword (ClassX) because the ClassX header wasn't included until after I tried to define an object of ClassX.
|
|
|
|
|
|
I know this. But your first suggestion told me to include the header file in the .cppp file for Window 2 to avoid the "duplicate class name" error. I couldn't do this, because there was a member variable of tyoe ClassX in Window2.
When presented with the preprocessor directives, I implemented them and it fixed the problem but you said this was not a preferred technique because of portability concerns.
How would you do this without preprocessor directives?
ClassX
Window1 : has a member var of ClassX so needs #include ClassX.h
Window2 : has a member var of ClassX so needs #include ClassX.h
if I include them both where you have agreed they need to be ie before the ClassX object is defined I get a compiler error of a duplicate class name.
If I include them where you first told me (in the CPP file before the window header) I get an undefined name error.
Using preprocessor directives allowed me to successfully do what I needed but you said it was a poor solution.
I would like to know the correct solution.
|
|
|
|
|
You need include guards in your header files:
#ifndef CLASSX_H_INCLUDED
#define CLASSX_H_INCLUDED
#endif // ndef CLASSX_H_INCLUDED There is also #pragma once but I prefer the above way since you can test for whether ClassX.h has been included with #ifdef CLASSX_H_INCLUDED
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
Thanks Mike - that did the trick.
I had used those a while back without remembering why I used them 
And I never noticed when I stopped using them.
I guess it took a big screeching halt to make me remember to always use them.
|
|
|
|
|
I take things a bit farther. Here is what I do :
#ifndef _HEADER_H
#define _HEADER_H
#else
#error repeated include of this file
#endif
then if this header must be included in another header file (nested) I do this -
#ifndef _HEADER_H
#include header.h
#endif
I went through and converted a rather large project to this scheme and my compile times decreased considerably. If you use a standard macro naming mechanism (_HEADER_H for me) then this is quite easy to use.
The Ten Commandments For C Programmers
|
|
|
|
|
Rick York wrote:
#ifndef _HEADER_H
#include header.h
#endif
I used this technique for a while and then I realized that the increased code clutter (three lines/include vs just one) wasn't worth the extra milliseconds saved per compiled unit. Instead, I made sure to use a precompiled header which really sped things up.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I know what you mean but I only do this when nesting include files - including one header in another. This keeps the headers safe. I don't do this in standard code as I'll see the error soon enough.
Yes, in most projects, the savings amount to milliseconds but in large scale projects this can add up significantly. I have been forced to use a library that is absolutely atrocious in this respect.
The Ten Commandments For C Programmers
|
|
|
|
|
Terry O`Nolley wrote:
Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?
You can use either an ifdef to include the cpp file only once
#if !defined(_MYCPPFILENAME_)
#define _MYCPPFILENAME_
#endif //def _MYCPPFILENAME_
Or you can use this as the first statement in your header file
#pragma once
There is a macro in vc6 that does this for you. Click Tools then customize then addins and macro files and then make sure SAMPLE is checked. Then open your header file and click tools then macros select sample and then select OneTimeInclude and click run.
John
|
|
|
|
|
I have done what you suggested and it is perfect.
This will save me a lot of time. Many thanks!
|
|
|
|
|
I use the macro for this all the time because I prefer the #ifdef solution and it saves me a a few steps...
John
|
|
|
|
|
In a function, I create a font chooer dialog for my user, for which I'm trying to add a callback function, like so:
//create the pointer
LPCFHOOKPROC FontHook;
//create the font chooser dialog
CFontDialog dlg(&LogFont,CF_ENABLEHOOK|CF_EFFECTS|CF_BOTH|CF_NOVECTORFONTS|CF_NOSCRIPTSEL|CF_INITTOLOGFONTSTRUCT,NULL,NULL);
//tell it to hook to the function
dlg.m_cf.lpfnHook = FontHook;
//display the font dialog
if(dlg.DoModal() == IDOK)
{
//blah blah
}
Then, elsewhere in the view I added the actual callback function, like so:
UINT CALLBACK FontHook(HWND hdlg,UINT uiMsg,WPARAM wParam,LPARAM lParam)
{
//blah blah
return TRUE;
}
It compiles fine, but when I try to use the font dialog is gives me an application error:
"The instruction at '0xcccccccc' referenced memory at '0xcccccccc'. The memory could not be 'read'."
It desplays this three times, before quitting out. I figured out it's on the .DoModal line where it's having the issue, I think. It gives me this error when debugging:
"Unhandled exception in Application.exe: 0xC0000005: Access violation."
Can anyone please tell me what I'm doing wrong or forgetting to do?
halblonious
|
|
|
|
|
The problem is to do with your FontHook pointer. To get this working you need to remove the following from your code:
<br />
LPCFHOOKPROC FontHook;<br />
Then ensure that you have a prototype for the callback fn somewhere before where you create your dialog. Prototype will look something like:
<br />
UINT CALLBACK FontHook( HWND, UINT, WPARAM, LPARAM );<br />
What you are doing wrong is creating an uninitialised local pointer in your dialog creation fn and you specify this pointer as the address of the callback fn. In debug mode, items such as un-initialised pointers always get set to 0xCCCCCCCC so that it's easy to recognise them as such.
Phil
|
|
|
|
|
Thank you very much, that seemed to work. Now, I'm off to figure out how to make do what I want...
halblonious
|
|
|
|
|
Try this instead of ur function write
UINT_PTR CALLBACK CFHookProc(
HWND hdlg, // handle to dialog box
UINT uiMsg, // message identifier
WPARAM wParam, // message parameter
LPARAM lParam // message parameter
);
and then try out if not write back
Thanx
TAKE CARE
|
|
|
|
|
I've got it working now. Thank you for your comment.
halblonious
|
|
|
|
|
In addition to what Phil has already pointed out, by using CF_BOTH, I believe that the hDC member of your LOGFONT structure must also be initialized. Are the other members properly initialized?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
They must be, because it seems to work now that I changed that line. Thank you.
halblonious
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
