Show child window without making parent inactive

[Matthew Cromer]

I want to pop up a child window without making the parent window inactive.
Yet I also want focus to pass to the child window.

Is this possible?

The application is a small pop-up palette for the user to select a date when
a special button on a textbox is pressed.

Matthew Cromer

[Matthew Cromer]

"Jonathan Wood" <jwood@softcircuits.com> wrote:
>As long as the child window is really a child window, then the parent should
>automatically retain focus. What is the relationship between these two
>windows and how are you setting that up?

Consider a combo box. When you click on the "handle", the list drops down.

I want exactly the same kind of relationship. The only difference is that
I am dropping down the monthview control from a custom textbox. However,
I want focus to go to the monthview control so the user can use the arrow
keys to choose the month, etc.

I suppose I can hack out a way to pass the cursor keys to the monthview while
retaining focus in the parent textbox.

The problem I have is that the monthview is put on another form so that it
doesn't have to live within the client area of the existing form. Just like
a combo listbox can extend off the form where it drops down.

Anyway, I hope this makes at least some sense.

Matthew

[Matthew Cromer]

"Jonathan Wood" <jwood@softcircuits.com> wrote:
>As long as the child window is really a child window, then the parent should
>automatically retain focus. What is the relationship between these two
>windows and how are you setting that up?

Consider a combo box. When you click on the "handle", the list drops down.

I want exactly the same kind of relationship. The only difference is that
I am dropping down the monthview control from a custom textbox. However,
I want focus to go to the monthview control so the user can use the arrow
keys to choose the month, etc.

I suppose I can hack out a way to pass the cursor keys to the monthview while
retaining focus in the parent textbox.

The problem I have is that the monthview is put on another form so that it
doesn't have to live within the client area of the existing form. Just like
a combo listbox can extend off the form where it drops down.

Anyway, I hope this makes at least some sense.

Matthew

[Jonathan Wood]

As long as the child window is really a child window, then the parent should
automatically retain focus. What is the relationship between these two
windows and how are you setting that up?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Matthew Cromer" <matthew@sdaconsulting.com> wrote in message
news:39be275a@news.devx.com...
>
> I want to pop up a child window without making the parent window inactive.
> Yet I also want focus to pass to the child window.
>
> Is this possible?
>
> The application is a small pop-up palette for the user to select a date
when
> a special button on a textbox is pressed.
>
> Matthew Cromer

[Jonathan Wood]

As long as the child window is really a child window, then the parent should
automatically retain focus. What is the relationship between these two
windows and how are you setting that up?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Matthew Cromer" <matthew@sdaconsulting.com> wrote in message
news:39be275a@news.devx.com...
>
> I want to pop up a child window without making the parent window inactive.
> Yet I also want focus to pass to the child window.
>
> Is this possible?
>
> The application is a small pop-up palette for the user to select a date
when
> a special button on a textbox is pressed.
>
> Matthew Cromer

[Matthew Cromer]

"Jonathan Wood" <jwood@softcircuits.com> wrote:
>Matthew,
>
>> Consider a combo box. When you click on the "handle", the list drops
>down.
>
>This is sometimes referred to as an "owned window." A combo box drop down
>window is not really a child window because it needs to extend outside of
>its "parent.">

OK, thanks for the clarification!

>Usually when I do this, I just allow the owned window to get the focus.
The
>only downside I saw was that the parent's title bar changed color to
>indicate it no longer had the focus.

Exactly. That's the only drawback I am having so far.

>
>I once implemented a dropdown calendar in C++ and, in that case, I did not
>allow the dropdown window to receive the focus. Instead, the control
>forwarded keystroke messages to the dropdown window when the dropdown was
>visible. Since I just forwarded all keystroke messages in this case, it
>wasn't that complex (although the entire control consisted of quite a bit
of
>code). The only other time I've seen this is with toolbar windows and I
>believe they also prevent themselves from getting focus and just custom
>paint their captions to make them look like they have the focus. This would
>be easy to verify with Spy++ but I'm pretty confident without testing it.


OK. So I have to hack around if I want that behavior.

Somehow a grey title bar doesn't seem that big a deal (I have a bunch of
functional code to write before I worry about this kind of minor UI glitch)

Thanks for your info!

Matthew Cromer

[Matthew Cromer]

"Jonathan Wood" <jwood@softcircuits.com> wrote:
>Matthew,
>
>> Consider a combo box. When you click on the "handle", the list drops
>down.
>
>This is sometimes referred to as an "owned window." A combo box drop down
>window is not really a child window because it needs to extend outside of
>its "parent.">

OK, thanks for the clarification!

>Usually when I do this, I just allow the owned window to get the focus.
The
>only downside I saw was that the parent's title bar changed color to
>indicate it no longer had the focus.

Exactly. That's the only drawback I am having so far.

>
>I once implemented a dropdown calendar in C++ and, in that case, I did not
>allow the dropdown window to receive the focus. Instead, the control
>forwarded keystroke messages to the dropdown window when the dropdown was
>visible. Since I just forwarded all keystroke messages in this case, it
>wasn't that complex (although the entire control consisted of quite a bit
of
>code). The only other time I've seen this is with toolbar windows and I
>believe they also prevent themselves from getting focus and just custom
>paint their captions to make them look like they have the focus. This would
>be easy to verify with Spy++ but I'm pretty confident without testing it.


OK. So I have to hack around if I want that behavior.

Somehow a grey title bar doesn't seem that big a deal (I have a bunch of
functional code to write before I worry about this kind of minor UI glitch)

Thanks for your info!

Matthew Cromer

[Jonathan Wood]

Matthew,

> Consider a combo box. When you click on the "handle", the list drops
down.

This is sometimes referred to as an "owned window." A combo box drop down
window is not really a child window because it needs to extend outside of
its "parent."

> I want exactly the same kind of relationship. The only difference is that
> I am dropping down the monthview control from a custom textbox. However,
> I want focus to go to the monthview control so the user can use the arrow
> keys to choose the month, etc.

I don't believe there's any way to automatically have a window that is not a
child window get the focus while the parent still retains the focus.

Usually when I do this, I just allow the owned window to get the focus. The
only downside I saw was that the parent's title bar changed color to
indicate it no longer had the focus.

I once implemented a dropdown calendar in C++ and, in that case, I did not
allow the dropdown window to receive the focus. Instead, the control
forwarded keystroke messages to the dropdown window when the dropdown was
visible. Since I just forwarded all keystroke messages in this case, it
wasn't that complex (although the entire control consisted of quite a bit of
code). The only other time I've seen this is with toolbar windows and I
believe they also prevent themselves from getting focus and just custom
paint their captions to make them look like they have the focus. This would
be easy to verify with Spy++ but I'm pretty confident without testing it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Matthew,

> Consider a combo box. When you click on the "handle", the list drops
down.

This is sometimes referred to as an "owned window." A combo box drop down
window is not really a child window because it needs to extend outside of
its "parent."

> I want exactly the same kind of relationship. The only difference is that
> I am dropping down the monthview control from a custom textbox. However,
> I want focus to go to the monthview control so the user can use the arrow
> keys to choose the month, etc.

I don't believe there's any way to automatically have a window that is not a
child window get the focus while the parent still retains the focus.

Usually when I do this, I just allow the owned window to get the focus. The
only downside I saw was that the parent's title bar changed color to
indicate it no longer had the focus.

I once implemented a dropdown calendar in C++ and, in that case, I did not
allow the dropdown window to receive the focus. Instead, the control
forwarded keystroke messages to the dropdown window when the dropdown was
visible. Since I just forwarded all keystroke messages in this case, it
wasn't that complex (although the entire control consisted of quite a bit of
code). The only other time I've seen this is with toolbar windows and I
believe they also prevent themselves from getting focus and just custom
paint their captions to make them look like they have the focus. This would
be easy to verify with Spy++ but I'm pretty confident without testing it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Michael Culley]

Matthew,

I did a bit of work trying to solve this problem. I came up with a solution
that wasn't perfect but it was only programatically imperfect - it looked
fine to the user.

All you need to do is subclass the main window and catch, from memory, the
WM_NCACTIVATE message and kill it and return a true value. This way the form
loses focus without looking like it has. While you are at it you can catch
the app lost focus message (WM_???) and hide the drop down like a combobox.

The other method was just sending the WM_NCACTIVATE message to the window
to reactivate the titlebar, but I found this caused a flicker.

If you need a subclass component I believe there is one avaiable at www.sdaconsulting.com
hehe

Michael Culley

"Matthew Cromer" <matthew@sdaconsulting.com> wrote:
>
>"Jonathan Wood" <jwood@softcircuits.com> wrote:
>>Matthew,
>>
>>> Consider a combo box. When you click on the "handle", the list drops
>>down.
>>
>>This is sometimes referred to as an "owned window." A combo box drop down
>>window is not really a child window because it needs to extend outside
of
>>its "parent.">
>
>OK, thanks for the clarification!
>
>>Usually when I do this, I just allow the owned window to get the focus.
>The
>>only downside I saw was that the parent's title bar changed color to
>>indicate it no longer had the focus.
>
>Exactly. That's the only drawback I am having so far.
>
>>
>>I once implemented a dropdown calendar in C++ and, in that case, I did
not
>>allow the dropdown window to receive the focus. Instead, the control
>>forwarded keystroke messages to the dropdown window when the dropdown was
>>visible. Since I just forwarded all keystroke messages in this case, it
>>wasn't that complex (although the entire control consisted of quite a bit
>of
>>code). The only other time I've seen this is with toolbar windows and I
>>believe they also prevent themselves from getting focus and just custom
>>paint their captions to make them look like they have the focus. This would
>>be easy to verify with Spy++ but I'm pretty confident without testing it.
>
>
>OK. So I have to hack around if I want that behavior.
>
>Somehow a grey title bar doesn't seem that big a deal (I have a bunch of
>functional code to write before I worry about this kind of minor UI glitch)
>
>Thanks for your info!
>
>Matthew Cromer

[Michael Culley]

Matthew,

I did a bit of work trying to solve this problem. I came up with a solution
that wasn't perfect but it was only programatically imperfect - it looked
fine to the user.

All you need to do is subclass the main window and catch, from memory, the
WM_NCACTIVATE message and kill it and return a true value. This way the form
loses focus without looking like it has. While you are at it you can catch
the app lost focus message (WM_???) and hide the drop down like a combobox.

The other method was just sending the WM_NCACTIVATE message to the window
to reactivate the titlebar, but I found this caused a flicker.

If you need a subclass component I believe there is one avaiable at www.sdaconsulting.com
hehe

Michael Culley

"Matthew Cromer" <matthew@sdaconsulting.com> wrote:
>
>"Jonathan Wood" <jwood@softcircuits.com> wrote:
>>Matthew,
>>
>>> Consider a combo box. When you click on the "handle", the list drops
>>down.
>>
>>This is sometimes referred to as an "owned window." A combo box drop down
>>window is not really a child window because it needs to extend outside
of
>>its "parent.">
>
>OK, thanks for the clarification!
>
>>Usually when I do this, I just allow the owned window to get the focus.
>The
>>only downside I saw was that the parent's title bar changed color to
>>indicate it no longer had the focus.
>
>Exactly. That's the only drawback I am having so far.
>
>>
>>I once implemented a dropdown calendar in C++ and, in that case, I did
not
>>allow the dropdown window to receive the focus. Instead, the control
>>forwarded keystroke messages to the dropdown window when the dropdown was
>>visible. Since I just forwarded all keystroke messages in this case, it
>>wasn't that complex (although the entire control consisted of quite a bit
>of
>>code). The only other time I've seen this is with toolbar windows and I
>>believe they also prevent themselves from getting focus and just custom
>>paint their captions to make them look like they have the focus. This would
>>be easy to verify with Spy++ but I'm pretty confident without testing it.
>
>
>OK. So I have to hack around if I want that behavior.
>
>Somehow a grey title bar doesn't seem that big a deal (I have a bunch of
>functional code to write before I worry about this kind of minor UI glitch)
>
>Thanks for your info!
>
>Matthew Cromer