? Post Window (Dialog) Creation Flag

Hi,

I've searched high and low (mostly low) but can't find anything about how to determine if a window (specifically a dialog and it's
controls) is completely created.

As you know, a window may/will receive all kinds of messages while it's being created.  Unfortunately, sometimes we write message
handlers that are to be executed AFTER the dialog and all of it's controls are created.

For example, moving/sizing controls in a dialog box is done in OnSize as expected.  However, WM_SIZE is sent to the window before
the controls even exist.  To avoid an exception, you have to check that the controls are there before performing the actions on
them.

Instead of using the common method for testing the control's existence:

  OnSize {
    if (GetDlgItem(IDC_SOME_CONTROL)!=NULL) {
  //or
  //if (SomeControl.GetSafeHwnd()   !=NULL) {
  //  perform actions on controls
    }
  }

I would like to use a simple one-shot flag.  That is, I am trying to make a simple member boolean that is set to false in the
constructor, then set to true when the window is finished being created.  From then on, any tests for control existence would just
check that instead of calling a function.  While it doesn't seem like a big deal, it could be.  For example, if you are resizing a
window, it will receive a lot of WM_SIZE messages, and having it do the extra overhead could possibly have a noticeable impact.
Even if it doesn't, using a flag is just more elegant, that's what _flags_ are for.

However, I cannot find a way to determine when the window is finished being created.  I vaguely remember there being some kind of
message that is sent when it's done but I can't find it, so I'm not so sure anymore.

I tried setting the flag in OnSize but it didn't work because it was only called once on dialog creation, at which point the
controls didn't yet exist; it was not called again after the controls were there.

Does anyone know of a way to determine if the window is completed?


Thanks a lot.

-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/10/2006 12:00:06 AM
vc.mfc 33608 articles. 0 followers. Follow

20 Replies
239 Views

Similar Articles

[PageSpeed] 54

What about WM_INITDIALOG?

-- 
Jeff Partch [VC++ MVP]


"Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
> Hi,
>
> I've searched high and low (mostly low) but can't find anything about how 
> to determine if a window (specifically a dialog and it's
> controls) is completely created.
>
> As you know, a window may/will receive all kinds of messages while it's 
> being created.  Unfortunately, sometimes we write message
> handlers that are to be executed AFTER the dialog and all of it's controls 
> are created.
>
> For example, moving/sizing controls in a dialog box is done in OnSize as 
> expected.  However, WM_SIZE is sent to the window before
> the controls even exist.  To avoid an exception, you have to check that 
> the controls are there before performing the actions on
> them.
>
> Instead of using the common method for testing the control's existence:
>
>  OnSize {
>    if (GetDlgItem(IDC_SOME_CONTROL)!=NULL) {
>  //or
>  //if (SomeControl.GetSafeHwnd()   !=NULL) {
>  //  perform actions on controls
>    }
>  }
>
> I would like to use a simple one-shot flag.  That is, I am trying to make 
> a simple member boolean that is set to false in the
> constructor, then set to true when the window is finished being created. 
> From then on, any tests for control existence would just
> check that instead of calling a function.  While it doesn't seem like a 
> big deal, it could be.  For example, if you are resizing a
> window, it will receive a lot of WM_SIZE messages, and having it do the 
> extra overhead could possibly have a noticeable impact.
> Even if it doesn't, using a flag is just more elegant, that's what _flags_ 
> are for.
>
> However, I cannot find a way to determine when the window is finished 
> being created.  I vaguely remember there being some kind of
> message that is sent when it's done but I can't find it, so I'm not so 
> sure anymore.
>
> I tried setting the flag in OnSize but it didn't work because it was only 
> called once on dialog creation, at which point the
> controls didn't yet exist; it was not called again after the controls were 
> there.
>
> Does anyone know of a way to determine if the window is completed?
>
>
> Thanks a lot.
>
> -- 
> Alec S.
> news/alec->synetech/cjb/net
>
> 


0
jeffp (1711)
9/10/2006 12:08:47 AM
"Jeff Partch" <jeffp@mvps.org> wrote in message news:evIgL1G1GHA.3644@TK2MSFTNGP03.phx.gbl...
> "Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
> > Does anyone know of a way to determine if the window is completed?

> What about WM_INITDIALOG?

I don't believe that the controls are available yet at that point (at least I don't remember it working the last time I tried.)
I'll do a test now to double check (if it does works, it would be too easy).  :)

-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/10/2006 1:07:28 AM
Override OnInitDialog. In it, call the base class first. At that time your
controls should be created. You can then set a flag as you want. I would
still use GetDlgItem after the flag(at least in Debug version) to confirm
that control actually do exist.

--
Ajay Kalra [MVP - VC++]
ajaykalra@yahoo.com


"Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
> Hi,
>
> I've searched high and low (mostly low) but can't find anything about how
to determine if a window (specifically a dialog and it's
> controls) is completely created.
>
> As you know, a window may/will receive all kinds of messages while it's
being created.  Unfortunately, sometimes we write message
> handlers that are to be executed AFTER the dialog and all of it's controls
are created.
>
> For example, moving/sizing controls in a dialog box is done in OnSize as
expected.  However, WM_SIZE is sent to the window before
> the controls even exist.  To avoid an exception, you have to check that
the controls are there before performing the actions on
> them.
>
> Instead of using the common method for testing the control's existence:
>
>   OnSize {
>     if (GetDlgItem(IDC_SOME_CONTROL)!=NULL) {
>   //or
>   //if (SomeControl.GetSafeHwnd()   !=NULL) {
>   //  perform actions on controls
>     }
>   }
>
> I would like to use a simple one-shot flag.  That is, I am trying to make
a simple member boolean that is set to false in the
> constructor, then set to true when the window is finished being created.
From then on, any tests for control existence would just
> check that instead of calling a function.  While it doesn't seem like a
big deal, it could be.  For example, if you are resizing a
> window, it will receive a lot of WM_SIZE messages, and having it do the
extra overhead could possibly have a noticeable impact.
> Even if it doesn't, using a flag is just more elegant, that's what _flags_
are for.
>
> However, I cannot find a way to determine when the window is finished
being created.  I vaguely remember there being some kind of
> message that is sent when it's done but I can't find it, so I'm not so
sure anymore.
>
> I tried setting the flag in OnSize but it didn't work because it was only
called once on dialog creation, at which point the
> controls didn't yet exist; it was not called again after the controls were
there.
>
> Does anyone know of a way to determine if the window is completed?
>
>
> Thanks a lot.
>
> --
> Alec S.
> news/alec->synetech/cjb/net
>
>


0
ajaykalra (6840)
9/10/2006 1:09:34 AM
"Alec S." <@> wrote in message news:ORvy$VH1GHA.4176@TK2MSFTNGP06.phx.gbl...
> "Jeff Partch" <jeffp@mvps.org> wrote in message news:evIgL1G1GHA.3644@TK2MSFTNGP03.phx.gbl...
> > "Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
> > > Does anyone know of a way to determine if the window is completed?
>
> > What about WM_INITDIALOG?
>
> I don't believe that the controls are available yet at that point (at least I don't remember it working the last time I tried.)
> I'll do a test now to double check (if it does works, it would be too easy).  :)


Well, it works.  Duh, of course it works, how else would I be able to initialize controls in OnInitDialog?  :)

I guess I just got stuck thinking inside the box because everywhere I look, I see the same old "if (GetDlgItem(IDC_CONTROL)!=NULL)"
being used.  From now on I'm using the flag.


Thanks.

-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/10/2006 1:13:02 AM

"Alec S." <@> wrote in message news:ORvy$VH1GHA.4176@TK2MSFTNGP06.phx.gbl...
> "Jeff Partch" <jeffp@mvps.org> wrote in message
news:evIgL1G1GHA.3644@TK2MSFTNGP03.phx.gbl...
> > "Alec S." <@> wrote in message
news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
> > > Does anyone know of a way to determine if the window is completed?
>
> > What about WM_INITDIALOG?
>
> I don't believe that the controls are available yet at that point (at
least I don't remember it working the last time I tried.)

Thats not true. Make sure you call the base class. Controls should be
created by then. The purpose of OnInitDialog is precisely what you are
trying to do. You typically initialize controls in this method.

--
Ajay Kalra [MVP - VC++]
ajaykalra@yahoo.com



0
ajaykalra (6840)
9/10/2006 1:13:20 AM
"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message news:eQOGHXH1GHA.3476@TK2MSFTNGP04.phx.gbl...
> Override OnInitDialog. In it, call the base class first. At that time your
> controls should be created. You can then set a flag as you want.

Thanks, that's what I'm doing now.


> I would still use GetDlgItem after the flag(at least in Debug version) to
> confirm that control actually do exist.

Why wouldn't it exist?  Is it because of the extra time the Debug version takes?  That shouldn't be a problem since the calls are
not asynchronous, should it?


-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/10/2006 1:58:10 AM
> Why wouldn't it exist?  Is it because of the extra time the Debug version
takes?  That shouldn't be a problem since the calls are
> not asynchronous, should it?

It  will exist. Its just a precaution.  If you remove one of the controls
from the dialog, an assert will let you know what happened.

--
Ajay Kalra [MVP - VC++]
ajaykalra@yahoo.com


0
ajaykalra (6840)
9/10/2006 2:08:37 AM
Bind the control to a control variable, and then do
	if(c_SomeControl.GetSafeHwnd() != NULL)

which does the same thing, but yes, you have to check it.

I just create a variable called 
	BOOL Initialized;
in the constructor
	Initialized = FALSE;
in OnInitDialog
	Initialized = TRUE;
	updateControls();
	return TRUE;

where updateControls() is my handler that handles all control
enabling/disabling/showing/hiding.  See my essay on dialog control management on my MVP
Tips site.

But there is no need to use a flag to represent information that is already encoded; so,
for example, using GetSafeHwnd() is more elegant than attempting to mimic it with a
separate mechanism (that's *not* what flags are for!)

You know when everything is done because OnInitDialog is called!  This is a definite event
in the life of a dialog (OnInitialUpdate in a CFormView serves this purpose as well)

				joe

On Sat, 9 Sep 2006 20:00:06 -0400, "Alec S." <@> wrote:

>Hi,
>
>I've searched high and low (mostly low) but can't find anything about how to determine if a window (specifically a dialog and it's
>controls) is completely created.
>
>As you know, a window may/will receive all kinds of messages while it's being created.  Unfortunately, sometimes we write message
>handlers that are to be executed AFTER the dialog and all of it's controls are created.
>
>For example, moving/sizing controls in a dialog box is done in OnSize as expected.  However, WM_SIZE is sent to the window before
>the controls even exist.  To avoid an exception, you have to check that the controls are there before performing the actions on
>them.
>
>Instead of using the common method for testing the control's existence:
>
>  OnSize {
>    if (GetDlgItem(IDC_SOME_CONTROL)!=NULL) {
>  //or
>  //if (SomeControl.GetSafeHwnd()   !=NULL) {
>  //  perform actions on controls
>    }
>  }
>
>I would like to use a simple one-shot flag.  That is, I am trying to make a simple member boolean that is set to false in the
>constructor, then set to true when the window is finished being created.  From then on, any tests for control existence would just
>check that instead of calling a function.  While it doesn't seem like a big deal, it could be.  For example, if you are resizing a
>window, it will receive a lot of WM_SIZE messages, and having it do the extra overhead could possibly have a noticeable impact.
>Even if it doesn't, using a flag is just more elegant, that's what _flags_ are for.
>
>However, I cannot find a way to determine when the window is finished being created.  I vaguely remember there being some kind of
>message that is sent when it's done but I can't find it, so I'm not so sure anymore.
>
>I tried setting the flag in OnSize but it didn't work because it was only called once on dialog creation, at which point the
>controls didn't yet exist; it was not called again after the controls were there.
>
>Does anyone know of a way to determine if the window is completed?
>
>
>Thanks a lot.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/10/2006 2:15:14 AM
You are *absolutely guaranteed* that all the controls are available; in fact, that is what
OnInitDialog (or OnInitialUpdate) is defined to represent!
					joe

On Sat, 9 Sep 2006 21:07:28 -0400, "Alec S." <@> wrote:

>"Jeff Partch" <jeffp@mvps.org> wrote in message news:evIgL1G1GHA.3644@TK2MSFTNGP03.phx.gbl...
>> "Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
>> > Does anyone know of a way to determine if the window is completed?
>
>> What about WM_INITDIALOG?
>
>I don't believe that the controls are available yet at that point (at least I don't remember it working the last time I tried.)
>I'll do a test now to double check (if it does works, it would be too easy).  :)
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/10/2006 2:16:01 AM
But why use a separate mechanism to replicate knowledge that already exists?  
					joe
On Sat, 9 Sep 2006 21:13:02 -0400, "Alec S." <@> wrote:

>"Alec S." <@> wrote in message news:ORvy$VH1GHA.4176@TK2MSFTNGP06.phx.gbl...
>> "Jeff Partch" <jeffp@mvps.org> wrote in message news:evIgL1G1GHA.3644@TK2MSFTNGP03.phx.gbl...
>> > "Alec S." <@> wrote in message news:esnrhwG1GHA.3372@TK2MSFTNGP04.phx.gbl...
>> > > Does anyone know of a way to determine if the window is completed?
>>
>> > What about WM_INITDIALOG?
>>
>> I don't believe that the controls are available yet at that point (at least I don't remember it working the last time I tried.)
>> I'll do a test now to double check (if it does works, it would be too easy).  :)
>
>
>Well, it works.  Duh, of course it works, how else would I be able to initialize controls in OnInitDialog?  :)
>
>I guess I just got stuck thinking inside the box because everywhere I look, I see the same old "if (GetDlgItem(IDC_CONTROL)!=NULL)"
>being used.  From now on I'm using the flag.
>
>
>Thanks.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/10/2006 2:16:44 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:h1t6g2p6m4396pkvbllj3v90nd5e6cg8no@4ax.com...
> But there is no need to use a flag to represent information that is already encoded;

Sure there is; checking a flag against zero is much faster than making a function call.


> so, for example, using GetSafeHwnd() is more elegant than attempting to mimic it with a
> separate mechanism (that's *not* what flags are for!)

I'm not trying to mimic GetSafeHwnd, I'm creating a flag that indicates the state of the controls (whether or not the controls are
available, ie the status of their existance) and thus whether or not it's safe to perform operations on them (if conditions are
correct), that's a flag by any-computer-definition.

I do understand why you say that GetDlgItem (which you always speak out against) makes more sense, but it's really just a matter of
semantics.  You're using GetDlgItem as "test if the control exists"; I'm using the flag as "the controls exist".


> You know when everything is done because OnInitDialog is called!  This is a definite event
> in the life of a dialog (OnInitialUpdate in a CFormView serves this purpose as well)

And that's why I'm using it now.  I could have sworn I'd already tried it before, but either way it works.



Ajay makes a good point though, if a control is programmatically deleted, then using a simple flag won't reflect that while
GetDlgItem would.  However, every implementation of that which I've seen (Joe's included) does one GetDlgItem for the whole block
(testing a single control's existence before performing operations on all of them).  Therefore, it is no better than a flag.  To
properly guard against programmatically removed controls, each control (that may be removed) would have to be tested with GetDlgItem
before use.


-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/10/2006 4:37:54 AM
You sound as if the time taken for the function call actually matters.  This suggests you
have some weird idea about performance issues; I suggest you think less about "efficiency"
(when it doesn't matter at all!) and more about robustness and correctness.  The argument
about the function call is, frankly, silly.  

You don't need a separate flag for this purpose!  The information already exists! Creating
a flag that duplicates this is a pointless waste of intellectual effort, and can lead to
erroneous code.  So why bother.  I repeat, the efficiency argument is completely silly.
You're about to do something to the control that will consume hundreds of thousands of
machine cycles, and you are worried about a few dozen instructions (GetSafeHwnd is very
fast).  Try to keep things in proportion.  Read my essay on "Optimization: Your Worst
Enemy".  You are making a pointless optimization based on some mythical concept that this
actually matters in real programs.  

Note that GetDlgItem actually takes thousands of instructions, but GetSafeHwnd takes very
few.  Since GetSafeHwnd is easy to code and deals with the problem easily.  A flag
requires additional effort to code, and saves so little time over GetSafeHwnd that it
hardly seems worthy of discussion.

Optimization matters only in inner loops.  The rest of the time, you are saving hundreds
of nanoseconds in contexts that involve hundreds of milliseconds.  Code that is easily
coded and works robustly wins every time over code that is made more complex so that it
optimizes things that can't possibly matter.  And we learned decades ago that replicating
information that can be derived from a single definition point is always a bad policy.  A
flag that replicates information that is already trivially available makes no sense.  It
can't even be justified from the viewpoint of "efficiency", which is always a suspicious
argument unless you actually have a meaningful argument justifying efficiency.

Efficiency matters only when it matters.  Then it matters a lot.  But the
flag-vs.-GetSafeHwnd argument simply cannot matter.
					joe
On Sun, 10 Sep 2006 00:37:54 -0400, "Alec S." <@> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:h1t6g2p6m4396pkvbllj3v90nd5e6cg8no@4ax.com...
>> But there is no need to use a flag to represent information that is already encoded;
>
>Sure there is; checking a flag against zero is much faster than making a function call.
>
>
>> so, for example, using GetSafeHwnd() is more elegant than attempting to mimic it with a
>> separate mechanism (that's *not* what flags are for!)
>
>I'm not trying to mimic GetSafeHwnd, I'm creating a flag that indicates the state of the controls (whether or not the controls are
>available, ie the status of their existance) and thus whether or not it's safe to perform operations on them (if conditions are
>correct), that's a flag by any-computer-definition.
>
>I do understand why you say that GetDlgItem (which you always speak out against) makes more sense, but it's really just a matter of
>semantics.  You're using GetDlgItem as "test if the control exists"; I'm using the flag as "the controls exist".
>
>
>> You know when everything is done because OnInitDialog is called!  This is a definite event
>> in the life of a dialog (OnInitialUpdate in a CFormView serves this purpose as well)
>
>And that's why I'm using it now.  I could have sworn I'd already tried it before, but either way it works.
>
>
>
>Ajay makes a good point though, if a control is programmatically deleted, then using a simple flag won't reflect that while
>GetDlgItem would.  However, every implementation of that which I've seen (Joe's included) does one GetDlgItem for the whole block
>(testing a single control's existence before performing operations on all of them).  Therefore, it is no better than a flag.  To
>properly guard against programmatically removed controls, each control (that may be removed) would have to be tested with GetDlgItem
>before use.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/10/2006 8:10:31 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:qeh7g25adomfsi276rv01a9c8ko6r6tn31@4ax.com...
> You sound as if the time taken for the function call actually matters.  This suggests you
> have some weird idea about performance issues; I suggest you think less about "efficiency"
> (when it doesn't matter at all!) and more about robustness and correctness.

No no, I know that the difference is insignificant (although if they do the same thing, then why not use the faster one as slight as
the difference may be, especially since the other stuff takes so much time, why exacerbate it?)  What I'm saying is that as far as I
can tell, using the other method does not make the code more robust or correct.  You've said that it does a couple of times but have
not given an example of how a flag would cause problems or how GetSafeHwnd could avoid them.  If you've got a valid, reasonable
explanation, then I would be more than happy to accept it.  I just don't currently see the difference.  (I did a quick check through
"Code Complete" (1st edition), and "Writing Solid Code" but they predate Windows so no help there.)


> You don't need a separate flag for this purpose!  The information already exists! Creating
> a flag that duplicates this is a pointless waste of intellectual effort, and can lead to
> erroneous code.

I'm not sure how/where the information already exists.  Using GetDlgItem returns a pointer to a control or NULL.  GetSafeHwnd
returns a handle to a handle to a control or NULL.  The flag indicates if the controls on the dialog exist yet or not.  It sounds an
awful lot like semantics here.  GetDlgItem/GetSafeHwnd return an access variable to a control.  You use them the same way I used the
flag by interpreting them to mean what my flag's sole purpose is.  While using your method saves code, everything I've ever read
says to separate functionality, and write functions that serve ONE purpose since it results in more reusable code (robustness) and
makes it easier to debug (correctness).  By that definition, the flag seems to be the better choice.  :-o


> Note that GetDlgItem actually takes thousands of instructions, but GetSafeHwnd takes very
> few.  Since GetSafeHwnd is easy to code and deals with the problem easily.  A flag
> requires additional effort to code, and saves so little time over GetSafeHwnd

I'm not sure how the flag takes more effort, I've got:
    BOOL m_Loaded;
    ...
    m_Loaded=FALSE;
    ...
    m_Loaded=TRUE;
    ...
    if (m_Loaded) {
That's it, and it appears to work perfectly.  One tiny variable extra (really only needs single bit, but a single byte would have
done), and two extra little lines.  Hardly any effort, especially if I add it to my VC wizard.

Of course like I said, if you know of a reason that this is bad, I'd be happy to hear it.  I'm not as old as you so I'm sure you
know more about this.


-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/11/2006 3:28:46 AM
See below...
On Sun, 10 Sep 2006 23:28:46 -0400, "Alec S." <@> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:qeh7g25adomfsi276rv01a9c8ko6r6tn31@4ax.com...
>> You sound as if the time taken for the function call actually matters.  This suggests you
>> have some weird idea about performance issues; I suggest you think less about "efficiency"
>> (when it doesn't matter at all!) and more about robustness and correctness.
>
>No no, I know that the difference is insignificant (although if they do the same thing, then why not use the faster one as slight as
>the difference may be, especially since the other stuff takes so much time, why exacerbate it?)  What I'm saying is that as far as I
>can tell, using the other method does not make the code more robust or correct.  You've said that it does a couple of times but have
>not given an example of how a flag would cause problems or how GetSafeHwnd could avoid them.  If you've got a valid, reasonable
>explanation, then I would be more than happy to accept it.  I just don't currently see the difference.  (I did a quick check through
>"Code Complete" (1st edition), and "Writing Solid Code" but they predate Windows so no help there.)
****
The flag encodes what you think might be the truth.  That's where the failure point
occurs.  However, if the window gets deleted, the flag will be incorrect.  However, a
CWnd-based class variable can detect that the destruction has happened and the handle will
be set to NULL.  So it will correctly reflect the state.  Unless you implement a way that
guarantees that the flag can never be incorrect, then you have a potential problem.  
>
>
>> You don't need a separate flag for this purpose!  The information already exists! Creating
>> a flag that duplicates this is a pointless waste of intellectual effort, and can lead to
>> erroneous code.
>
>I'm not sure how/where the information already exists.  Using GetDlgItem returns a pointer to a control or NULL.  GetSafeHwnd
>returns a handle to a handle to a control or NULL.  The flag indicates if the controls on the dialog exist yet or not.  It sounds an
>awful lot like semantics here.  GetDlgItem/GetSafeHwnd return an access variable to a control.  You use them the same way I used the
>flag by interpreting them to mean what my flag's sole purpose is.  While using your method saves code, everything I've ever read
>says to separate functionality, and write functions that serve ONE purpose since it results in more reusable code (robustness) and
>makes it easier to debug (correctness).  By that definition, the flag seems to be the better choice.  :-o
****
The information exists in the CWnd object.  It already exists.  That is what a CWnd is
defined as being.  GetDlgItem will work, but it involves a kernel ring transition and a
linear search of all the controls in the dialog, and you had indicated that "efficiency"
mattered.  So GetSafeHwnd is a better choice.

The difference is that GetDlgItem *directly* checks for the existence; GetSafeHwnd checks
*indirectly* through a robust path, but the flag test does not check for the actual
existence; it merely presumes that the flag is correct.  So the ONE purpose of GetDlgItem
is to verify that the window associated with that dialog item ID exists (oh yes, if it
does, you can safe the result and use it later...) and GetSafeHwnd verifies that both a
CWnd object exists and the HWND associated with it exsts (and yes, if you save that
result, you can use that for other purposes).  You are misconstruing the notion of "one
purpose" and confusing it with "a reflection of the truth is always equal to the truth".
*****
>
>
>> Note that GetDlgItem actually takes thousands of instructions, but GetSafeHwnd takes very
>> few.  Since GetSafeHwnd is easy to code and deals with the problem easily.  A flag
>> requires additional effort to code, and saves so little time over GetSafeHwnd
>
>I'm not sure how the flag takes more effort, I've got:
>    BOOL m_Loaded;
>    ...
>    m_Loaded=FALSE;
>    ...
>    m_Loaded=TRUE;
>    ...
>    if (m_Loaded) {
>That's it, and it appears to work perfectly.  One tiny variable extra (really only needs single bit, but a single byte would have
>done), and two extra little lines.  Hardly any effort, especially if I add it to my VC wizard.
****
Yes, and that takes extra intellectual effort.  It is one more variable.  Complexity of
code is related to the number of variables and their lifetimes; the longer a variable
exists, the more chance it has to interact with other state.  Therefore, it is not just
the act of adding the variable, but the considerable baggage that comes along with that
addition.  The presumption, for example, that the variable always represents the truth.
The presumption that you have always maintained that relationship between the reflection
of the truth and the truth itself.  This is why modern languages always have scoped
variables; you can be certain that once you leave scope, the variable is gone, and
therefore can no longer interact with anything else in the program.  Apply the "global
variable considered harmful" analysis to class variables, recursively, to see that create
a variable like this violates the same principles that make global variables bad.  

Do not duplicate effort trying to represent images of the truth when the truth itself is
sufficient and easy to query.
****
>
>Of course like I said, if you know of a reason that this is bad, I'd be happy to hear it.  I'm not as old as you so I'm sure you
>know more about this.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/11/2006 2:21:19 PM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:4grag2teperdh65s81533gt9238eqhvcir@4ax.com...
> The information exists in the CWnd object.  It already exists.  That is what a CWnd is
> defined as being.  GetDlgItem will work, but it involves a kernel ring transition and a
> linear search of all the controls in the dialog, and you had indicated that "efficiency"
> mattered.  So GetSafeHwnd is a better choice.

I only meant that since there's so much work to be done, it's best not to add to it.  So yes, you're right, using GetSafeHwnd is
better (assuming of course that it's got a control variable; I don't imagine that you would propose that every single control to be
manipulated should ALWAYS be given a control variable do you?  Even a simple static whose only purpose is to show some value through
SetWindowText?  That would be an extra variable, and extra memory.)


> The difference is that GetDlgItem *directly* checks for the existence; GetSafeHwnd checks
> *indirectly* through a robust path, but the flag test does not check for the actual
> existence; it merely presumes that the flag is correct.  So the ONE purpose of GetDlgItem
> is to verify that the window associated with that dialog item ID exists (oh yes, if it
> does, you can safe the result and use it later...) and GetSafeHwnd verifies that both a
> CWnd object exists and the HWND associated with it exsts (and yes, if you save that
> result, you can use that for other purposes).  You are misconstruing the notion of "one
> purpose" and confusing it with "a reflection of the truth is always equal to the truth".

You make a valid point, and I would certainly do that if there were any reason to believe that the control might not be there (like
if I were to remove some).  But if I do not remove any controls, then shouldn't a flag be reliable enough?

More importantly, what I'm saying is that when you use just one of those to test the existance of a single control, then it is no
safer than the flag.  For example doing something like this:

  if (m_Edit.GetSafeHwnd!=NULL)
    m_Edit.MoveWindow(blah);
  if (m_Button.GetSafeHwnd!=NULL)
    m_Button.MoveWindow(blah);
  if (GetDlgItem(IDC_LIST)!=NULL)
    GetDlgItem(IDC_LIST)->MoveWindow(blah);

Would make sense and would be fine, but you and everyone else are doing this:

  if (m_Edit.GetSafeHwnd!=NULL) {
    m_Edit.MoveWindow(blah);
    m_Button.MoveWindow(blah);
    //GetDlgItem(IDC_LIST)->MoveWindow(blah);  //let's be extra safe on this one:
    CWnd* list=GetDlgItem(IDC_LIST);
    if (list!=NULL) list->MoveWindow(blah);
  }

You're not testing for the existance of individual controls before using them, you're testing whether or not the dialog's controls
have been created yet.  In this way, it's functionally identical to and no more reliable than the flag.  What if that one control
that you tested no longer exists?  Then NONE of the controls are moved.


> Yes, and that takes extra intellectual effort.  It is one more variable.  Complexity of
> code is related to the number of variables and their lifetimes; the longer a variable
> exists, the more chance it has to interact with other state.  Therefore, it is not just
> the act of adding the variable, but the considerable baggage that comes along with that
> addition.  The presumption, for example, that the variable always represents the truth.
> The presumption that you have always maintained that relationship between the reflection
> of the truth and the truth itself.  This is why modern languages always have scoped
> variables; you can be certain that once you leave scope, the variable is gone, and
> therefore can no longer interact with anything else in the program.  Apply the "global
> variable considered harmful" analysis to class variables, recursively, to see that create
> a variable like this violates the same principles that make global variables bad.
>
> Do not duplicate effort trying to represent images of the truth when the truth itself is
> sufficient and easy to query.
> ****

Plus, with the ease and rapidity of exploits, it's probably better to have as few variables as possible.


-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/11/2006 5:09:16 PM

On Mon, 11 Sep 2006 13:09:16 -0400, "Alec S." <@> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:4grag2teperdh65s81533gt9238eqhvcir@4ax.com...
>> The information exists in the CWnd object.  It already exists.  That is what a CWnd is
>> defined as being.  GetDlgItem will work, but it involves a kernel ring transition and a
>> linear search of all the controls in the dialog, and you had indicated that "efficiency"
>> mattered.  So GetSafeHwnd is a better choice.
>
>I only meant that since there's so much work to be done, it's best not to add to it.  So yes, you're right, using GetSafeHwnd is
>better (assuming of course that it's got a control variable; I don't imagine that you would propose that every single control to be
>manipulated should ALWAYS be given a control variable do you?  Even a simple static whose only purpose is to show some value through
>SetWindowText?  That would be an extra variable, and extra memory.)
****
Actually, I *do* advocate that every single control that is manipulated should be given a
control variable.  Why not?  Does it ever make sense *not* to do this?  Why have two
completely orthogonal mechanisms to handle this.  And the control variables work correctly
if you decide to override SetWindowText, whereas the GetDlgItem approach will cause
subclassed objects to fail completely.  Another failure mode.  "Robust under maintenance"
is critical.  Therefore, I should be able to subcass a CStatic, override SetWindowText,
change the declaration, and recompile, and everything will work correctly.  E.g.,
flicker-elimination:
	void CMyStatic::SetWindowText(LPCTSTR s)
	    {
                     CString old;
                     CStatic::GetWindowText(old);
                     if(old == s)
                        return;
                     CStatic::SetWindowText(s);
                   }

If I had been doing this with GetDlgItem, I have to go and change all kinds of places in
my code; with a control variable, I have to change exactly ONE place, the declaration of
the variable!  So I would *NEVER* consider using GetDlgItem except in some very rare and
exotic situations (my claim is that if you are writing more than on GetDlgItem per year,
you are not using MFC correctly)
****
>
>
>> The difference is that GetDlgItem *directly* checks for the existence; GetSafeHwnd checks
>> *indirectly* through a robust path, but the flag test does not check for the actual
>> existence; it merely presumes that the flag is correct.  So the ONE purpose of GetDlgItem
>> is to verify that the window associated with that dialog item ID exists (oh yes, if it
>> does, you can safe the result and use it later...) and GetSafeHwnd verifies that both a
>> CWnd object exists and the HWND associated with it exsts (and yes, if you save that
>> result, you can use that for other purposes).  You are misconstruing the notion of "one
>> purpose" and confusing it with "a reflection of the truth is always equal to the truth".
>
>You make a valid point, and I would certainly do that if there were any reason to believe that the control might not be there (like
>if I were to remove some).  But if I do not remove any controls, then shouldn't a flag be reliable enough?
****
Because six months from now you may make that decision, or some future maintainer might
make that decision, and then the flag will lie, whereas GetSafeHwnd would always tell the
truth!
****
>
>More importantly, what I'm saying is that when you use just one of those to test the existance of a single control, then it is no
>safer than the flag.  For example doing something like this:
>
>  if (m_Edit.GetSafeHwnd!=NULL)
>    m_Edit.MoveWindow(blah);
>  if (m_Button.GetSafeHwnd!=NULL)
>    m_Button.MoveWindow(blah);
>  if (GetDlgItem(IDC_LIST)!=NULL)
>    GetDlgItem(IDC_LIST)->MoveWindow(blah);
>
>Would make sense and would be fine, but you and everyone else are doing this:
>
>  if (m_Edit.GetSafeHwnd!=NULL) {
>    m_Edit.MoveWindow(blah);
>    m_Button.MoveWindow(blah);
>    //GetDlgItem(IDC_LIST)->MoveWindow(blah);  //let's be extra safe on this one:
>    CWnd* list=GetDlgItem(IDC_LIST);
>    if (list!=NULL) list->MoveWindow(blah);
>  }
>
****
Well, the first form is correct, and the second form is wrong, so there's little point to
arguing about errors in erroneous code.  I always check EACH control before trying to
manipulate it.

And if you don't do this with buddy controls you are screwed anyway.  Creation order will
do you in.
****
>You're not testing for the existance of individual controls before using them, you're testing whether or not the dialog's controls
>have been created yet.  In this way, it's functionally identical to and no more reliable than the flag.  What if that one control
>that you tested no longer exists?  Then NONE of the controls are moved.
****
But you don't need a redundant test when there is already a perfectly fine test.  So why
duplicate information that is already present?
****
>
>
>> Yes, and that takes extra intellectual effort.  It is one more variable.  Complexity of
>> code is related to the number of variables and their lifetimes; the longer a variable
>> exists, the more chance it has to interact with other state.  Therefore, it is not just
>> the act of adding the variable, but the considerable baggage that comes along with that
>> addition.  The presumption, for example, that the variable always represents the truth.
>> The presumption that you have always maintained that relationship between the reflection
>> of the truth and the truth itself.  This is why modern languages always have scoped
>> variables; you can be certain that once you leave scope, the variable is gone, and
>> therefore can no longer interact with anything else in the program.  Apply the "global
>> variable considered harmful" analysis to class variables, recursively, to see that create
>> a variable like this violates the same principles that make global variables bad.
>>
>> Do not duplicate effort trying to represent images of the truth when the truth itself is
>> sufficient and easy to query.
>> ****
>
>Plus, with the ease and rapidity of exploits, it's probably better to have as few variables as possible.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/11/2006 6:29:42 PM
On Mon, 11 Sep 2006 14:29:42 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:

>Actually, I *do* advocate that every single control that is manipulated should be given a
>control variable.  Why not?  Does it ever make sense *not* to do this?  Why have two
>completely orthogonal mechanisms to handle this.  And the control variables work correctly
>if you decide to override SetWindowText, whereas the GetDlgItem approach will cause
>subclassed objects to fail completely.  Another failure mode.

If the control has been subclassed, that is, bound to an MFC control
variable, GetDlgItem will return a pointer to the CWnd part of that control
variable. You can call virtual functions through this pointer, and all will
be well. The problem is, SetWindowText is not virtual and thus cannot be
overridden. It can only be hidden, and it's a bad practice to hide public
member functions, because among other things, it can set up wrong
expectations concerning their behavior. They are not polymorphic, and you
should not expect them to act as if they are. It is a mistake to define
your own SetWindowText. If you handle this scenario properly, it won't
matter if you use GetDlgItem or not for a bound control, but it would be
pretty rare to use GetDlgItem on a bound control, so it's kind of a moot
point. See below for more.

>"Robust under maintenance"
>is critical.  Therefore, I should be able to subcass a CStatic, override SetWindowText,

Again, you cannot override SetWindowText. It is not possible.

>change the declaration, and recompile, and everything will work correctly.  E.g.,
>flicker-elimination:
>	void CMyStatic::SetWindowText(LPCTSTR s)
>	    {
>                     CString old;
>                     CStatic::GetWindowText(old);
>                     if(old == s)
>                        return;
>                     CStatic::SetWindowText(s);
>                   }
>
>If I had been doing this with GetDlgItem, I have to go and change all kinds of places in
>my code; with a control variable, I have to change exactly ONE place, the declaration of
>the variable!  So I would *NEVER* consider using GetDlgItem except in some very rare and
>exotic situations (my claim is that if you are writing more than on GetDlgItem per year,
>you are not using MFC correctly)

This is a false problem which exists only because this is the wrong way to
do this. It is through message maps that MFC achieves polymorphism for
messages, and the correct way to do this sort of thing is to handle the
Windows message, in this case, WM_SETTEXT. This way, you can call
SetWindowText through a pointer to any base in the class hierarchy, and you
can even use SendMessage(hWnd, WM_SETTEXT).

-- 
Doug Harrison
Visual C++ MVP
0
dsh (2499)
9/11/2006 7:14:20 PM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:saabg2t3m5m49fvpfbbfttjphqt21btlip@4ax.com...
> Actually, I *do* advocate that every single control that is manipulated should be given a
> control variable.  Why not?  Does it ever make sense *not* to do this?  Why have two
> completely orthogonal mechanisms to handle this.  And the control variables work correctly
> if you decide to override SetWindowText, whereas the GetDlgItem approach will cause
> subclassed objects to fail completely.  Another failure mode.  "Robust under maintenance"
> is critical.  Therefore, I should be able to subcass a CStatic, override SetWindowText,
> change the declaration, and recompile, and everything will work correctly.  E.g.,
> flicker-elimination:
> void CMyStatic::SetWindowText(LPCTSTR s)
>     {
>                      CString old;
>                      CStatic::GetWindowText(old);
>                      if(old == s)
>                         return;
>                      CStatic::SetWindowText(s);
>                    }
>
> If I had been doing this with GetDlgItem, I have to go and change all kinds of places in
> my code; with a control variable, I have to change exactly ONE place, the declaration of
> the variable!  So I would *NEVER* consider using GetDlgItem except in some very rare and
> exotic situations (my claim is that if you are writing more than on GetDlgItem per year,
> you are not using MFC correctly)

Yes, I've seen that line in your articles.  The old changing-a-variable argument is a fine point, and I'll have to try your
flicker-elimination technique.  :)

> >For example doing something like this:
> >
> >  if (m_Edit.GetSafeHwnd!=NULL)
> >    m_Edit.MoveWindow(blah);
> >  if (m_Button.GetSafeHwnd!=NULL)
> >    m_Button.MoveWindow(blah);
> >  if (GetDlgItem(IDC_LIST)!=NULL)
> >    GetDlgItem(IDC_LIST)->MoveWindow(blah);
> >
> >Would make sense and would be fine, but you and everyone else are doing this:
> >
> >  if (m_Edit.GetSafeHwnd!=NULL) {
> >    m_Edit.MoveWindow(blah);
> >    m_Button.MoveWindow(blah);
> >    //GetDlgItem(IDC_LIST)->MoveWindow(blah);  //let's be extra safe on this one:
> >    CWnd* list=GetDlgItem(IDC_LIST);
> >    if (list!=NULL) list->MoveWindow(blah);
> >  }
> >
> ****
> Well, the first form is correct, and the second form is wrong, so there's little point to
> arguing about errors in erroneous code.  I always check EACH control before trying to
> manipulate it.
>
> And if you don't do this with buddy controls you are screwed anyway.  Creation order will
> do you in.
> ****

That's what I mean, it makes perfect sense to do that if you check each one.  I don't know about your production code, but in your
articles, and everywhere else that mentions things like dynamically moving/sizing controls, they always do the latter.

> >You're not testing for the existance of individual controls before using them, you're testing whether or not the dialog's
controls
> >have been created yet.  In this way, it's functionally identical to and no more reliable than the flag.  What if that one control
> >that you tested no longer exists?  Then NONE of the controls are moved.
> ****
> But you don't need a redundant test when there is already a perfectly fine test.  So why
> duplicate information that is already present?
> ****

???  You just said that you test each control before manipulating it.  How then would it be redundant?  Testing for one control's
existance isn't duplicating a test for another control's existance.


-- 
Alec S.
news/alec->synetech/cjb/net


0
Alec
9/11/2006 9:25:09 PM
I agree.  The point is that since the control has already been bound, there's no need to
use GetDlgItem.  If it hasn't been bound, the result will be erroneous, e.g.,
	((CStatic *)GetDlgItem(IDC_WHATEVER))->SetIcon(...);
will always call the base class handler, so if I need to call CMyStatic, I have to find
all the GetDlgItem calls and change the ones that are for my class.  Whoops.  Maintenance
nightmare.

Since GetDlgItem uses CWnd::FromHandle to create a CWnd reference, then it will give a
pointer to the subclass, but because of the cast to a CStatic, that binding is also
ignored.  In either case, it opens up a nightmare of maintenance problems (which I've
found and fixed in far too many applications I've been given).  

In a sensible implementation of MFC, these *would* have been virtual methods, but we've
been crippled by bad design decisions; so the only way to override the behavior is by
hiding by writing a public method of the subclass.  This works.  It has worked for years.
I'm not sure why you say it can't be overridden.  It might not be tasteful, but it *does*
work, and it's the best we can do because we aren't given the virtual methods we should
have been given.

Because Microsoft erroneously elected to misimplement the base class calls, so instead of
passing the actual parameters you use to the base class, they reuse the global-variable
message values, it is very hard to handle WM_SETTEXT properly.  

For example, suppose I wanted to change the text from "100" to "1.00" (for example, a
buddy control that works in steps of 0.01.  The sensible implementation would be

void CMyEdit::OnSetText(LPCTSTR s)
    {
     CString val;
     val.Format(_T("%4.2g"), _ttof(s) / 100.0);
     CEdit::OnSetText(val);
    }

which would then follow, philosophically, the structure of message handlers.  But this
doesn't work because the agument passed is ignored.  Directly calling DefWindowProc
requires that you reassemble the parameters out of the function inputs.

If there's a "right" way to do this, I'd be interested, but I haven't yet found one that
meets all the necessary constraints.
					joe

On Mon, 11 Sep 2006 14:14:20 -0500, "Doug Harrison [MVP]" <dsh@mvps.org> wrote:

>On Mon, 11 Sep 2006 14:29:42 -0400, Joseph M. Newcomer
><newcomer@flounder.com> wrote:
>
>>Actually, I *do* advocate that every single control that is manipulated should be given a
>>control variable.  Why not?  Does it ever make sense *not* to do this?  Why have two
>>completely orthogonal mechanisms to handle this.  And the control variables work correctly
>>if you decide to override SetWindowText, whereas the GetDlgItem approach will cause
>>subclassed objects to fail completely.  Another failure mode.
>
>If the control has been subclassed, that is, bound to an MFC control
>variable, GetDlgItem will return a pointer to the CWnd part of that control
>variable. You can call virtual functions through this pointer, and all will
>be well. The problem is, SetWindowText is not virtual and thus cannot be
>overridden. It can only be hidden, and it's a bad practice to hide public
>member functions, because among other things, it can set up wrong
>expectations concerning their behavior. They are not polymorphic, and you
>should not expect them to act as if they are. It is a mistake to define
>your own SetWindowText. If you handle this scenario properly, it won't
>matter if you use GetDlgItem or not for a bound control, but it would be
>pretty rare to use GetDlgItem on a bound control, so it's kind of a moot
>point. See below for more.
>
>>"Robust under maintenance"
>>is critical.  Therefore, I should be able to subcass a CStatic, override SetWindowText,
>
>Again, you cannot override SetWindowText. It is not possible.
>
>>change the declaration, and recompile, and everything will work correctly.  E.g.,
>>flicker-elimination:
>>	void CMyStatic::SetWindowText(LPCTSTR s)
>>	    {
>>                     CString old;
>>                     CStatic::GetWindowText(old);
>>                     if(old == s)
>>                        return;
>>                     CStatic::SetWindowText(s);
>>                   }
>>
>>If I had been doing this with GetDlgItem, I have to go and change all kinds of places in
>>my code; with a control variable, I have to change exactly ONE place, the declaration of
>>the variable!  So I would *NEVER* consider using GetDlgItem except in some very rare and
>>exotic situations (my claim is that if you are writing more than on GetDlgItem per year,
>>you are not using MFC correctly)
>
>This is a false problem which exists only because this is the wrong way to
>do this. It is through message maps that MFC achieves polymorphism for
>messages, and the correct way to do this sort of thing is to handle the
>Windows message, in this case, WM_SETTEXT. This way, you can call
>SetWindowText through a pointer to any base in the class hierarchy, and you
>can even use SendMessage(hWnd, WM_SETTEXT).
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15979)
9/11/2006 11:27:58 PM
On Mon, 11 Sep 2006 19:27:58 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:

>I agree.  The point is that since the control has already been bound, there's no need to
>use GetDlgItem.  If it hasn't been bound, the result will be erroneous, e.g.,
>	((CStatic *)GetDlgItem(IDC_WHATEVER))->SetIcon(...);
>will always call the base class handler, so if I need to call CMyStatic, I have to find
>all the GetDlgItem calls and change the ones that are for my class.  Whoops.  Maintenance
>nightmare.

You won't need to change anything if you:

a. Handle WM_SETICON or STM_SETICON (whatever the right message is) in
CMyStatic instead of trying (and failing!) to override SetIcon.

b. Bind IDC_WHATEVER to a CMyStatic control variable, assuming it's derived
from CStatic.

Let me reiterate this point. This line will work as desired if you later
apply (a) and (b):

	((CStatic *)GetDlgItem(IDC_WHATEVER))->SetIcon(...);

By handling the Windows message in CMyStatic, the message map mechanism
will ensure this line calls CMyStatic::OnSetIcon for controls bound to
CMyStatic. This argument of yours against GetDlgItem is based on the
fallacy that it's valid for CMyStatic to define its own SetIcon, but it's
never valid to do this, and problems that result from this fundamental
mistake are due to that mistake and not the use of GetDlgItem.

On the other hand, if IDC_WHATEVER originally wasn't bound to an MFC
control, the existing code was performing a bogus cast, which more or less
works due to CStatic and CWnd having the same object layout. This is not to
say it's a good practice, because it isn't, and of course you're better
served by binding a control of the right type in the first place. However,
this doesn't make GetDlgItem "bad", because the "badness" occurs at the
more fundamental level of the bogus cast.

-- 
Doug Harrison
Visual C++ MVP
0
dsh (2499)
9/12/2006 12:50:52 AM
Reply:

Similar Artilces:

Posting old bills
I am setting up Money 2006 to tract income and expenses for a rental property, but I need to back date it to 1/1/2007. How do I enter bills and deposits made in the past? Thanks Go to the account register and enter the manually. Just click on the next blank transaction and go to town. You may want to make sure you are using Advanced Register. If there are subsequent transactions already in these accounts and you have balanced the accounts to statements--as though these transactions were already entered--then you will have to adjust account beginning balances and/or Account Adjustment...

Windows Live Mail Error ID: 0x800CCC0E 08-31-10
The connection to the server has failed. Subject '' Server: 'smtp-out.uottawa.ca' Windows Live Mail Error ID: 0x800CCC0E Protocol: SMTP Port: 25 Secure(SSL): No Socket Error: 10060 I have tried changing the outgoing port to 587 and ticking the box underneath to no avail. My incoming server is IMAP, the default port is 143. Please help So you _can_ receive, but not send? "Sepideh" <Sepideh@discussions.microsoft.com> wrote in message news:FFCB1139-FC43-4680-BBA3-4BE39DD7BE9D@microsoft.com... > The connection to the server has failed. &...

links fail: Outlook Express 6/Windows XP
When I boot up and start Outlook Express, a double click on any link fails. Nothing happens. After <cntl><alt><dle> brings up prgram screen, I kill all IE explorer programs. After that, the links will work. Is something clobbered or something strange going on at startup?? How can I fix??? Ask in an Outlook Express forum. This is an Microsoft Office Outlook forum. Outlook Express is family of Internet Explorer and Outlook of the Office family. Here is the link for the right forum http://communities.microsoft.com/newsgroups/default.asp?icp=InternetExplorer Good Luck! --...

* OWA... (Third Post)
Microsoft? If you're concerned about security then you should respond to this question. We cannot make this OWA server available on the Internet without applying the latest SP and critical updates. =========================== Our OWA Exchange 5.5 server (Windows NT Server) recently died and we replaced it with a Windows 2000 Server. We installed Exchange 5.5 OWA then applied Exchange SP4. Everything was working until we apply Windows 2000 SP4. Everytime we logon we get "OWA was unable to get to your inbox" error. As soon as we un-installed Windows 2000 SP4, OWA wo...

Add fields of Scroll window in VBA ?
Hi, I am able to add other fields in form but I am unable to add fields of scrolling window in VBA. Thanks in advance -- Aditya While I'm happy you have things solved, I don't believe what you have below is the correct solution. You should be able to add any fields of any scrolling window to your project. I'm darn sure that is the case because I've used VBA to pull values from lookup windows before and those are of course browse only. My only note for scrolling windows is you have to make sure the window is "filled" before you try to add it to vba. ...

Dialog Form Question
Hi I want to automatically create a member in the linked class for each control that I put on the Dialog Resource Is that possible and how? Thank you No way to do this automatically, but you can do it control by control by right clicking and selecting Add Variable or Add Event Handler. I mostly use cut and paste these days and just add them manually. It doesn't take much time if you use one for a template then just copy it. Tom "S Shulman" <smshulman@hotmail.com> wrote in message news:OSFxkPv2FHA.636@TK2MSFTNGP10.phx.gbl... > Hi > > I want to automa...

opening windows mail
I can open Windows Email by just clicking on the email icon under the start menu w/o needing a password on MY pc, but how can I access my emails from a different computer? Appreciate some help. It depends on what protocol your email account(s) use. Webmail accounts ( Hotmail/Live, Yahoo, Gmail, etc.) are designed to be accessed from any computer using a web browser. Messages stay on the server. IMAP accounts (AOL, Gmail, etc.) are designed to be accessed from any computer using a client email program (Windows Mail, Outlook, Thunderbird, etc.). Messages stay on the serve...

Add windows Common Dialogs
Hello Is there any way to add Windows common dialogs in MFC Dialogs (like add button in Dialogs)? Thanks R.Selvam selvamselvam@hotmail.com Take a look here. http://www.codeguru.com/dialog/index.shtml Scroll down to the middle of the page under the heading Common Dialogs Ali R. "R.Selvam" <selvamselvam@hotmail.com> wrote in message news:07dd01c3c8a9$dea2b820$a601280a@phx.gbl... > Hello > > Is there any way to add Windows common dialogs in MFC > Dialogs (like add button in Dialogs)? > > Thanks > R.Selvam > selvamselvam@hotmail.com > > ...

To the sender of the MI5 posts
I am not sure if you read responses or (like most other spammers) just see the web as a place where you are free to say whatever you want without fear of contradiction. Who knows? Either way - this section of this site is site is specifically here so that anyone with a comment, question, point to rise, etc regarding access databases can post with the knowledge that other likeminded people may read their post. It is not here as a general forum to discuss other matters. I have no doubt that if you are blocked from posting you will see this as yet another indication that MI5 is after yo...

Windows 7 Excel 7
Over the last week while in a spreadsheet, excel has just arbitrarily begun to restore/repair a file. This has happened a couple times, no power failures or surges... A converter had been installed, the system went back to a restore but it has happened again. I then have to save as another file name. ...

Q: How to prevent help from moving my windows around?
I'm using Outlook 2000, on Microsoft Windows 2000 [Version 5.00.2195], and also the Visual Basic environment for making macros for outlook. When I open the visual basic help then the help system rearranges my basic and outlook windows. And then if I move the help windows then the outlook windows and visual basic windows also rearange themselves on my screen. Does anyone know how to stop this from happening, and if so, how? Thanks, malcolm. Do you have the help window undocked? drag it away from the screen edge to undock it. -- Diane Poremsky [MVP - Outlook] Author, Teach Yourself...

What's the difference between Cross-posting and Multi-posting
And thanks for the discussion earlier... although the rudeness was unneeded. Sign me, A New User (and learning from you all) rochgal, you wrote on Thu, 22 Sep 2005 14:53:03 -0700: > What's the difference between Cross-posting and Multi-posting Cross-posting = You send one posting to several newsgroups. Multi-posting = You send several postings (with the same content) to several newsgroups. -- Best Regards Christian Goeller Some misspellings, grammatical or linguistical mistakes found? All corrections would be appreciated! ...

Getting a handle to the contents of a window's contents
Hi everyone, What Windows API should I use if I wanted to access the contents of a window's contents. For instance, if I were to open a file in Word, or browse a site using Explorer, how would I parse the text that I am viewing? TIA Paul > What Windows API should I use if I wanted to access the contents of a > window's contents. For instance, if I were to open a file in Word, or > browse a site using Explorer, how would I parse the text that I am > viewing? > It all depends upon the control you want the contents from. GetWindowText etc will work for some. Keep in mi...

Post to GL
Hello I am having a problem with a setting within Great Plains 8.0 service pack 2. I have posting setup to only allow posting from the batch level for Inventory. But when you go into Inventory Batches the check box for post to gl is not marked. If I have it setup in posting to post to the gl shouldn't this check box be marked in inventory batches? -- Thanks, Brian Apples and oranges. The post to GL checkbox on the inventory batch window tells the system whether an IV transaction will post at all. The posting settings in tools --> setup --> posting tell the system w...

Intrastat posting issue
We are a UK company using intrastat. At the moment we cannot post invoices directly (thru) to the General ledger because we are getting an error saying that the 'intratsat information is missing'. When we click on an invoice that won't post in the Sales Transaction Entry screen, and click on the blue EC flag box, all the intrastat data is there and correct. Then when we post it goes through to the GL correctly. It seems that it will only post to the GL if every single line is checked (via the Blue EC flag) on the sales invoice regardless of the fact that all the date is alr...

Possible to have MFC Ctreectrl meet Vista Aero theme by developing in Windows XP?
Hi All, I have an application including MFC tree-view control created by CTreeCtrl class, this applicaiton is developed in Windows XP, and now i need to run this application on Vista, so is it possible to have MFC Ctreectrl meet Vista Aero theme by developing it in Windows XP? that means the tree-view control should meet the following standards: The expanded tree items exceed what the container's client area is capable of displaying, a scroll bar appears for the XP style controls. However, for the Vista Aero theme a scroll bar will not appear. In Vista, when the user clicks on tree items ...

Preventing Windows Live Mail from signing in automatically
Is there a way to prevent Windows Live Mail from signing in automatically when I click on it?. I like the program but when I click on it, it simultaniously prompts me for a password AND opens up my email account and therefore displaying all my emails and everything else I have on there. Is there a way to stop that from happening and just have it open up my email AFTER I enter my password?. Thanks. Basic answer is NO. Contrary to what a reasonable person might assume, the sign-in prompt when starting WLM has nothing to do with being able to send and receive mail or even to get ...

Access 2002 bug: "dynamic" forms problem
There was no respond to my original post in microsoft.public.access.forms (May 5th 2007) about a fortnight so I try it here... ��������������������������������� A while ago we had a discussion about A2002 (sub)form which changes dynamically from code (hide/unhide controls, change subfom's width, etc.). There's a problem if I make some changes in code when the form is open: if I save changes, A2002 saves controls positions & subform's size as well. This is a BIG A2002 BUG and it's really annoying. Why Access forms don't behave as Visual Basic forms? I don't want Acc...

Problems with Windows Live Mail (current version) memory usage
I told Windows Live Mail on my 64-bit desktop to search an entire newsgroups server account for posts with "cheap" in the subject line, and it took about half an hour to get past the startup of the Find Message function. It finally found 999 items within the approximately 140 newsgroups I I subscribe to from that server. I'd estimate that I've already downloaded around 8,000,000 newsgroups posts now in the WLM database, at least according to the number of items found during a Norton Internet Security 2010 scan. No other programs except Windows Task Manager were ...

where is my post??
twice now I have typed up my post & sent it. So where is it? On Wed, 18 Jul 2007 08:41:36 -0700, Stapes <steve.staple@gmail.com> wrote: >twice now I have typed up my post & sent it. So where is it? On Google Groups: 1184773041.958329.270430@e16g2000pri.googlegroups.com Google's been having some problems lately, maybe it's temporarily unavailable. John W. Vinson [MVP] You mean the multiple posts with subject "Cancel = true"? I see 3 of them, and Allen Browne's already provided an answer. -- Doug Steele, Microsoft Access MVP http://I...

How can I undo text scaling in New mail window
I am using Outlook 2003, and when I try to compose a new mail the text that is displayed is HUGE. I want it as it used to be where the text is about size 10, unaffected by whether my mail-window is large or not. I have tried changing it to web layout, and this seems to do the trick, but that only works for one mail, and when I create a new one I have to do it all over again. There must be a way around this? Can anyone help? Stian ...

My post not posted!
A couple of times when I've posted a reply to a recent post (same day), and later tried to view it, I found the header with a line drawn through it, and the following in the message body view pane: Message is no longer available on the server Windows Live Mail is unable to retrieve the requested message because the server no longer has the message available. -------------------------------------------------------------------------------- News servers regularly expire articles as they get older to make space available for newer articles. IMAP servers can be accessed by multip...

Cannot send newsgroup post with an attachment
I can send and receive posts using Outlook Express 6 newsgroups. I do not use html. When I send a post that has an attachment, e.g. a 160kB jpg that post never shows up as having been sent. How can I fix this? regards, "nobody" I can't speak for others, but msnews has a 100KB limit. If I have a need to post a graphic, I upload it to TinyPic and post the link to it. TinyPic: http://tinypic.com/ -- Bruce Hagen MS-MVP [Mail] Imperial Beach, CA "news.microsoft.com" <nobody@nowhere.com> wrote in message ...

Windows Mail
UNABLE TO SEND E-MAILS You haven't given us much to go on. Do you get an error message when you try to send? If so,=20 right-click on your error message, copy, then paste it into a reply = here. We can't do much troubleshooting without the complete error message.=20 --=20 Gary VanderMolen, Microsoft MVP (Mail) http://mvp.support.microsoft.com/default.aspx/profile/vandermolen "John Machin" <jgmac120@embarqmail.com> wrote in message = news:%23O0SNXdeKHA.2164@TK2MSFTNGP02.phx.gbl... > UNABLE TO SEND E-MAILS ...

Dragging Email Messages In Windows Folders
Hi, Some time back I used to manage my emails in windows folders by selecting them all, dragging them from outlook (inbox) to a windows folder. I had emails with similiar subjects. So the Email files (in message format) were created by outlook like filename = subject of message + autogenerated number (in case of multiple messages with same subject) Now after this new installation. When i repeat the same procedure... Windows gives error "This folder already contains a file named "subject of message" Would you like to replace the existing file with another one? So the list of ...