Board index » Visual Studio » Combo box getting hidden

Visual Studio302
I have a problem with the same CView class I asked about the other day...



Its a CView class with an extensive OnDraw method (Gantt-based resource

loading chart). I have a few controls in the corner - a plus and minus

CButton, a CStatic text (my font problem the other day) and a CComboBox. I

also have a horizontal and vertical CScrollBar. These controls are class

members (no resource associated) and are all .Create() in my ::Create

method. Following an OnDraw(), everything is drawn properly, except my combo

box. I assume it is a z-order problem, but I don't know how to bring it

forward again, or just manually call a redraw method on the control at the

end of my OnDraw.



I've tried a ShowWindow with SW_HIDE, followed by a SW_SHOW. I've tried

ActivateWindow. I've tried SetPosition, but the version of the method in the

MSDN has a different set of parameters and the second parameter in the MSDN

(insertAfter) doesn't exist in the method for CComboBox.



Its late and I'm tired again, so this is probably obvious, but Help!


-

What's wrong with it?



Why?



Have you checked the z-order of the control using Spy++? The z-order

is just the order the controls are listed under their parent in Spy++.



The z-order can be changed by using SetWindowPos.



Dave

-

"David Lowndes" <DavidL@example.invalid>wrote in message

Well, everything is drawn properly (my own lines/ boxes and the CButtons

etc), except my combo box - its just a white box so I can't see it!



I thought it is possibly being drawn before I draw the rest of the screen,

therefore it is behind something else



And like I said in my original question, the CComboBox ::SetWindowPos()

method is not the same parameter list as the main SetWindowPos method in the

MSDN - the second parameter (in the MSDN) is how to change the Z-order and

this is the parameter missing from the CComboBox::SetWindowPos() method!





-

see below...



On Tue, 22 May 2007 10:44:52 +0100, "GT" <ContactGT_remove_@hotmail.com>wrote:



Hmm...CComboBox::SetWindowPos does not exist; it derives directly from CWnd::SetWindowPos.

It is not the second parameter to CWnd::SetWindowPos that determines the z-order, but the

first parameter. It is the second parameter of ::SetWindowPos (the raw API call) but that

is not relevant here. So what are you talking about?



The parameters to CWnd::SetWindowPos are

(const CWnd * pInsertAfter, int x, int y, int cx, int cy, UINT flags)

so I have no idea why you would think the x-coordinate had anything to do with the

Z-order.



joe

*****

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

"Joseph M. Newcomer" <newcomer@flounder.com>wrote in message

You've got the wrong end of the stick. Clearly I didn't think the x

coordinate has anything to do with the z-order. The second parameter in

SetWindowPos according to the MSDN is 'hWndInsertAfter'. I looked up

SetWindowPos in the MSDN and arrived at this page entitled "SetWindowPos

Funtion":



msdn2.microsoft.com/en-us/library/ms633545.aspx">msdn2.microsoft.com/en-us/library/ms633545.aspx



The second parameter here is 'hWndInsertAfter'. The x coordinate is the 3rd

parameter. The 'hWndInsertAfter' can be set to HWND_TOP (amongst other

things). However, when I tried to use this method on my control the compiler

told me that I had the wrong number of parameters and the intellisense

clearly showed that the second parameter of the MSDN's SetWindowPos

('hWndInsertAfter') was not there for CScrollBar, but in fact the parameter

list is as you have quoted above, hence my confusion - 2 methods with the

same name, but different parameter lists and the parameter I need to use

isn't available in the CComboBox::SetWindowPos! If the 'hWndInsertAfter'

parameter is not there, then how do I set it?. I tried using HWND_TOP as my

first parameter and the compiler said it couldn't convert from "HWND" to

"Const Wnd *". At this point, I went to bed!





-

See below...

On Tue, 22 May 2007 15:56:00 +0100, "GT" <ContactGT_remove_@hotmail.com>wrote:



But you clearly said

CWnd::SetWindowPos method is used to set the Z-order for the SetWindowPos method; I see no

reason I would ever want to use the ::SetWindowPos API. And if you had read the

documentation, you would have clearly seen that this is true. It is clearly NOT missing

from the CComboBox::SetWindowPos (which is CWnd::SetWindowPos).



API: ::SetWindowPos(HWND hWnd, HWND hInsertAfter, int x, int y, int cx, int cy, UINT

flags)

MFC: CWnd::SetWindowPos (const CWnd * pInsertAfter, int x, int y, int cx, int cy, UINT

flags)



Just looking at the names alone makes it evident that in MFC it is the first parameter.



Note that when you are talking about calls, you must distinguish if you are talking about

raw API calls or MFC methods, and since you were talking about CComboBox::SetWindowPos, it

seemed obvious from context that you were comparing it to CWnd::SetWindowPos. Otherwise,

you would have explicitly said "::SetWindowPos" or "the SetWindowPos API".

****

But the problem is you are talking about the SetWindowPos API, which in programming MFC

would be irrelevant. So why didn't you look up the SetWindowPos *method*?

*****

Reading the documentation is usually a good start. OF COURSE Intellisense told ;you that

there were not two window parameters, because it was doing the correct thing, as the

compiler did, of referencing the MFC method of the CWnd class. Most API calls have MFC

methods of the same name. Had you actually looked at the documentation, this would have

been obvious. But you did not look at the "SetWindowPos method", which is what you should

have looked at when using MFC. So what was missing was the explicit first parameter which

defined the window whose position was being set, which in MFC is the m_hWnd member of the

CWnd-derived class.

joe

*****

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

GT wrote:

GT:



It is MFC 101 that most Windows API functions that take HWND as the

first parameter have a corresponding CWnd method with the same name with

the first parameter removed. If you use this name, unqualified, from a

CWnd method, then you are calling the CWnd method. To get the API

function you would need to do, for example, ::SetWindowsPos(...). The

compiler will not use your arguments to conclude that you wanted the API

function; rather it will tell you that you have the wrong number of

arguments for the method



--

David Wilkinson

Visual C++ MVP

-

Joe, you clearly have a fantastic and deep understanding of the MFC and

MSDN. I have a lot of respect for this as I have no formal training in MFC.

The majority of your posts are very helpful and constructive. However, I

find a large minority of your posts very annoying as you seem to take

pleasure in berating anyone who doesn't know how to do something which to

you is simple. I felt like a naughty schoolboy after your last post which

shot me down in flames!



OK, so I have my dunces hat on, but you have taken pages of text to tell me

off for referring to the wrong version of the SetWindowPos method, but you

haven't actually offered me any help, other than saying "read the

documentation"!! Why didn't you just say that in 1 line!



Now that I have found the right page in the MSDN for SetWindowPos, I find

that it doesn't actually solve the problem anyway, so all this telling off

was for nothing!!



I did say in my original post that I "assume" that z-order is the problem,

however "m_cmbResource.SetWindowPos(&wndTop, etc" still leaves me with a

white / invisible combo box, for most of the time. So something else must be

the problem. As well as SetWindowPos, I've tried a ShowWindow with SW_HIDE,

followed by a SW_SHOW. I've tried ActivateWindow(). Any other ideas anyone?





-

On the face of it that doesn't sound (appear) like a z-order problem.

If it were an SDK application I'd assume it was due to incorrect

message processing somewhere. I'm not sure how you'd easily get that

sort of error with MFC though.



I didn't see you mention if you'd checked the z-order...

Have you?



Dave

-

There are things you need to understand about MFC before you start, and nearly every book

about MFC explains these things. One of them is that most methods of wrapper classes have

the same names as the API calls. I knew this the first day I wrote an MFC program, and I

didn't have a book, just the Microsoft documentation and the Scribble tutorial. You can't

just sit down and start randomly writing code without doing SOME study, and one of the

very first things you have to study is the CWnd class because it is so important. The

next one to study is the CDC class. You spend the first few days just reading the methods

in these classes. Then it is obvious.



The answer is indeed obvious. If you know how to use the API, you know how to use the MFC

method. The only thing you glean from the documentation is that instead of using the HWND

value HWND_TOPMOST, for example, you use the CWnd* value &hwndTopMost.



There are disciplines of learning technology that you need to apply, and that's what I was

really yelling at you for. You did not apply good study methods to learning a new system.

When I learned windows, I spent a couple weeks just reading manuals, so by the time I sat

down to write my first program, I had absorbed a massive amount of the culture of Windows.

After that, it was just looking things up. I read the Windows manuals at night,

alphabetically by API name, to see what each API did.



When I learned MFC, it took me considerably less than a day to learn about the naming

conventions for the methods. It was in the introductory documentation, somewhere near the

front! I just started doing the Scribble tutorial and learned enough MFC in three days to

deliver a prototype to my customer in two weeks.



You DON'T sit down and start typing code. It is a bad way to develop software, and it is

a bad way to learn.



Today, I STILL sit down with something in the manual and read all about it before I start

coding. I read the entire debug interface two weeks ago. Spent a whole day just reading

it. When I sat down to write my code, it came up almost immediately, except for one

glitch that seems to be due to inadequate documentation. But you sound like you just sat

down and started typing, without taking time to understand even the superficial aspects of

what is going on in MFC, such as the methods of CWnd and CDC. Otherwise, the error you

reported would have not been made.



There are deep issues about MFC, and these take a lot of explanation, but you are expected

to know how to use the documentation.



Also note that an earlier answer to your problem suggested that this would be an issue

only if you had overlapping controls; if you don't have overlapping controls, it is not

the problem. The problem is elsewhere.



Right now, you are flailing about, sprinkling pixie dust around in the hopes of solving

the problem.



Is it an owner-draw box? What are its styles? Are you doing any graphics on your own,

using CDC, CClientDC, CPaintDC, memory DCs, etc.? It still sounds like a resource leak.

joe



On Tue, 22 May 2007 22:12:43 +0100, "GT" <ContactGT_remove_@hotmail.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-