|
It's an ordinary button (not owner drawn), put on a dialog with a white background. No ownerdraw magic here. 
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
You need to make the buttons with BS_OWNERDRAW style.
Then you need to draw the buttons yourself in the handler for WM_DRAWITEM in the (your) class inheriting from CButton or CBitmapButton.
That is what it takes to change background color of dialog.
this is this.
|
|
|
|
|
Argh. Annoying. 
But I will try it out. Thanks!
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Ah, taking care of WM_DRAWITEM doesn't really do it. What you need to do is subclassing the button and take care of WM_ERASEBKGND. It is the background drawing that is the culprit. It draws using the button class's brush, whose color is COLOR_BTNFACE, which is "dialog grey". The theme drawing code just doesn't draw on that area, hence one needs to draw the background oneself instead of letting the button's default WM_ERASBKGND handler do it.
To ensure correct background color, I communicate with the parent and asks for the background using the WM_CTLCOLORBTN message. If I don't get a brush back, I let the button's default handler paint the background.
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Hi Guys,
I have a thread running recv continuously listening for messages from a client. The same program sets up a second connection, this time acting as a client to another machine. However, when the setup runs it seems to prevent a message reaching recv in the main thread. I've pinned it down to this portion of code:
hostent* hp;
if (inet_addr(&m_sServerIP[0]) == INADDR_NONE)
{
hp = gethostbyname(&m_sServerIP[0]);
} else {
unsigned long addr = inet_addr(&m_sServerIP[0]);
hp = gethostbyaddr((char*)&addr,sizeof(addr),AF_INET);
}
When this code is commented out I get the message I'm expecting on the main thread. Also, if the server at the other end responds immediately then there's no problem. Is there anything I can do to prevent this interference.
Sorry, I'm a bit of a newbie to network stuff and multithreading.
Many thanks,
Simon
|
|
|
|
|
Hello,
I have a little problem with virtual functions in derived classes. The problem is that I want to call a virtual function in my base class CBase. This function is abstract in this class. In the derived class CDerived this function is implemented. When the code in the base class gets executed, the _purecall handler is invoked. This means that I call a non-existing (abstract) function which is not implemented.
Here is the sample code:
<br />
class CBase<br />
{<br />
public:<br />
virtual void Foo() = 0;
<br />
void DoFoo() { static_cast<CBase*>(this)->Foo(); }<br />
};<br />
<br />
class CDerived : public CBase<br />
{<br />
public:<br />
virtual void Foo() { }<br />
};<br />
As you can see, I want to supply an interface in which certain functionality is provided. Some core functionality depends on ssituation specific user code, which should be supplied in the derived class.
Does anybody know how to solve this problem?
I also got the blogging virus..[^]
|
|
|
|
|
I don't understand what you really want to do...
Virtual functions are used like in the following case:
CBase* pClass = new CDerived;<br />
pClass->Foo();
In this case, the function that will be called is the derived function. The thing I don't understand is why do you want to call the redifined Foo function from within the base class ??? 
Why not simply call the Foo function directly ?
Maybe because you want this function to do something common for every class ? But then a much better solution would be to call from within your redifined Foo function a function from the base class.
|
|
|
|
|
cedric moonen wrote:
Virtual functions are used like in the following case:
CBase* pClass = new CDerived;
pClass->Foo();
No, the purpose of virtual functions is that the correct function is called when the exact type of a class is not known. For exemple:
<br />
class A<br />
{ <br />
public:<br />
virtual void Foo() {}<br />
};<br />
<br />
class B<br />
{<br />
public:<br />
virtual void Foo() {}<br />
};<br />
<br />
A* pA = new B;<br />
pA->Foo();
cedric moonen wrote:
In this case, the function that will be called is the derived function. The thing I don't understand is why do you want to call the redifined Foo function from within the base class ???
The base class (the interface) relies on functionality that cannot be implemented at that level, but the general functionality is always the same...
So the user must supply some functionality that is different for each use of the class.
cedric moonen wrote:
Why not simply call the Foo function directly ?
What do you mean by that, calling the function directly. If you mean that I should cast to the derived type, I cannot. This is because I don't know which one of the infinitly amount of possible derived classes would be calling the function.
cedric moonen wrote:
Maybe because you want this function to do something common for every class ? But then a much better solution would be to call from within your redifined Foo function a function from the base class.
In the most cases this would be the better solution, but in my particular case, it requires more than just 2 lines of code that will need to be rewritten every time a new class is derived from the base class.
I have a couple of dozen lines that are identical for every case, but the implementation of a function in the middle of those lines is user specific. I need to call that function from the base class, because I cannot rely on the end user to execute certain code before and after the call. Besides that, I don't want the user to write all those lines over and over again...
I also got the blogging virus..[^]
|
|
|
|
|
Bob Stanneveld wrote:
No, the purpose of virtual functions is that the correct function is called when the exact type of a class is not known. For exemple:
class A
{
public:
virtual void Foo() {}
};
class B
{
public:
virtual void Foo() {}
};
A* pA = new B;
pA->Foo(); // calls B::Foo
This won't work the compiler will complain because it cannot cast from B* to A*. What you need to add in your code is that B derives from A and that's exactly the same explanation I gave you. Virtual functions are used only with inheritance.
Bob Stanneveld wrote:
What do you mean by that, calling the function directly. If you mean that I should cast to the derived type, I cannot. This is because I don't know which one of the infinitly amount of possible derived classes would be calling the function.
As you explained above, when you have this code:
class A<br />
{ <br />
public:<br />
virtual void Foo() {}<br />
};<br />
<br />
class B : public A<br />
{<br />
public:<br />
virtual void Foo() {}<br />
};<br />
<br />
A* pA = new B;<br />
pA->Foo();
You don't need to know the type of child class at compile time. The correct derived function will automatically be called.
Bob Stanneveld wrote:
I have a couple of dozen lines that are identical for every case, but the implementation of a function in the middle of those lines is user specific
Ok, now I understand a little bit better the problem and what you want to achieve. But unfortunately, if you want to do that, you will need to know the type of the class in which you want to cast. Also, I think there is a missing part in your code with the static_cast operator (the text between the < > was removed). I think you'll need to post it again because it is the most important part of the code 
|
|
|
|
|
I guess he missed out B deriving from A by mistake. That apart, I don't see why the type of the class needs to be known. That's what virtual functions are for, aren't they?
And he had casted it to Base *. (I found out by looking at the HTML source).
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
S. Senthil Kumar wrote:
I guess he missed out B deriving from A by mistake
That was my guess also but then it is exactly the same that I explained 
S. Senthil Kumar wrote:
That apart, I don't see why the type of the class needs to be known. That's what virtual functions are for, aren't they?
Yes when you call the function from outside the class with a pointer. Here what he wants to do is call a function from the base class (that just exist in the base class) then call from within this function the derived function Foo. But from within the class, if you call it directly, you will call the function from the base class and not from the derived class (not using the virtual table). So to make it work you need to cast the this pointer into the child class thus it has to be known ! Maybe the missing part in the code was that I tried to cast into the base class but that won,t work neither...
|
|
|
|
|
No, it doesn't matter whether you're calling the virtual function from outside the class or inside. As long as you're using a pointer to the class, you should be fine. If you call it from within the base class, the call will get translated to this->Func(); which is the same as p->Func() where p is a pointer to Base.
class Base
{
public:
virtual void Stop() = 0;
void SomeFunc()
{
Stop();
}
};
class Derived : public Base
{
public:
void Stop()
{
cout << "Derived" ;
}
};
int main()
{
Base * b = new Derived();
b->SomeFunc();
}
This piece of code prints Derived as expected.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Just watch out during construction and destruction when the vtable is changing all the time.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
My guess is you haven't overridden the virtual function correctly. Maybe it has fewer or more parameters than the original function, maybe it's misspelled. Also, I don't really see why you should be using a static_cast to call a virtual function.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
S. Senthil Kumar wrote:
My guess is you haven't overridden the virtual function correctly
If that would be the case, than the compiler would complain about instantiating abstract classes, since not all abstract functions have been implemented...
S. Senthil Kumar wrote:
Also, I don't really see why you should be using a static_cast to call a virtual function.
This would be, because the compiler complains about unresolved external symbols if I omit that. I thought that this should invoke a virtual function call using a pointer from the v-table, but something is terribly wrong and I don't know what.
I also got the blogging virus..[^]
|
|
|
|
|
Yeah, you're right. Can you post the full code? Maybe that'll help.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
The simplified code of the base class
<br />
template <class T><br />
class IMultiThreaded : protected A, public B<T>, public C, public D<br />
{<br />
public:<br />
virtual ~CBase();<br />
<br />
vitual DWORD Stop(DWORD* pdwCode, DWORD dwWaitTimeOut = DEFAULT_TIMEOUT) = 0;<br />
};<br />
<br />
template <class T><br />
CBase<T>::~CBase()<br />
{<br />
if( m_bSomeConstant ) Stop(NULL); <br />
}<br />
The code of the derived class:
<br />
<class><br />
template <class T><br />
class CDerived : public CBase<T><br />
{<br />
public:<br />
virtual ~CDerived() { }<br />
virtual DWORD Stop(DWORD* pdwCode, DWORD dwWaitTimeOut = DEFAULT_TIMEOUT);<br />
}<br />
<br />
template <class T><br />
DWORD CDerived<T>::Stop(DWORD *pdwCode, DWORD dwWaitTimeOut)<br />
{<br />
}<br />
I also got the blogging virus..[^]
|
|
|
|
|
It looks like you are calling the virtual function from the destructor. That's a big no-no.
The order of destructor execution in C++ is such that by the time you're in the destructor of your base class, the derived part of your instance is already gone. The compiler is intelligent enough to figure that out and decides to call the base class function itself. In your case, it is pure virtual and so you are getting the unresolved external symbol error.
If you static cast it to Base explicitly, I guess the compiler assumes you know what you are doing and calls the virtual function anyway. But at runtime, it'll blow up badly.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
|
Just make the destructor virtual. That should solve your problem.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
As you can see in my code example, the destructor is alreay virtual. As you explained in your previous post, the function of the derived class won't be called, since the derived part is destroyed already...
[EDIT]
I already solved the problem, by putting the cleanup in a special cleanup routine, that the user has to call from the derived class's destructor. I would have loved a more nice solution, but I guess that's not going to happen..
[/EDIT]
I also got the blogging virus..[^]
|
|
|
|
|
struct
__declspec(uuid("F5748778-4F2F-4dd7-AB08-2616D76A1DA4"))// //why?
mystruct
{
...
};
|
|
|
|
|
HeartFriend wrote:
struct
__declspec(uuid("F5748778-4F2F-4dd7-AB08-2616D76A1DA4"))// //why?
mystruct
{
...
};
Are you reading any Com header file!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
u can say that, it's a snippet i get from our project written by other developer
|
|
|
|
|
For Uniquly Defined the Com Interface!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
!