Prev: How to: optional CString parameter
Next: screen show and print : difference
From: David Wilkinson on 5 May 2008 11:35
David Ching wrote:
> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
> news:4k5u14hp9sfd8kohdi6rreg8h6uhijj7l7(a)4ax.com...
>>> Thanks!! Will that display the character in the next window without
>>> the user having to re-type it?
>>>
>> Yes, because it moves to the next edit control when it discovers the
>> current edit control
>> is now filled, rather than using EN_MAXTEXT, which tells you that you
>> can't put the
>> current character in it.
>> joe
>>
>
> How does that work? EN_CHANGE just tells you when the edit box is (or is
> about to be) changed. It doesn't move the focus to the next dialog control,
> nor type the character into it. I would think the dialog handler would need
> to do that.

David:

Isn't that what Joe said? Change the focus in the EN_CHANGE handler. Even so,
I'm surprised it works.

--
David Wilkinson
Visual C++ MVP
From: Joseph M. Newcomer on 5 May 2008 15:14
ON_CONTROL_RANGE(EN_CHANGE, IDC_FIELD1, IDC_FIELD5, OnChangeKeyField)

void CMyDialog::OnEnChangeKeyField(UINT id)
{
CString s;
CWnd * wnd = GetDlgItem(id);
wnd->GetWindowText(s);
if(s.GetLength() == MAX_KEY_COMPONENT)
{ /* filled */
CWnd * next = GetNextDlgTabItem(wnd);
next->SetFocus();
} /* filled */
}

MAX_KEY_COMPONENT was set to 4 in our case, and there were 20 characters in the key (5
fields of 4 characters each). The edit control was subclassed to only allow [A-Z0-9\b] as
valid input characters, and was set to uppercase translation so lowercase letters were
translated to uppercase.

The tab order was [field1] [field2][field3][field4][field5][ok]

so the last GetNextDlgTabItem went to the OK button
joe


On Mon, 5 May 2008 07:37:14 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote:

>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>news:4k5u14hp9sfd8kohdi6rreg8h6uhijj7l7(a)4ax.com...
>>>Thanks!! Will that display the character in the next window without
>>>the user having to re-type it?
>>>
>> Yes, because it moves to the next edit control when it discovers the
>> current edit control
>> is now filled, rather than using EN_MAXTEXT, which tells you that you
>> can't put the
>> current character in it.
>> joe
>>
>
>How does that work? EN_CHANGE just tells you when the edit box is (or is
>about to be) changed. It doesn't move the focus to the next dialog control,
>nor type the character into it. I would think the dialog handler would need
>to do that.
>
>-- David
>
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 5 May 2008 16:57
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:c0mu14t6hb313a5u4771ua88jrt1j8vr70(a)4ax.com...
> ON_CONTROL_RANGE(EN_CHANGE, IDC_FIELD1, IDC_FIELD5, OnChangeKeyField)
>
> void CMyDialog::OnEnChangeKeyField(UINT id)
> {
> CString s;
> CWnd * wnd = GetDlgItem(id);
> wnd->GetWindowText(s);
> if(s.GetLength() == MAX_KEY_COMPONENT)
> { /* filled */
> CWnd * next = GetNextDlgTabItem(wnd);
> next->SetFocus();
> } /* filled */
> }
>
> MAX_KEY_COMPONENT was set to 4 in our case, and there were 20 characters
> in the key (5
> fields of 4 characters each). The edit control was subclassed to only
> allow [A-Z0-9\b] as
> valid input characters, and was set to uppercase translation so lowercase
> letters were
> translated to uppercase.
>

Yes, but this only solves half the problem. It changes the focus to the
next control. It doesn't erase the last character and re-type it into the
next control. The way the problem was initially phrased, that is how it
should work, although I see you attempt to achieve the same effect by moving
the focus on the character before the overflow. That's the way I do it
also, but that's not what the OP asked.

-- David


From: David Scambler on 5 May 2008 22:53
"David Ching" <dc(a)remove-this.dcsoft.com> wrote in
news:wyKTj.15754$2g1.788(a)nlpi068.nbdc.sbc.com:

> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
> news:c0mu14t6hb313a5u4771ua88jrt1j8vr70(a)4ax.com...
>> ON_CONTROL_RANGE(EN_CHANGE, IDC_FIELD1, IDC_FIELD5, OnChangeKeyField)
>>
>> void CMyDialog::OnEnChangeKeyField(UINT id)
>> {
>> CString s;
>> CWnd * wnd = GetDlgItem(id);
>> wnd->GetWindowText(s);
>> if(s.GetLength() == MAX_KEY_COMPONENT)
>> { /* filled */
>> CWnd * next = GetNextDlgTabItem(wnd);
>> next->SetFocus();
>> } /* filled */
>> }
>>
>> MAX_KEY_COMPONENT was set to 4 in our case, and there were 20
>> characters in the key (5
>> fields of 4 characters each). The edit control was subclassed to
>> only allow [A-Z0-9\b] as
>> valid input characters, and was set to uppercase translation so
>> lowercase letters were
>> translated to uppercase.
>>
>
> Yes, but this only solves half the problem. It changes the focus to
> the next control. It doesn't erase the last character and re-type it
> into the next control. The way the problem was initially phrased,
> that is how it should work, although I see you attempt to achieve the
> same effect by moving the focus on the character before the overflow.
> That's the way I do it also, but that's not what the OP asked.

Hmmm - seems even messier than that. What if the last character was not
typed at the end of the field but was inserted at the start. What if a
paste inserted a number of characters. Joe's
(s.GetLength() == MAX_KEY_COMPONENT)
will not compare true if the result of the paste exceeds
MAX_KEY_COMPONENT.


>
> -- David
>
>
>

From: folderann on 5 May 2008 23:09
On 06 May 2008 02:53:23 GMT, David Scambler <Your_email(a)email.net>
wrote:

>"David Ching" <dc(a)remove-this.dcsoft.com> wrote in
>news:wyKTj.15754$2g1.788(a)nlpi068.nbdc.sbc.com:
>
>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>> news:c0mu14t6hb313a5u4771ua88jrt1j8vr70(a)4ax.com...
>>> ON_CONTROL_RANGE(EN_CHANGE, IDC_FIELD1, IDC_FIELD5, OnChangeKeyField)
>>>
>>> void CMyDialog::OnEnChangeKeyField(UINT id)
>>> {
>>> CString s;
>>> CWnd * wnd = GetDlgItem(id);
>>> wnd->GetWindowText(s);
>>> if(s.GetLength() == MAX_KEY_COMPONENT)
>>> { /* filled */
>>> CWnd * next = GetNextDlgTabItem(wnd);
>>> next->SetFocus();
>>> } /* filled */
>>> }
>>>
>>> MAX_KEY_COMPONENT was set to 4 in our case, and there were 20
>>> characters in the key (5
>>> fields of 4 characters each). The edit control was subclassed to
>>> only allow [A-Z0-9\b] as
>>> valid input characters, and was set to uppercase translation so
>>> lowercase letters were
>>> translated to uppercase.
>>>
>>
>> Yes, but this only solves half the problem. It changes the focus to
>> the next control. It doesn't erase the last character and re-type it
>> into the next control. The way the problem was initially phrased,
>> that is how it should work, although I see you attempt to achieve the
>> same effect by moving the focus on the character before the overflow.
>> That's the way I do it also, but that's not what the OP asked.
>
>Hmmm - seems even messier than that. What if the last character was not
>typed at the end of the field but was inserted at the start. What if a
>paste inserted a number of characters. Joe's
> (s.GetLength() == MAX_KEY_COMPONENT)
>will not compare true if the result of the paste exceeds
>MAX_KEY_COMPONENT.
>
>
>>
>> -- David
>>
>>
>>
Thanks to you all I'm watching and learning. It occurs to me that
Microsoft does what I'm trying to accomplish in the applet where the
user enter a XP or Vista key. When the first five characters are
entered the focus automatically moves to the next edit control BEFORE
the next character is keyed in. It's my (ignorant) sense that would
be programmatically more simple than waiting until AFTER the sixth
character is entered.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How to: optional CString parameter
Next: screen show and print : difference