Re: document class
void CMIAppView::OnBnClickedBtnMmenuState()
{
CWizardStartDialog dlgStartWiz(this);
CNetNetworkDialog NetNetworkDlg;
CDisplayDialog DisplayDlg;
dlgStartWiz.AddPage(&NetNetworkDlg, CNetNetworkDialog ::IDD);
dlgStartWiz.AddPage(&DisplayDlg, CDisplayDialog ::IDD);
dlgStartWiz.DoModal();
}
Is it the correct place to start this dialog in the view class?
*****
How do thse know what to update? If it is global state they are updati=
ng, then they own
the state, and there is no problem. But when an update is committed, h=
ow is it committed,
and where is it committed to? Generally, dialogs should not have acces=
s to anything
beyond their own scope (that is, they should know nothing of mainframe, v=
iews or
documents) but in the case where a dialog manages global state, then the =
global state is
accessible.
Now, the next question: given that the dialogs have completed, is there a=
nything in the
views that needs to be updated? If so, then the dialogs should be hand=
led by the
document, so it can call UpdateAllViews.
=
joe
****
That would mean that I have to call a document method in the
CMIAppView::OnBnClickedBtnMmenuState() to start the dialog (in the
document class) and after getting back from the dialog I can call
UpdateAllViews().
How is it possible to get the specific information for all checkboxes
as well as other elements of the dialog from the document class? I
think the possibility to add a pointer of the document class at
startup of the dialog is not so good, because of the OO.
****
I agree. THere are a couple solutions. One is, why is the document =
managing the display?
If the display is managed by a display state class, then you can include =
a pointer to the
display-state class and initialize it before you do the DoModal, possibly=
even by
extending the constructor to the CDisplayDlg class. Another is to simp=
ly have a public
member that is initialized. Or, you can have this dialog directly acce=
ss the one-and-only
global display state object (because it is really the interface; in fact,=
I'd probably
include the dialog interaction as part of the display state object, such =
as
CDisplay::AskUserForParameters();
which launched a dialog to get the values, and therefore the whole mechan=
ism is completely
hiddent from the non-display-state components.
Ok thanks for pointing that out. Calling a public method of the
CDisplay class in the OnInitDialog method to get all the required
information to set all elements / items as checkboxes with the correct
behaviour; and before leaving / getting back from the dialog (user has
clicked the OK button) I will call another public function of the
CDisplay method to update the display values according to the user
settings he made in the dialog.
One question: I`ve a XML file (together with an XMLFile-Class -
installed with a global variable of this class to access this class).
I call this class in the OnNewDocument method to load the xml file and
parse all included values from the xml file into a CStringList (name
of the node, value of the node and attributes of the node if available
-> then a empty string and the next item). This list includes all
network settings, display settings and so on.
If I update the display settings in the CDisplay class after the user
clicks on the OK button in the dialog; Is it the responsibility of the
CDisplay class to update also the CStringList in the XML File class?
If so, the display class has access to the global variable of the XML
file class and simply call the CXMLFile::SetNewParams() method?
After getting back from the dialog, you said it`s a good time to call
UpdateAllViews(). So at first I will call the =B4CXMLFile class to get
the latest version of the CStringList which includes the updated
information from the CDisplay-class and after that I call
UpdateAllViews()?
What I see here is too much thinking-in-C and not enough thinking-in-C++.
that`s totally true.
class CDisplay
{
public:
CDisplay(void);
~CDisplay(void);
protected:
UINT m_brightness;
CFont m_StatFont;
CFont m_IpAddrFont;
};
extern CDisplay DisplayInfo;
cpp.file
#include "Display.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
#define DISPLAY_BRIGHT_MIN 0
#define DISPLAY_BRIGHT_MAX 100
//global variable to access this class from the document class
CDisplay DisplayInfo;
void CDisplay::GetFont(CFont& statFont, CFont& ipAddrFont)
{
statFont = m_StatFont;
ipAddrFont = m_IpAddrFont;
}
Do you know how do I have to setup this simply function to work? At
the moment I get the error message "CObject::operator =": no access to
private member, which declaration obtained in the CObject class....
Another question: where do you declare defines? In the header file of
the specific class or in an additonal header file, where only defines
will be?
#define DISPLAY_BRIGHT_MIN 0
#define DISPLAY_BRIGHT_MAX 100
I tend to prefer the model of
CMIAppDoc::GetArray(CStringArray & result, ....whatever...)
{
return(XmlFile.GetXmlData(nbr));
****
Who allocates the CStringArray and who is responsible for its cleanup?
*****
}
I thought the best way would be that the class which tries to get some
informaton from another class is responsible for this CStringArray.
That means if the http-socket class tries to get some information to
fill the required http page (sending a PostMessage to the visible
window) will have a class member protected CStringList; because the
only other option would be to declare a global variable...
class HttpSoc :
public CConnSoc
protected:
CStringList sListGetXmlParam;
};
void HttpSoc::ProcessPktRecv(CByteArray &data)
{
//among other things
viswnd->PostMessage(UWM_GET_DATA_FROM_XML_LIST,
(WPARAM)sListGetXmlParam, ::GetCurrentThreadId());
}
In the visible window class;
LRESULT CMIVisWnd::OnGetDataFromXmlList(WPARAM wParam, LPARAM lParam)
{
//XmlList is the global variable of the CXmlListClass
CStringArray *slist = XmlList.GetList();
//send post-thead-message back to http-thread class
::PostThreadMessage(lParam, UWM_HTTP_XML_FILE, (WPARAM)slist,
0);
return TRUE;
}
The visible window class (CMIVisWnd) w=EDll handle the get and post
message requests from the http class as well as requests from the
document class; if there`s a reason to send a PostMessage to the
document class.
class CMIVisWnd : public CWnd
{
public:
CMIVisWnd(void);
virtual ~CMIVisWnd(void);
//create visible window
BOOL Start(CMIAppDoc * d);
protected:
CMIAppDoc *doc;
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);
afx_msg LRESULT OnGetDataFromDoc(WPARAM wParam, LPARAM);
afx_msg LRESULT OnSetDataFromHttp(WPARAM wParam, LPARAM);
DECLARE_MESSAGE_MAP()
};
best regards
Hans