|
From where is this pointer coming from ?? In general, when playing with pointers, the thing you have to pay attention to is to initialize them to NULL. Then, you can simply check if the pointer is NULL or not using if (pPointer)
I don't see why you need to check for bad pointers...
|
|
|
|
|
Thanks for your reply. here is why i think i need to check for bad ptr:
theres this function in a class that would return a pointer. something like this
CMyWnd *GetMyWnd(){ return m_myWnd};
now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this
GetMyWnd()->SetSomeFunc(); // the application crashes here, in VS2005 where as in 2003 it works fine.
this happens because the pointer that GetMyWnd returns is not a valid pointer and once it tries to acces any member of CMyWnd the application crashes.
i've changed the above statement to something like this:
CMyWnd *pWnd = GetMyWnd(); // i also tried CMyWnd *pWnd = NULL; pWnd = GetMyWnd();
if(pWnd)
{
pWnd->SetSomeFunc();
}
to see what GetMyWnd returns. It returns a Junk value, and the if condition is evaluated to true and it enters inside and crashes. this is the reason that i thought i should check for NULL as well as Bad Ptr.
how do i solve this?? is there anyother way??
|
|
|
|
|
sw@thi wrote: now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this
You know what your real problem is - you say so. Fix the real problem instead of trying to use a function to cover up the error. cdcdcdcd is a value that indicates an uninitialized variable. It appears that your GetMyWnd function is not maintaining the value of m_myWnd. Figure out why
Judy
|
|
|
|
|
IsBadReadPtr / IsBadWritePtr are as good as it gets on Win32 I'm afraid. You shouldn't run into too much trouble as long as your app is doing 'ordinary' things with memory i.e. no mucking around with non-paged pool or using exception filters to allocate virtual memory. I wouldn't try using them against anything you expect to be allocated on the stack either as compiler optimisations might change behaviour between Debug and Release builds.
That leaves you with IsBadReadPtr / IsBadWritePtr are fine for Heap memory you allocate yourself i.e. new and delete.
I use a special class to check pointer parameters like this when they are passed. The template class has assignment from and cast to operators for the original pointer type. The cast calls the relevant check function whenever it is used. The checking classes are removed in the Release build for performance by the use of a macro. so
void SomeFunc( CNullPointerCheck<char*> pszData )
which checks pszData for NULL on every call in Debug, becomes
void SomeFunc( char* pszData )
with zero overhead in Release builds. It gets written as
void SomeFunc( _PC_NP(char*) pszData )
which makes it clear this is a Parameter Check for Null Pointer
Other classes check for Readable and Writable memory of a certain size at the target of the pointer using the IsBadReadPtr/IsBadWritePtr functions so
void SomeFunc( _PC_WP(char*, 40) pszData )
for example checks for at least 40 characters of writable memory.
I'll post the whole lot as an article some day when I'm happy with the error reporting system.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
You should avoid IsBadReadPtr and IsBadWrite pointer like the plague. See here[^] and here[^]. These functions may be "as it gets on Win32", but they fall well short of good enough.
Steve
|
|
|
|
|
Very interesting. It would seems that you should only use IsBad*Ptr if you can gaurentee 2 things.
1 You're not intentionally passing in exotic memory types like guard page addresses.
2 If anything goes wrong the app will stop because the result of the call will always be acted on.
If you're writing the Win32 API you can't make these gaurentees so you shouldn't use the functions. In my case I use them in a framework where I can gaurentee both things so I feel reasonably justified in making this limited use.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I’ve actually fallen victim to a stack guard-page corruption caused by the numerous calls to IsBadReadPtr and IsBadWritePtr in MFC. It wasn’t at all obvious that the memory page in question was on the stack and not the heap (it took ages to even discover that the guard page on the stack was corrupted); after all every local variable is on the stack and many such variables are passed “through” MFC. It took many weeks to debug the issue. Anyway, what’s the point of a function succeeding if it’s called with some random pointer and thus can’t access the data it needs to do its job? Don’t validate memory, crash! Then the source of the problem is staring you in the face instead of some problem far removed from the actual source.
Steve
|
|
|
|
|
I'll look forward to that article. We are not doing anything special with that ptr. just check for that pointer and then if its valid then call one more member from that ptr.
i gave a full explanation in reply to cedric moonen's message above yours. Thanks for your reply.
|
|
|
|
|
sw@thi wrote: i need to check whether a pointer is valid or not...
Why?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
New day, same old story 
|
|
|
|
|
sw@thi wrote: they also say that its not good practice to use these functions.
any particular reason!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
You should avoid IsBadReadPtr and IsBadWrite pointer like the plague. See here[^] and here[^]. If you get a bad pointer the best thing that you can do is ***NOT*** attempt to validate it and let the application crash so it can be debugged.
Steve
|
|
|
|
|
hello friends,
i trying to access properties of activeX control throught atl dialog, but unable to access, also unable to create a control variable of activeX control, which can be create in mfc.
thnx...
Rajesh
|
|
|
|
|
Have a look at the ActiveX Control Test Container tool which Microsoft ship with VC6. If you hunt around on the Web the source for it is available. It's ATL and does just about everything with ActiveX controls that you can imagine and some stuff that I still can't even after I read it.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I need to send some raw data from a packet sniffed by Ethereal. Someone knows how?
|
|
|
|
|
alofang wrote: I need to send some raw data from a packet sniffed by Ethereal. Someone knows how?
just convert that to char and send it TCP via socket!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
|
Does exist a simple way to change the background color of edit and button ctrls when has the focus? thanks VC6++
|
|
|
|
|
Take a look in SetBkColor ()
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nelek wrote: Take a look in SetBkColor ()
it will not work.. you have to subclass
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Not true. Consider this code (dots are code that's been omitted):
=================================================================
In ".h" file.
-------------
class CFocusColourDlg : public CDialog
{
.
.
.
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CFocusColourDlg)
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
virtual BOOL OnCommand(WPARAM wParam, LPARAM lParam);
//}}AFX_VIRTUAL
// Implementation
protected:
HICON m_hIcon;
CBrush m_RedBrush;
// Generated message map functions
//{{AFX_MSG(CFocusColourDlg)
virtual BOOL OnInitDialog();
afx_msg void OnPaint();
afx_msg HCURSOR OnQueryDragIcon();
afx_msg HBRUSH OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor);
afx_msg void OnDestroy();
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
In ".cpp" file.
---------------
.
.
.
BEGIN_MESSAGE_MAP(CFocusColourDlg, CDialog)
//{{AFX_MSG_MAP(CFocusColourDlg)
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_WM_CTLCOLOR()
ON_WM_DESTROY()
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CFocusColourDlg message handlers
BOOL CFocusColourDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
m_RedBrush.CreateSolidBrush(RGB(255, 0, 0));
return TRUE; // return TRUE unless you set the focus to a control
}
.
.
.
BOOL CFocusColourDlg::OnCommand(WPARAM wParam, LPARAM lParam)
{
WORD NotifyCode = HIWORD(wParam);
WORD Id = LOWORD(wParam);
HWND hWnd = reinterpret_cast<HWND>(lParam);
if (NotifyCode==EN_SETFOCUS || NotifyCode==EN_KILLFOCUS)
{
::InvalidateRect(hWnd, NULL, TRUE);
}
return CDialog::OnCommand(wParam, lParam);
}
HBRUSH CFocusColourDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if (pWnd->GetSafeHwnd() == ::GetFocus())
{
pDC->SetBkColor(RGB(255, 0, 0));
return m_RedBrush;
}
return hbr;
}
void CFocusColourDlg::OnDestroy()
{
CDialog::OnDestroy();
m_RedBrush.DeleteObject();
}
Steve
|
|
|
|
|
but according to OPPs principal.. i am just abstracting that thing from outer world i.e. Dialog!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
This approach doesn't necessarily break OOP principles; there's nothing wrong with an edit control asking its parent what colour it should use.
Steve
|
|
|
|
|
ArielR wrote: Does exist a simple way to change the background color of edit and button ctrls when has the focus? thanks VC6++
you need to SUBCLASS that control to achieve same.. search SUBCLASS by mr Chris!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Thank for your reply. The SUBCLASS change the background color by the mouse movement. I need to change the color when it was focused by mouse or tab order. Could you help me? Thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
