Re: document class

On Sep 21, 11:54 pm, mfc <mfcp...@googlemail.com> wrote:


This is valid, provided that you did put an instance of CMainFrame
into m_pMainWnd (and you did ;-) ).

However, it is a mistake to then use CMainFrame (or app, or a doc in
the case of SDI) to get to "global" instances of CFont, CDisplay, and
CNetwork. More generally, for all but smallest throwaway projects, it
is a mistake to put any of your "global" state in these objects _and_
use CYourApp/CMainFrame/doc to get to said global state.

It might not be obvious now, but as code grows, you will realize that
if you do it this way, if you dump all "global" stuff into app or main
frame, each time you change _anything_ in said global state, _any_
client (*.cpp file) using _any_ part of the whole global state will
need to be recompiled. In other words, you will create compile-time
dependency where there is none, or at least not necessarily.

In other words, if you have, say CDisplay and CNetwork, you could do
e.g.:

app.h

class CApp : public CWinApp
{
private:
  friend CDisplay& GlobalDisplayState();
  CDisplay m_display; // etc.
}
// DO NOT include CApp in other source files nilly-willy!

display.h

class CDisplay {...};
CDisplay& GlobalDisplayState();

display.cpp

#include "app.h"
#include "display.h"

CDisplay& GlobalDisplayState()
{
  return static_cast<CApp*>(AfxGetApp())->m_display;
}

Rinse, repeat for CNetwork. Note: this approach uses a function to
access global state. Function might mean more code. So you might want
move GlobalDisplayState to an *.inl file in NDEBUG, but I'd verify
first that optimization actually does not inline this anyhow (it
should happen) and that there is indeed a visible performance hit (it
shouldn't happen).

More generally: avoid including app.h, mainfrm.h, doc.h in ANY other
source files. This absolutely kill your compilation times as project
grows, and it's doable with not-such-a-great effort (see above).
Future generations will thank you! ;-)

The talk about PostMessage, BTW, seems incidental to your global
state. Background and global state _are_ connected, but, AFAICanSee,
only because ou want to modify global state from background, and you
want to update UI accordingly (which you should do in the main UI
thread).

If this is your purpose, then you could do simply this:
* make your global state elements thread-safe
* make your background change your global state
* from background, use PostMessage (to e.g. m_pMainWnd) to "nudge" UI
to change; use LPARAM, WPARAM to "explain" what should be changed if
you need to be more precise. Once in MainWnd, you could/should simply
iterate over documents and call UpdateAllViews (possibly passing
LPARAM and WPARAM to lHint and pHint).

In other words, there is no __need__ to add responsibility of updating
UI to your global state classes.

Goran.