Prev: cannot execute C preprocessor cl.exe
Next: Expand max. status bar pane text length?
From: Oliver Regenfelder on 14 May 2010 16:10
Hello,

Joseph M. Newcomer wrote:
> Some years ago, I realized that the secret of being a succe3ssful programmer is one of
> those things we are always told is a Bad Thing: pure laziness! When I tried to use DBUs,
> I had to *work*, and the results weren't always what were expected. Once I relized I
> could getbetter effects with less work, I went that direction. In generaly, I try to find
> the "lazy" solution to a problem, because it is usually simpler.
>
> So I let the dialog system resize my static frame in accordance with its built-in rules,
> so I don't have to simulate them, then I just use the results. In general, I try to reuse
> existing mechanisms instead of trying to simulate them. Laziness will buy you a lot of
> leverage.

I thought windows would provide better support to work with DBUs
directly inside the MFC. But that seems to lack a bit. I had hoped
for something like direct conversions routines from/to DBUs but they
are not available in a CWnd even though this is embedded in a Dialog.

> ***
> GetClientRect will be important; it already compensates for the scroll bars you might
> have.

Thanks for the Info.

> Note the use of the SetWindowPos to get the Z-order correct, so the control has the right
> tab position. That was one of the fine points of the trick.

You must have seen my puzzled look, while I was wondering why I have to
move the window after having it already properly positioned (in terms of
x/y coordinates).

Thanks,

Oliver
From: Joseph M. Newcomer on 18 May 2010 12:14
See below...
On Fri, 14 May 2010 22:10:42 +0200, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>Joseph M. Newcomer wrote:
>> Some years ago, I realized that the secret of being a succe3ssful programmer is one of
>> those things we are always told is a Bad Thing: pure laziness! When I tried to use DBUs,
>> I had to *work*, and the results weren't always what were expected. Once I relized I
>> could getbetter effects with less work, I went that direction. In generaly, I try to find
>> the "lazy" solution to a problem, because it is usually simpler.
>>
>> So I let the dialog system resize my static frame in accordance with its built-in rules,
>> so I don't have to simulate them, then I just use the results. In general, I try to reuse
>> existing mechanisms instead of trying to simulate them. Laziness will buy you a lot of
>> leverage.
>
>I thought windows would provide better support to work with DBUs
>directly inside the MFC. But that seems to lack a bit. I had hoped
>for something like direct conversions routines from/to DBUs but they
>are not available in a CWnd even though this is embedded in a Dialog.
****
I made this same discovery around 1990 and gave up on DBUs at runtime.
****
>
>> ***
>> GetClientRect will be important; it already compensates for the scroll bars you might
>> have.
>
>Thanks for the Info.
>
>> Note the use of the SetWindowPos to get the Z-order correct, so the control has the right
>> tab position. That was one of the fine points of the trick.
>
>You must have seen my puzzled look, while I was wondering why I have to
>move the window after having it already properly positioned (in terms of
>x/y coordinates).
****
Physical position of a child window has nothing to do with its tab order, which is
determined by what we call the "Z-order". All controls form a linked list of controls,
from dlg_or_formview.GetWindow(GW_CHILD) and proceeding through ->GetWindow(GW_HWNDNEXT).
When you call Create on a window, it is placed at the end of the list, that is, last in
the Z-order. If you want the tab key to take you there, you have to put it in the right
position. What I do is put my static frame in the desired tab order (even though a static
window can't be tabbed to) and then move the newly-created window to follow it, and then
when I delete the static frame, my new control is in the right position in the Z-order.

for(CWnd * wnd = GetWindow(GW_CHILD); wnd != NULL; wnd = wnd->GetWindow(GW_HWNDNEXT))

will iterate over the child windows; this is the same linked list that the tab key follows
(GetNextTabCtrl, for example, if I've remembered the name correctly).
joe
****
>
>Thanks,
>
>Oliver
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  | 
Pages: 1 2
Prev: cannot execute C preprocessor cl.exe
Next: Expand max. status bar pane text length?