C / C++ / MFC

27-Jul-05 18:58

i wanted to know that while allocating memory to ptr for modeless dialog is it necessary to initialize the ptr to first NULL in the constructor of the class of the dialog or do i need to initilaize to NULL where i write code to dispaly the modeless dialog?(in my case in menu handler of another dialog)

thanks

Christian Graus27-Jul-05 19:14

27-Jul-05 19:14

Setting first to NULL is a matter of good style, nothing will ever detect that you did, or complain that you didn't ( which is sort of the point ). When you create it, it's too late, before you create it, you want it to be NULL so you can tell it has not been created. So, all pointers should be set to NULL in the constructer for members, and at the time they are declared for variables in functions. There would be no point in setting it to NULL jsut before it got given a valid value.

Christian Graus - Microsoft MVP - C++

sayup27-Jul-05 20:53

27-Jul-05 20:53

thanks,can you suggest on something else.Actually i ahve a problem.I have created a dialog based application.I have inserted menu options voz dialog1,dialog2,dialog3,....dialog6 in the dialog .On clicking of these menu opions i am popping 6 different modeless dialog.here is sample code written for say menu item dialog1
midialog *d1;//midialog is class for dialog resource
d1=new midialog;
d1->Create(IDD_DIALOG1);
d1->ShowWindow(SW_SHOW);

d1 optionally is set to NULL in parent dialog constructor.

To close the dialog i either click on OK or Cancel or Red cross button and then i close the parent window.I have overriden OnCancel,OnOk functions and called DestroyWindow() in them. Also called PostNcDestroy function .Is this correct?

midialog::OnOk()
{
//Cdialog::OnOK();//commented out
UpdateData(TRUE);
Destroywindow(0;
}
midialog::Oncancel()
{
//CDialog::OnCancel();//commented out since it calls EndDialog and not DestroyWindow()
}
midialog::PostNcDestroy()
{
CDialog::PostNcDestroy();
delete this;
}

Is this ok?i also hope then there will be no problem when i close the modeless dialog and open it again
plz reply
i am in fix

Christian Graus28-Jul-05 15:10

28-Jul-05 15:10

The thing to do is this:

d1 needs to be a member variable, that is, it needs to be declared in the parent classes header file. Otherwise, how can you clean up after this memory ?

Assuming it's now called m_d1, you set it to NULL in your constructor.

Now when your user clicks the menu item for d1, it looks like this :

if (m_d1 == NULL)
{
d1=new midialog();
d1->Create(IDD_DIALOG1);
}

d1->ShowWindow(SW_SHOW);

And your OnOK and OnCancel should both NOT call DestroyWindow or delete this, they should just call ShowWindow(SW_HIDE);, which hides the window until the user elects to show it again.

Make sure you handle OnClose as well, or make sure there's no close button on the top right of the modeless dialog.

Christian Graus - Microsoft MVP - C++

sayup28-Jul-05 19:39

28-Jul-05 19:39

hello,
thanks but the idea which you gav eisnt working.In the menu handler i have not intilaized m_d1(as it is not necessary).I straight way have put
d1=new midialog();
d1->Create(IDD_DIALOG1);
d1->ShowWindow(SW_SHOW);
and i am not clear as to why your saying OnCancel shouldn't call DestroyWindow().I suppose its reqiured for modeless dialog.....
And what do you mean by handling OnClose well?
please expalin
thanks in advance

thanks

Christian Graus28-Jul-05 19:49

28-Jul-05 19:49

sayup wrote:
n the menu handler i have not intilaized m_d1(as it is not necessary).

If m_d1 is a member variable, then it IS necessary that it be initiallised to NULL. That was my answer to your first question. And if a modeless dialog is not a member variable, then you're going to leak memory.

sayup wrote:
and i am not clear as to why your saying OnCancel shouldn't call DestroyWindow().

Because then you need a callback to the first function, in order to set the pointer back to NULL. So much easier to just hide the window until you need it next.

sayup wrote:
And what do you mean by handling OnClose well?

If you click on the X on the top right of a dialog, it closes without calling OnOK or OnCancel, so you need to handle this case as well.

Christian Graus - Microsoft MVP - C++

sayup28-Jul-05 21:51

28-Jul-05 21:51

ok thanks,
can you please tell me what is m_d1? it is just defined as variable of my modeless dialog class?I am asking this because i declared it as avariable and initalized it to NULL in parent dialog's constructor and then wrote code as you had given but it was giving some error of == sign;like i have intilaized in constructor and i am checking its value in (m_d1==NULL)in menu handler.
Also one more doubt if i wrote ShowWindow(SW_HIDE) in OnCancel() instead of DestroyWindow(),next time when i click on the menu the dialog be displayed,this is what your suggesting right?
and after clicking red cross button if the modeless dialog completelty closes i dont have any problems with it.It should only open successfully next time i select the menu.
by the way can you just give me suggestion how to store the history in edit box.Like if user entes some values in edit box of dialog and then we close the box,the value should be seen next time i open the dialog....
thanks a lot
please reply

thanks

Christian Graus31-Jul-05 13:13

31-Jul-05 13:13

sayup wrote:
can you please tell me what is m_d1?

m_ is the convention for naming member variables. It's the member variable which is a pointer to your dialog class, set to NULL in your constructor.

sayup wrote:
and then wrote code as you had given but it was giving some error of == sign;like i have intilaized in constructor and i am checking its value in (m_d1==NULL)in menu handler.

What was the error ? If m_d1 is a pointer, then I don't see what the error could be.

sayup wrote:
Also one more doubt if i wrote ShowWindow(SW_HIDE) in OnCancel() instead of DestroyWindow(),next time when i click on the menu the dialog be displayed,this is what your suggesting right?

Yes, with the code I gave you.

sayup wrote:
and after clicking red cross button if the modeless dialog completelty closes i dont have any problems with it.It should only open successfully next time i select the menu.

You need to handle this event so it also only calls ShowWindow

sayup wrote:
by the way can you just give me suggestion how to store the history in edit box.Like if user entes some values in edit box of dialog and then we close the box,the value should be seen next time i open the dialog....

Where do you store app settings now ? If this is one of these modeless dialogs, it will stay there by itself when you impliment my suggestion.

Christian Graus - Microsoft MVP - C++

ddmcr27-Jul-05 21:46

ddmcr

27-Jul-05 21:46

This article will definitely help you
http://www.codeproject.com/dialog/gettingmodeless.asp[^]

"Success is the ability of going from one failure to another with no loss of enthusiasm" - W.Churchill

sayup28-Jul-05 19:40

how to debug exe service?

28-Jul-05 19:40

i have read that article but i am still very confused.I request you to read my recent message(sent just before this) and give me suggestion
thanks

thanks

HeartFriend27-Jul-05 17:03

HeartFriend

27-Jul-05 17:03

in my app, i call an exe service. but i can't set break point in the exe service. how to do it? thanks in advance

Re: how to debug exe service?

Christian Graus27-Jul-05 17:05

how to design multiple inheritance classes?

27-Jul-05 17:05

Do a debug build, start it, and attach your IDE to the process.

Christian Graus - Microsoft MVP - C++

nm_11427-Jul-05 16:39

27-Jul-05 16:39

I have a class named CWinFileIn and one named CWinFileOut, and I wanted to derived another one CWinFileInOut from the other two, but the compiler gives errors about functions and data members being ambiguous (both CWinFileIn and CWinFileOut have m_hFile etc.). So what's the right way of designing these classes?
- thanks

Christian Graus27-Jul-05 16:49

27-Jul-05 16:49

Don't give them both variables of the same name, I would have thought. The other possibility is containment, write a class that has instances of both classes, or derives from one and has an instance of the other.

Christian Graus - Microsoft MVP - C++

nm_11427-Jul-05 18:02

27-Jul-05 18:02

Christian Graus wrote:
Don't give them both variables of the same name

but I want CWinFileInOut to inherit CWinFileIn's read functions and CWinFileOut's write functions, using the same file handle and other private data. but i guess it's not possible.

Christian Graus27-Jul-05 18:08

27-Jul-05 18:08

nm_114 wrote:
but I want CWinFileInOut to inherit CWinFileIn's read functions and CWinFileOut's write functions, using the same file handle and other private data. but i guess it's not possible.

Then derive from a common base class that contains those variables, and/or derive from multiple classes that define interfaces.

Christian Graus - Microsoft MVP - C++

nm_11427-Jul-05 18:34

27-Jul-05 18:34

Christian Graus wrote:
Then derive from a common base class that contains those variables

I made a struct WFIOInfo that has the handle info etc. and CWinFileIn and CWinFileOut both derive from it, so if CWinFileInOut derive from both CWinFileIn and CWinFileOut which both have their own instances of the base class i still get the same ambiguous errors. Or did I not understand what you were suggesting?

Christian Graus wrote:
and/or derive from multiple classes that define interfaces

I don't know what that means. do you know of any examples i could look at?

Christian Graus27-Jul-05 19:06

27-Jul-05 19:06

struct WFIOInfo
{
...
}

class WinFileInInterface // Note - NOT derived from WFIOInfo, defines an interface for what CWinFIleIn has that WFIOInfo does not
{
virtual void myMethod; //etc
}

class WinFileOutInterface
{
virtual void myMethod; //etc
}

class CWinFileIn : WFIOInfo, WinFileInInterface
{
}

class CWinFileOut : WFIOInfo, WinFileOutInterface
{
}

class CWinFileInOut : WFINInfo, WinFileInInterface, WinFileOutInterface
{
}

So, CWinFileInOut is not derived from either derived class, but from all three base classes that combine to make the class you're after.

Christian Graus - Microsoft MVP - C++

nm_11427-Jul-05 19:56

27-Jul-05 19:56

ok, i think i *almost* have it, but its giving me the following errors:

Linking...
winiotest.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall WinFileOutInterface::DoWriteFile(void const *,unsigned long)" (?DoWriteFile@WinFileOutInterface@@UAEHPBXK@Z)
winiotest.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall WinFileInInterface::DoReadFile(void *,unsigned long)" (?DoReadFile@WinFileInInterface@@UAEHPAXK@Z)
winiotest.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall WinFileInInterface::Open(char const *)" (?Open@WinFileInInterface@@UAEHPBD@Z)
winiotest.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall WinFileOutInterface::Open(char const *)" (?Open@WinFileOutInterface@@UAEHPBD@Z)
Debug/winiotest.exe : fatal error LNK1120: 4 unresolved externals

here's my code so far:

struct WFIOInfo
{
	HANDLE m_hFile;
	DWORD m_dwBytes;
};

class WinFileInInterface
{
public:
	virtual BOOL Open(LPCTSTR lpszFileName);
	virtual BOOL DoReadFile(LPVOID lpBuffer, DWORD nNumberOfBytesToRead);
};

class WinFileOutInterface
{
public:
	virtual BOOL Open(LPCTSTR lpszFileName);
	virtual BOOL DoWriteFile(LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite);
};

class CWinFileIn : WFIOInfo, WinFileInInterface
{
public:
	virtual BOOL Open(LPCTSTR lpszFileName)
	{
		return TRUE;
	}
	virtual BOOL DoReadFile(LPVOID lpBuffer, DWORD nNumberOfBytesToRead)
	{
		return ::ReadFile(m_hFile, lpBuffer, nNumberOfBytesToRead, &m_dwBytes, NULL);
	}
};

class CWinFileOut : WFIOInfo, WinFileOutInterface
{
public:
	virtual BOOL Open(LPCTSTR lpszFileName)
	{
		return TRUE;
	}
	virtual BOOL DoWriteFile(LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite)
	{
		return ::WriteFile(m_hFile, lpBuffer, nNumberOfBytesToWrite, &m_dwBytes, NULL);
	}
};

class CWinFileInOut : WFIOInfo, WinFileInInterface, WinFileOutInterface
{
public:
	BOOL Open(LPCTSTR lpszFileName)
	{
		return TRUE;
	}
};

any idea what i'm doing wrong?

GDavy27-Jul-05 20:29

GDavy

27-Jul-05 20:29

an interface should be purely abstract so put a =0 behind function definitions.

class WinFileInInterface<br />
{<br />
public:<br />
	virtual BOOL Open(LPCTSTR lpszFileName) = 0;<br />
	virtual BOOL DoReadFile(LPVOID lpBuffer, DWORD nNumberOfBytesToRead) = 0;<br />
};<br />
<br />
class WinFileOutInterface<br />
{<br />
public:<br />
	virtual BOOL Open(LPCTSTR lpszFileName) = 0;<br />
	virtual BOOL DoWriteFile(LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite) = 0;<br />
};

nm_11428-Jul-05 18:02

28-Jul-05 18:02

When I tried that I got the following errors:

Compiling...
winiotest.cpp
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : error C2259: 'CWinFileInOut' : cannot instantiate abstract class due to following members:
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(109) : see declaration of 'CWinFileInOut'
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : warning C4259: 'int __thiscall WinFileInInterface::DoReadFile(void *,unsigned long)' : pure virtual function was not defined
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(73) : see declaration of 'DoReadFile'
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : warning C4259: 'int __thiscall WinFileOutInterface::DoWriteFile(const void *,unsigned long)' : pure virtual function was not defined
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(80) : see declaration of 'DoWriteFile'
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : error C2259: 'CWinFileInOut' : cannot instantiate abstract class due to following members:
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(109) : see declaration of 'CWinFileInOut'
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : warning C4259: 'int __thiscall WinFileInInterface::DoReadFile(void *,unsigned long)' : pure virtual function was not defined
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(73) : see declaration of 'DoReadFile'
C:\C++\Projects\[Tests]\winiotest\winiotest.cpp(29) : warning C4259: 'int __thiscall WinFileOutInterface::DoWriteFile(const void *,unsigned long)' : pure virtual function was not defined
        c:\c++\projects\[tests]\winiotest\cwinfileio.h(80) : see declaration of 'DoWriteFile'

vikramlinux27-Jul-05 20:39

vikramlinux

27-Jul-05 20:39

Why dont u use classname as specifier? like
ObjectInstanceName.Classname::variablename?

Bob Stanneveld27-Jul-05 21:21

Bob Stanneveld

27-Jul-05 21:21

Hello,

As some other user already suggested, you should use virtual base classes (if you want to share among the different types). See Here[^] for more information on virtual inheritance.

Another way to go (IMHO the better way) is to encapsulate some details of your base classes using private inheritance instead of public. Also you need to override some other functions to resolve the ambiguities:

struct WFIOInfo
{	HANDLE m_hFile;	
	DWORD m_dwBytes;
};

class WinFileInInterface
{
public:	
	virtual BOOL Open(LPCTSTR lpszFileName);	
	virtual BOOL DoReadFile(LPVOID lpBuffer, DWORD nNumberOfBytesToRead);
};

class WinFileOutInterface
{
public:	
	virtual BOOL Open(LPCTSTR lpszFileName);	
	virtual BOOL DoWriteFile(LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite);
};

class CWinFileIn : private WFIOInfo, public WinFileInInterface
{
public:	
	virtual BOOL Open(LPCTSTR lpszFileName)	
	{return TRUE;}	
	virtual BOOL DoReadFile(LPVOID lpBuffer, DWORD nNumberOfBytesToRead)	
	{return ::ReadFile(m_hFile, lpBuffer, nNumberOfBytesToRead, &m_dwBytes, NULL);}
};

class CWinFileOut : private WFIOInfo, WinFileOutInterface
{
public:	
	virtual BOOL Open(LPCTSTR lpszFileName)	{return TRUE;}	
	virtual BOOL DoWriteFile(LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite)
	{return ::WriteFile(m_hFile, lpBuffer, nNumberOfBytesToWrite, &m_dwBytes, NULL);}
};

class CWinFileInOut : private: WFIOInfo, 
		      public: WinFileInInterface, 
  		      public: WinFileOutInterface
{
public:	
	BOOL Open(LPCTSTR lpszFileName)	
	{	return TRUE;	}
};

Using the private inheritance, you make the class only visible and accessible to the class that derives from it. Classes which are derived from that class, do not know about the previous privatly inherited classes. This way, you can have multiple names inside different classes.

Hope this helps Big Grin | :-D

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

nm_11429-Jul-05 11:24