Beatachon
asked on
this vs. (Cwnd*)m_hWnd #2
Sorry, guys. The comment list was getting a little too long for my taste on that question, so let's start fresh. Here's what's going on:
Yes, I have tried changing that value. (to -1) Is that a valid thing to test out your idea, Shogi? In addition to that, thanks for the help guys, and here's that source:
#include "cdedit.h"
CDEdit :: CDEdit(int Mode)
{
_validationMode = Mode;
}
void CDEdit :: OnKillFocus( CWnd* pNewWnd )
{
char BoxText[255], NewText[255];
double DummyD;
CEdit::OnKillFocus(pNewWnd );
GetWindowText(BoxText, 254);
if(strlen(BoxText) == 0)
return;
if(_validator.ConvertStrin g(_validat ionMode, BoxText, NewText, &DummyD))
{
AfxMessageBox("Error with value!");
SetWindowText(BoxText);
return;
}
SetWindowText(NewText);
//Default();
}
BEGIN_MESSAGE_MAP(CDEdit, CEdit)
ON_WM_KILLFOCUS()
END_MESSAGE_MAP()
-------------------------- ---------- ----
And the header:
#ifndef CDEDIT_H
#define CDEDIT_H
#include "stdafx.h"
#include "CDataVal.h"
class CDEdit : public CEdit
{
public:
CDEdit(int Mode);
private:
CDataValidation _validator;
int _validationMode;
void OnKillFocus( CWnd* pNewWnd );
DECLARE_MESSAGE_MAP()
};
/*
// Defines for use with this class
// These specify the validation mode.
#define CD_AMOUNT_MODE 1//For cash amounts
#define CD_NUMBER_MODE 2//Just convert to value from string
#define CD_DISPLAY_DATE_MODE 3//In the form: mm/dd/yy
#define CD_PARAM_DATE_MODE 4//In the form: yyyymmdd from mm/dd/yy
#define CD_ERROR_DATE 5//General (no delimiters)
#define CD_ERROR_DAY 6
#define CD_ERROR_MONTH 7
#define CD_ERROR_YEAR 8
#define CD_ERROR_BAD_AMOUNT 9
*/
#endif
-------------------------- ------
So what do you think?
Thanks again.
Yes, I have tried changing that value. (to -1) Is that a valid thing to test out your idea, Shogi? In addition to that, thanks for the help guys, and here's that source:
#include "cdedit.h"
CDEdit :: CDEdit(int Mode)
{
_validationMode = Mode;
}
void CDEdit :: OnKillFocus( CWnd* pNewWnd )
{
char BoxText[255], NewText[255];
double DummyD;
CEdit::OnKillFocus(pNewWnd
GetWindowText(BoxText, 254);
if(strlen(BoxText) == 0)
return;
if(_validator.ConvertStrin
{
AfxMessageBox("Error with value!");
SetWindowText(BoxText);
return;
}
SetWindowText(NewText);
//Default();
}
BEGIN_MESSAGE_MAP(CDEdit, CEdit)
ON_WM_KILLFOCUS()
END_MESSAGE_MAP()
--------------------------
And the header:
#ifndef CDEDIT_H
#define CDEDIT_H
#include "stdafx.h"
#include "CDataVal.h"
class CDEdit : public CEdit
{
public:
CDEdit(int Mode);
private:
CDataValidation _validator;
int _validationMode;
void OnKillFocus( CWnd* pNewWnd );
DECLARE_MESSAGE_MAP()
};
/*
// Defines for use with this class
// These specify the validation mode.
#define CD_AMOUNT_MODE 1//For cash amounts
#define CD_NUMBER_MODE 2//Just convert to value from string
#define CD_DISPLAY_DATE_MODE 3//In the form: mm/dd/yy
#define CD_PARAM_DATE_MODE 4//In the form: yyyymmdd from mm/dd/yy
#define CD_ERROR_DATE 5//General (no delimiters)
#define CD_ERROR_DAY 6
#define CD_ERROR_MONTH 7
#define CD_ERROR_YEAR 8
#define CD_ERROR_BAD_AMOUNT 9
*/
#endif
--------------------------
So what do you think?
Thanks again.
(I would have suggested reducing the point value to 0 on the old question, marked it as answered and then opened up this new one. Some people benefit from the *discussion*, not just the answer! :P)
Anyway... Back on topic.. I am running out of ideas on this one. I cannot see, from the ST and source, what might be wrong.
When the assertion fails, what is it failing on? Is the Dialog (Create(...)) unable to resolve the passed CWnd into a valid window? Try passing in a NULL CWnd (Dialogs do not HAVE to have a parent window).
Also try this: Override the constructor to accept a HWND instead of a CWnd*, and use CWnd::FromHandlePermanant( ) (or CWnd::FromHandle()) in the overridden Create(...) to get a CWnd*, and pass that to the Create() function. Note that you might have the same problem as before: CWnd::FromHandlePerm() might return NULL, which is basically what is happening now.
-=- James.
Anyway... Back on topic.. I am running out of ideas on this one. I cannot see, from the ST and source, what might be wrong.
When the assertion fails, what is it failing on? Is the Dialog (Create(...)) unable to resolve the passed CWnd into a valid window? Try passing in a NULL CWnd (Dialogs do not HAVE to have a parent window).
Also try this: Override the constructor to accept a HWND instead of a CWnd*, and use CWnd::FromHandlePermanant(
-=- James.
ASKER
I'm not passing in a parent window to the dialog as it is. So by default Null is going in. I'll try your FromHandlePermanent suggestion to pass the pointer to the create function. I'm also going to try creating just a plain old CEdit object to see what happens. Let's narrow it down. I'll keep you posted.
(I know, REALLY bad pun.)
(I know, REALLY bad pun.)
ASKER
Well, no luck. I think it's pooping out at ASSERT_VALID(this); inside BOOL CMapWordToPtr::Lookup(WORD key, void*& rValue) const. But who's calling this? Is the Create function for the control calling it or is the dialog?
FromHandlePermanent(m_hWnd ); gave me back the same thing the this pointer has.
FromHandlePermanent(m_hWnd
ASKER
It's actually the AfxWndProc. The line is:
pWnd = CWnd::FromHandlePermanent( hWnd);
Just like you said, it is the FromHandlePermanent.
But whose? The control or the dialog. I've now seen the FromHandlePermanent work for the dialog.
pWnd = CWnd::FromHandlePermanent(
Just like you said, it is the FromHandlePermanent.
But whose? The control or the dialog. I've now seen the FromHandlePermanent work for the dialog.
Let me see the stack trace again, please...
-=- James.
-=- James.
ASKER
Of course, the this pointer at that point Does look like this:
-this = 0x23D7:0x8030
+CObject = {...}
+classCMapWordToPtr = {...}
+m_pHashTable = 0x0000:0x0000 protected
m_nHashTableSize = 0 protected
m_nCount = 0 protected
+m_pFreeList = 0x0000:0x0000 protected
+m_pBlocks = 0x0000:0x0000 protected
m_nBlockSize = 0 protected
All nulled. Hmm.
-this = 0x23D7:0x8030
+CObject = {...}
+classCMapWordToPtr = {...}
+m_pHashTable = 0x0000:0x0000 protected
m_nHashTableSize = 0 protected
m_nCount = 0 protected
+m_pFreeList = 0x0000:0x0000 protected
+m_pBlocks = 0x0000:0x0000 protected
m_nBlockSize = 0 protected
All nulled. Hmm.
ASKER
Here you go:
CMapWordToPtr::GetAssocAt( )
CMapWordToPtr::Lookup()
CHandleMap::LookupPermanen t()
CWnd::FromHandlePermanent( )
AfxWndProc()
KRNL386!(1)
USER!(1)
CWnd::Create()
CEdit::Create()
CSelSort::OnInitDialog()
-------------------------- ---------- ----------
This does all work when I build it in my win32 version, by the way. Is it something specific to 16-bit that I'm not doing properly?
CMapWordToPtr::GetAssocAt(
CMapWordToPtr::Lookup()
CHandleMap::LookupPermanen
CWnd::FromHandlePermanent(
AfxWndProc()
KRNL386!(1)
USER!(1)
CWnd::Create()
CEdit::Create()
CSelSort::OnInitDialog()
--------------------------
This does all work when I build it in my win32 version, by the way. Is it something specific to 16-bit that I'm not doing properly?
The Assertion is in CDEdit::Create(...). From here, it looks like it cannot find the HWND (window) associated with the CWnd* that is passed into Create(...).
Does the Control (CDEdit) exist within the DLL or does the Dialog and Control exist in the DLL? Maybe that has something to do with it.
Remember my last suggestion, about overriding Create(...)? Try it again, but this time, create a CWnd and wrap the HWND with it (use CWnd::Attach(...)). Make the CWnd a member of the CDEdit class.
-=- James.
Does the Control (CDEdit) exist within the DLL or does the Dialog and Control exist in the DLL? Maybe that has something to do with it.
Remember my last suggestion, about overriding Create(...)? Try it again, but this time, create a CWnd and wrap the HWND with it (use CWnd::Attach(...)). Make the CWnd a member of the CDEdit class.
-=- James.
ASKER
Does this look right to you?
in the header file under private I have:
CWnd _dummyCWnd;
and then implemented this:
BOOL CDEdit::Create(DWORD dwStyle, const RECT& rect, HWND HParent/*CWnd* pParentWnd*/, UINT nID)
{
_dummyCWnd.Attach(HParent) ;
return CWnd::Create("EDIT", NULL, dwStyle, rect, &_dummyCWnd, nID);
}
The reason I ask is that the Attach function asserts also. Any ideas?
in the header file under private I have:
CWnd _dummyCWnd;
and then implemented this:
BOOL CDEdit::Create(DWORD dwStyle, const RECT& rect, HWND HParent/*CWnd* pParentWnd*/, UINT nID)
{
_dummyCWnd.Attach(HParent)
return CWnd::Create("EDIT", NULL, dwStyle, rect, &_dummyCWnd, nID);
}
The reason I ask is that the Attach function asserts also. Any ideas?
ASKER
Asserts on this line:
ASSERT(FromHandlePermanent (hWndNew) == NULL);
// must not already be in permanent map
ASSERT(FromHandlePermanent
// must not already be in permanent map
What about the DLL/Application question that I asked?
FWIW, this is exactly what happens when you try to share CWnd (derived/using) objects between threads in Win32: Because each thread has its on handle-map, it cannot find mappings that were made in another thread.
Attach() should not ASSERT unless (I believe) the HWND that was given to it is invalid.
Try this... What does IsWindow() (is that available under Win16?) return when you give it:
o (In the dialog class, right before CDEdit::Create()) m_hWnd
o (In CDEdit::Create()) HParent
It should return a Non-Zero value indicating that the HWND that was given to it actually reperesents a valid (Existing) window.
-=- James.
FWIW, this is exactly what happens when you try to share CWnd (derived/using) objects between threads in Win32: Because each thread has its on handle-map, it cannot find mappings that were made in another thread.
Attach() should not ASSERT unless (I believe) the HWND that was given to it is invalid.
Try this... What does IsWindow() (is that available under Win16?) return when you give it:
o (In the dialog class, right before CDEdit::Create()) m_hWnd
o (In CDEdit::Create()) HParent
It should return a Non-Zero value indicating that the HWND that was given to it actually reperesents a valid (Existing) window.
-=- James.
ASKER
IsWindow returns good values.
I'm giving up. I'm just going to try to lay the controls out in the dialog template and then subclass them. Think it'll work?
Am I right in thinking that there is no UnSubclassWindow() in 16-bit? All I have to do is call SubClassWindow()?
(Answer this question. I wanna give you the points for helping me out.)
Thanks.
I'm giving up. I'm just going to try to lay the controls out in the dialog template and then subclass them. Think it'll work?
Am I right in thinking that there is no UnSubclassWindow() in 16-bit? All I have to do is call SubClassWindow()?
(Answer this question. I wanna give you the points for helping me out.)
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yeah, you're right, but you spent the most time. Thanks to you to, Shogi.
See you guys later.
(I mean that. I'll probably be back)
There was a reason we left 16-bit behind.
See you guys later.
(I mean that. I'll probably be back)
There was a reason we left 16-bit behind.
ASKER