|
Post the line(s) that's been flagged (line 32 in the header).
I Dream of Absolute Zero
|
|
|
|
|
This is the line.
HRESULT LogNTEvent(const LONG lSeverity, const CString & sAppName, const CString & sVersion, const CString & sFile, const LONG lLine, const LONG lErrorCode, const CString & sMsg1, const LONG lPassingCode, const CString & sMsg2);
the implementation for it is given below:
HRESULT LogNTEvent(const LONG lSeverity, const CString &sAppName, const CString &sVersion, const CString &sFile, const LONG lLine, const LONG lErrorCode, const CString &sMsg1, const LONG lPassingCode, const CString &sMsg2)
{
HRESULT hResult = S_OK;
IEVEventLog* pIEventLog = NULL;
long lMySeverity = 1;
if ( 0 <= lSeverity && 4 >= lSeverity )
lMySeverity = lSeverity;
// Write to debug trace log
CString sTraceMsg0;
sTraceMsg0.Format( L"Filename %s: Line=%x, ErrorCode=%x, Message=%s, Method=%s, Passing=%d\n", sFile, lLine, lErrorCode, sMsg1, sMsg2 ,lPassingCode );
TRACE( sTraceMsg0 );
hResult = CoCreateInstance( __uuidof( EVEventLog ), NULL, CLSCTX_ALL, __uuidof( IEVEventLog ), (void**)&pIEventLog );
if ( FAILED( hResult ) )
return ((DWORD)0xC000110DL);
BSTR bsAppName = SysAllocString( L"Vigilance" );
BSTR bsFileName = sFile.AllocSysString();
BSTR bsFuncName = sMsg1.AllocSysString();
BSTR bsMethod = sMsg2.AllocSysString();
hResult = pIEventLog->LogEvent( bsAppName, ((WORD)0x0000000AL), lErrorCode, bsFileName, bsFuncName, lLine, bsMethod, lPassingCode, NULL, NULL);
pIEventLog->Release();
SysFreeString( bsAppName );
SysFreeString( bsFileName );
SysFreeString( bsFuncName );
SysFreeString( bsMethod );
if ( FAILED( hResult ) )
return ((DWORD)0xC000110DL);
return S_OK;
}
|
|
|
|
|
By chance is it complaining about the CString reference.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
me think you might be missing a , or something similar on line 32 or somewhere above that line; or in a another header file that was included just before that one.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
This is what is there in the header file
#ifndef _CNEVSERVICESMANAGER_H_
#define _CNEVSERVICESMANAGER_H_
// included header files
#include <atlbase.h>
#include <lm.h>
#include "../NEVEMXMLParsingUtilities/NEVEMResponseMessageParser.h"
#include "../NEVEMXMLParsingUtilities/CNEVEMSystemServiceStructure.h"
#include "../NEVEMXMLParsingUtilities/CNEVEMSystemServicesStructure.h"
#include "../NEVEMCommon/NEVEMCommon.h"
#include "NEVCOMUtils.h"
const int VIGILANCE_SERVICES = 0;
const int SYSTEM_SERVICES = 1;
const int GLOBAL_SERVICES = 2;
const int ORACLE_SERVICES = 3;
HRESULT LogNTEvent(const LONG lSeverity, const CString & sAppName, const CString & sVersion, const CString & sFile, const LONG lLine, const LONG lErrorCode, const CString & sMsg1, const LONG lPassingCode, const CString & sMsg2);
class CNEVServicesManager {
public:
CNEVServicesManager();
~CNEVServicesManager();
HRESULT CNEVServicesManagerInit(wstring & szVEMXMLResponseMessage);
// Service Controls
HRESULT stopService (const wstring & szServiceName, wstring & szVEMXMLResponseMessage);
HRESULT startService (const wstring & szServiceName, wstring & szVEMXMLResponseMessage);
HRESULT pauseService (const wstring & szServiceName, wstring & szVEMXMLResponseMessage);
HRESULT restartService(const wstring & szServiceName, wstring & szVEMXMLResponseMessage);
HRESULT getallServices(wstring & szVigilanceRelatedServicesXMLStructure, wstring & szVEMXMLResponseMessage);
HRESULT setServiceStartupInfo(const wstring & szSystemServiceXMLStructure, wstring & szVEMXMLResponseMessage);
HRESULT getServiceStartupInfo(const wstring & szServiceName,
wstring & szServiceDescription,
DWORD & dwServiceType,
DWORD & dwStartType,
bool & bInteractWithDesktop,
wstring & szStartupAccount, vector<vemresponsemessage>& vecResponseMessages);
HRESULT getServiceCurrentState(const wstring & szServiceName, DWORD & dwCurrentState, wstring & szVEMXMLResponseMessage);
private:
SC_HANDLE hSCManager;
SC_HANDLE hService;
map<wstring, int=""> mapVigilanceRelatedServicesNames;
// functions
HRESULT fillCNEVServiceInfoStruct(CNEVServiceInfoStruct& oCNEVServiceInfoStruct,
LPENUM_SERVICE_STATUS lpServices, vector<vemresponsemessage>& vecResponseMessages);
HRESULT getDependentServices (const wstring & szServiceName,
vector<wstring> & szDependentServices, vector<vemresponsemessage>& vecResponseMessages);
HRESULT getErrorMessage(const DWORD & dwErrCode, wstring & szErrorMessage);
wstring getServiceDisplayName(const wstring & szServiceName);
};
#endif
|
|
|
|
|
I have a dialog with a white background. When I create buttons on that dialog, themed buttons are drawn with a thin grey border. I tried correcting the problem by responding to WM_CTLCOLORBTN, but it didn't help. In fact, I never received a WM_CTLCOLORBTN message.
Any solutions to this problem is welcome. 
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
When dealing with most things custom drawn (custom drawn controls) I have found that XP Themes often fight me all of the way. I would suggest disabling themes for that application (maybe SetThemeAppProperties?).
Modifying the painting of most button controls often requires that it be done as an ownerdrawn button, returning brush information from WM_CTLCOLORBTN is often not enough. You might have to resort to getting the theme information and using GetThemeColor(...) to paint them ownerdraw style.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
I'm not drawing the button myself. It's a simple BS_PUSHBUTTON. It's just that the dialog has a white background. If you look closely on a button using the standard xp theme, you'll see that it is not rectangular - it's got rounded corners. It's this border between the buttons rectangle and it's "image" that turns grey, as if it's assuming it's on a grey dialog.
Very frustrating. 
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Is this an owner-drawn button? 'Cause the only to change the appearance of a button control is to do you own drawing. Also the docs say that this message (WM_CTLCOLORBTN), only gets handled by an owner-drawn button.
I Dream of Absolute Zero
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
