Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How do I show or hide a list box.

512 views
Skip to first unread message

Glen Hytoft

unread,
Feb 6, 1998, 3:00:00 AM2/6/98
to

How do I show or hide a list box.

I think I've found out that WS_VISIBLE is the style that controls the
visibility of an list box. But how do change that.

I've tried:

GetDlgItem(IDC_MYLISTBOX)->ShowWindow(SW_SHOW);

and

GetDlgItem(IDC_MYLISTBOX)->ShowWindow(SW_HIDE);

but that crashes.

Any suggestions ?

The Gremlin

unread,
Feb 6, 1998, 3:00:00 AM2/6/98
to

That's the way to do it. But you're probably making these calls on the
OnCreate function, at that time the ListBox doesn't exist yet.

Make the calls on OnInitDialog.

Glen Hytoft wrote in message ...

Glen Hytoft

unread,
Feb 6, 1998, 3:00:00 AM2/6/98
to

Unfortunately not. I'm using the call in message handlers (ON_CLICK).

I.e. when I click radio button #1 then the first ComboBox (I wrote ListBox
but I mean ComboBox) is visible, and the second ComboBox is invisible. And
when I click radio button #2 then the second ComboBox is visible, and the
first ComboBox is invisible.

Glen

The Gremlin wrote in message ...

Oliver Carl

unread,
Feb 6, 1998, 3:00:00 AM2/6/98
to Glen Hytoft

Glen Hytoft wrote:
>
> Unfortunately not. I'm using the call in message handlers (ON_CLICK).
>
Still, the window might not be created yet....:

If your application crashes (actually always - to avoid the
possibility), I would try the following:

CWnd* w = GetDlgItem(IDC_MYLISTBOX);
if (w != NULL)
w->ShowWindow(SW_SHOW);
else
TRACE0("....\n");

(As an alternative, you might also use exception handling.)

That might not be a solution to your problem, but it should avoid a
crash and therefore make the debugging processing easier :-).

Also check that IDC_MYLISTBOX is the correct name.

cu
Oliver

Ken Schweizer

unread,
Feb 9, 1998, 3:00:00 AM2/9/98
to

I too have tried somewhat the same thing with the same results. I let
Bill's software do everything and assumed that it would work. I know I'm
showing my naivete in Visual C++, but I must be missing a definition of
some sort.

Using the Resource Tab I copied IDC_COMM_MyDialog and renamed it to
IDC_COMM_MyDialog_P, then changed all of the edit boxes ID's. When I press
a button on IDC_COMM_MyDialog Box it executes :

GetDlgItem(IDD_COMM_MyDialog)->ShowWindow(SW_HIDE);
GetDlgItem(IDD_COMM_Dialog_P)->ShowWindow(SW_SHOW);
and should "switch" windows.

When I click on the button I get

COMM caused an invalid page fault in
module MFC42D.DLL at 014f:5f43889c.

I'm afraid I have no idea what this means.

Any help will be appreciated.

Ken

Please remove SPAM from my address to contact me.

Joseph M. Newcomer

unread,
Feb 14, 1998, 3:00:00 AM2/14/98
to

On 9 Feb 1998 02:25:07 GMT, kens...@magicnet.net (Ken Schweizer)
wrote:

Better style is to use the Variables tab on the Class Wizard to add
variables to represent the list box. For example, create a variable
of type "control". For example
IDC_MYLISTBOX CList c_MyListBox

(Microsoft keeps insisting on the m_ prefix, but for controls it makes
a lot more sense to have the c_ prefix, because you can then use the
m_ prefix to add a "Value" type variable if you want one. Just
backspace over the m_ and type c_)

Now, let's say you want to hide the box initially in the OnInitDialog,
and make it visible later

To hide it, you just write
c_MyListBox.ShowWindow(SW_HIDE);

and to make it visible you write
c_MyListBox.ShowWindow(SW_SHOW);

I wish Microsoft had the sense to give us OnUpdateCommandUI interfaces
to dialog controls; it is the single most sensible approach to the
problem, yet they don't do it. I tend to handle it by putting all the
enable/show logic in exactly one function which I call everywhere. I
sounds "inefficient" but the inefficiency is so irrelevant compared to
the complexity that I have decided this is the only way that makes
sense:

void MyClass::updateControls()
{
if(whatever)
c_MyListBox.ShowWindow(SW_SHOW);
else
c_MyListBox.ShowWindow(SW_HIDE);

BOOL enable = something;
c_MyButton.EnableWindow(enable);
c_MyCheckGroupBox.EnableWindow(enable);
c_CheckBox1.EnableWIndow(enable);
c_CheckBox2.EnableWindow(enable);
}

// of course I use more sensible names than "CheckBox1"...

void MyClass::OnSelChangeThing()
{
... do my thing
updateControls();
}

This means you NEVER, EVER, NOT EVEN ONCE, have to figure out if
you've called exactly the right subroutines from all the precisely
right places to make sure that all the controls are shown and enabled
consistent with your intentions. Absolutely positively all logic is
in exactly one place, easily seen, maintained, and all you have to
remember to do is call updateControls() whenever you change any state
that matters. I have applied this method rigorously since I first
started programming MFC and have NEVER found a reason to regret it. I
HAVE regretted every program I ever wrote that did NOT use this style,
and I have spent a lot of time when I get code others have written
rewriting their dialog handlers to use this style. And every time I
do, I find BUGS in their code that go away (and would never have
occurred) in my style.
joe

Joseph M. Newcomer
newc...@flounder.com
http://www3.pgh.net/~newcomer

0 new messages