Re: document class
On 23 Sep., 04:22, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On Wed, 22 Sep 2010 09:50:22 -0700 (PDT), mfc <mfcp...@googlemail.com> wr=
ote:
ok
let`s assume that the whole fixture we`re talking about is a video
recorder with an integrated webserver and a display for the user. I
decided to use a SDI application because it is enough for this project
(I don`t need more than one document).
I`ve nothing installed in the application class (so far) - there`s
only what visual studio created installing a sdi document.
In the document class: OnNewDocument() I call my CXmlFile-Class to
open the xml file with the user specific data. These information are
necessary / important for the view class as well as for the
webserver.
****
So the "display information" applies to the client user? Or the hostin=
g application? If
the client user, it can't be in the document because it would be unique t=
o each client
connection. So I'm now confused again as to what is happening.
****
At the moment there`s only one XML file for all client users. The only
way for a client user to get his specific data (network, display
settings) is to load a second / another xml file, where these
information are stored. That means that there`s only one unique
document at the same time, which is unique to all users at this time.
If a second client user (user two) wants to change the brightness of
the display, the brightness will also change for user one. The same is
true for the network settings - there`s only one network connection in
the video recorder. If client user one will change these settings,
client user two will see that.
class CMIAppDoc : public CDocument
{
protected: // Nur aus Serialisierung erstellen
CMIAppDoc();
DECLARE_DYNCREATE(CMIAppDoc)
protected:
CXmlFile XmlFile;
};
In the view class I will call the CNetwork class to create the thread
for the http webserver in the OnInitialUpdate() method. I didn`t find
any other suitable place to do this, because I need a valid window to
install the UI-threads. But I`m definitly not sure if it is really the
correct place, because the view itself has nothing to do with creating
threads for the webserver or anything else... If I`m right the view
class is only responsible for all kinds of members of buttons
checkboxen etc. which are visible on the display.
****
So if you have more than one view (which IS possible in SDI) which is in =
charge of the
network connection. It would strike me that this is part of the "docum=
ent state" rather
than the "view state", assuming it is not actually global state.
The point is, if you need a window for PostMessage notifications, and the=
interaction is
limited to the document, a view is inappropriate; this is why I had to cr=
eate a
highly-integrated invisible window as part of the document class, so a vi=
ew class never
entered the discussion.
And I'm still confused as to whether you are describing the actual server=
app, or a client
app.
****
If you are sitting in front of your video recorder and one of your
friends is also sitting in front of THIS video recorder - then you
will have my application. There`s one fixture which can load different
settings but if you load one of these settings (stored in the XML)
your friend is not able to say " I want to load my specific settings,
because then you also will see his specific settings... and not your
settings"
If`ve more than one view class, but only one view class is available
at the same time. The menu of the video recorder is my view class. If
you enter a menu -> I`ll create a new dialog -> a new view.
Moreover the view class get the xml list, which includes some
information (e.g. which checkbox is checked or not and so on)... from
the document class. And the view class gets the created font, which
will be created in the mainframe OnCreate() method.
****
No, the document receives state which is *reflected* in the view by vario=
us check boxes
showing the state of the document; in OnInitialUpdate, you query the docu=
ment and set the
check boxes to reflect the document state. The view never knows or car=
es WHY the value
from GetWhateverState() returns TRUE of FALSE (indicating check or unchec=
ked), how it was
encoded, how it is represented in the document, etc.; and if you change t=
he checkbox, you
call the SetWhateverState() method with a BOOL indicating what the new st=
ate should be;
the view does not know or care if this is stored in XML format, at the en=
d of a wire, or
in East Hyperspace. In fact, the view should not know or care about XML.
I have no idea why you would create a font in the mainframe; if I want a =
font for a view,
I create it in the view. The view should not know or care about the ma=
inframe.
****
The problem is that the font should be the same for all views not only
for one view. Therefore I`m using the mainframe instead of the view
class. In this way it is possible for each view to get the and set the
same font.
void CMIAppView::OnInitialUpdate()
{
CFormView::OnInitialUpdate();
net.InitThreads();
****
There should be no concept of 'net' in the view. If this is logically =
part of the
document state, it would call GetDocument()->Init(), assuming the threads=
were not created
in the obvious place, the OnNewDocument method.
****
That`s a good hint - GetDocument()->Init(). In this way the view class
only knows the document class and not the network class as well.
m_XmlUserList = ((CMIAppDoc *)GetDocument())->GetL=
ist(0);
****
What is the type of this variable, and why is the declaration not shown? =
Note that the
implication that it is XML already says that the view knows more about th=
e representation
in the document than is healthy for it. I would be more inclined to do
POSITION p = GetDocument()->GetFirstUserPosition();
while(p != NULL)
{
SomeType something = GetDocumen=
t()->GetNextUser(p);
... deal with it
}
Of course, if you were really serious, you'd figure out how to write a st=
d::-style
iterator for this. I find them too hairy.
****
HFONT hfont = (HFONT)GetParent()-
SendMessage(UWM_ON_GET_FONT, USE_STAT_FONT, 0);
CFont* pStatFont = CFont::FromHandle(hfont);
****
I'm not sure why you have to ask the parent for the font; for example, wh=
y isn't the font
created in the view? What is the advantage of putting it in the mainfr=
ame?
****>}
After that everything is initialized.
Assuming that the user will use the webserver to change some values
(network settings, display settings and so on) -> the fixture will
receive a post msg to the specific http connection thread. From there
I will send a PostMessage to a visible window (mainthread), I`ve
created, so that the document class is able to receive messages.
****
I would post a message to the document's invisible window, most likely by=
doing
WhateverDocument::NotifyChange(...);
and if the implementation of this required a PostMessage to the invisible=
window, why
should anyone care? You're still making things too closely-coupled.
****
The next step will be to valid the received information from the post
message. The validation for the network settings is only possible in
the network class where I installed the http thread. The display
settings validation is only in the CDisplay class possible and so on.
The com port settings is only possible in the comport class.... but
where (in which class) should I access these classes?
****
So, there should be a network state type, which contains all the network =
stuff, including
the validation routine. The display class would have a validation meth=
od. So, I might
call
BOOL CDisplay::Validate(const CString & parameters);
which would validate the parameters; in fact, I'd probably have
BOOL CDisplay::SetParameters(const CString & parameters);
And where do you install the member variable of these classes?? In the
document class? Or do you use static methods?
and if any validation needs to be done, the SetParameters method will cal=
l the Validate
method, and I wouldn't want to see any of this. You keep introducting =
these dependencies
where class A needs to know how class B is implemented to know how to use=
class B; in
fact, you have insufficient abstraction. As soon as you start thinking=
OO, the
abstraction falls out naturally.
If these recieved information are valid I will store these information
in the xml file by the document class and call updateallviews.
****
You are still looking too deeply inside the implementation of class B. =
Class A should
have only the vaguest notion of how class B works; it calls class B, and =
class B does
stuff. So, for example, there should be no knowledge in a view class t=
hat a display or
network class exists in the document; instead, there are methods that you=
call that
completely mask the concepts of network objects and display objects.
****
Thats the whole part. My question is now: where is the right place to
call the display class, the network class and so on (which are in the
same thread as the mainthread)?
****
Classes do not exist in threads. Classes exist. Threads exist. T=
hat's all there is.
There are situations in which thread 2 cannot call certain methods becaus=
e there is a
conflict with thread 1's use of state, but you document these as restrict=
ions, without
having to know why.
****
If I`m straight forward, then the application class sounds suitable
(as you pointed it out before) because all these things are
application dependend and not document depended. If so, then I need a
way to access these classes - installing a protected member in the
application class together with a public function... And which class
should be able to access the application class (in this case)?
****
If these are global state, then they are global state, and they are not a=
ffiliated with
the app, document, view, or anything else. Now it may be the case that=
only the document
knows about and manipulates this global state, but don't confuse that wit=
h the state being
"part of" the document.
joe
****
I hope you could give me some hints...
best regards
Hans
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm- Zitierten Text ausblenden =
-
- Zitierten Text anzeigen -