|
If a window is created with the WS_VISIBLE style it will be visible as soon as it is created: No call to ShowWindow will be required. Can you show us the code in question?
Steve
|
|
|
|
|
Thanks for answering by the way :- ). Yes, I know what WS_VISIBLE does. The code is quite big and has some other functions. I will try to keep it down as much as possible not to clog the post.
1. Window is created via a call to a Build function. The Build function creates the PARENT like this:
hwndThis = CreateWindowEx<br />
(<br />
NULL,<br />
sClassName,
sClassName,<br />
WS_POPUP | WS_VISIBLE,<br />
0,<br />
0,<br />
W,
H,<br />
NULL,<br />
NULL,<br />
hHost,
NULL<br />
);
2. The kid is created like this, using a call to a CreateControl function, AFTER the Build function finished its stuff:
<br />
hwndControl = CreateWindowEx
(<br />
NULL,
"Static",
Text,
lStyle,
0,
0,
0,
0,
hwndThis,
NULL,
(HINSTANCE)hwndThis,
NULL
);
The conclusion is that I don't see the kid displayed. At all.
However, if I call the CreateControl function when clicking some other button, it works. What doesn't work is when in the same place I do
Build
CreateControl
But if I do:
Build
<now click="" some="" button="">
CreateControl <in the="" code="" of="" that="" button="">
It works.
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
Looks like it's because the child has 0 width and height. Also the hInstance is set wrong. Try this (but correct the hInstance ):
<br />
hwndControl = CreateWindowEx
(<br />
NULL,
"Static",
Text,
lStyle,
0,
0,
100, <br />
100, <br />
hwndThis,
NULL,
(HINSTANCE)hwndThis, <br />
NULL
);<br />
In general casting should be avoided. For example without the (HINSTANCE) cast you would get a compiler but with it you're telling the compiler "just do it" and circumventing type checking.
Steve
-- modified at 3:05 Thursday 19th January, 2006
|
|
|
|
|
Well, I'm not that much of a begginer. Sorry, I forgot to mention that I do set WIDTH and HEIGHT later. So those are valid members. However, you did help me understand the real problem. The X and Y that I set later were corrupt due to some checks I made later and because the parent wasn't visible, X and Y were something like -50000. Now I corrected them and it works. So thank you for indirectly making me solve the problem!!
About the HINSTANCE: I don't think that this is the problem because it works in some cases, as I said, when I call the CreateControl function later. However, I did take your remark in notice and will try from now on to pass HINSTANCE. I don't fully understand the difference between passing a HINSTANCE and a HWND, and at the time, I couldn't get a HINSTANCE so easily. How do you get one for a HWND anyway?
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
Normally you get the HINSTANCE (or HMODULE , they are the same in Win32 - there used to be a distinction in the 16 bit days) from your DllMain if you're a DLL or from WinMain for an EXE. Also see here for details on the hInstance parameter of CreateWindow . In short all the system supplied window classes (such as "STATIC") ignore the hInstance parameter because they are registered with the CS_GLOBALCLASS flag.
HINSTANCE g_hInstance;
BOOL WINAPI DllMain(
HINSTANCE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved
)
{
if ( fdwReason == DLL_PROCESS_ATTACH )
{
g_hInstance = hinstDLL;
}
}
int WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
)
{
g_hInstance = hInstance;
}
Steve
|
|
|
|
|
Yeah but the Application I'm using to test&develop my API wrapper class is MFC, I don't see any "m_hinstance" member. I didn't spend too much time searching for it either but MFC doesn't have a WinMain exposed right? I got a few things made in MFC (2 of them with an UI) but it just seemed easier to throw the HWND and since I saw it working I said "ok". I think I also saw in some examples people that passed HWNDs there.
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
AfxGetApp()->m_hInstance
Steve
|
|
|
|
|
You're too kind :- ). Thanks.
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
However, how do I get the HINSTANCE of a newly created window? You see, my window API wrapper, creates a window and obtains a HWND from CreateWindowEx. But as I create children in this window, to their CreateWindowEx I also have to specify a HINSTANCE. And from where exactly will I find out the HINSTANCE of the first window that I created, considering that I did not retrieve it via WinMain since I do not have a WinMain (I have a WndProc only). Can I specify the same HINSTANCE as I specified for the parent? Or should I do in another way? Any ideas?
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
The HINSTANCE you pass to CreateWindow(Ex) should be:
- The HINSTANCE of the module that called RegisterClass for the desired window class (the one you're creating); or if the CS_GLOBALCLASS class style is used,
- Whatever you like (I'd use NULL in this case).
All of the pre-registered window classes like "EDIT" and "STATIC" use the CS_GLOBALCLASS class style.
Steve
|
|
|
|
|
1. So I can specify NULL for all of these?
Button The class for a button.
ComboBox The class for a combo box.
Edit The class for an edit control.
ListBox The class for a list box.
MDIClient The class for an MDI client window.
ScrollBar The class for a scroll bar.
Static The class for a static control.
2. But still, how can I get the HINSTANCE of a window that I created using CreateWindowEx using a simple class that I created too using RegisterClassEx.
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
Axonn Echysttas wrote: 1. So I can specify NULL for all of these?
Yes.
Axonn Echysttas wrote: 2. But still, how can I get the HINSTANCE of a window that I created using CreateWindowEx using a simple class that I created too using RegisterClassEx.
Two choices here:
1. When you call RegisterClass(Ex) use the CS_GLOBALCLASS style. If you do this you can pass NULL for your own classes. This is the more dangerous option because as the class is global you run the risk of name clashes.
2. When you call RegisterClass(Ex) pass the HINSTANCE of the you EXE/DLL and use the same HINSTANCE when calling CreateWindow(Ex) . In this case it is the HINSTANCE /class name pair that identify the window class. Typically the HINSTANCE of the module that calls RegisterClass(Ex) is used.
Steve
-- modified at 9:29 Thursday 19th January, 2006
I misunderstood (2):
A HINSTANCE identifies a module (an .EXE or DLL). I'm not sure if you can get the HINSTANCE of a class from a HWND .
|
|
|
|
|
Yeap. Ok. It's all clear now. Thank you a lot. My final decision is that I will use the HINSTANCE of the EXE/DLL all over the place, rather than using global.
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
|
in the header file it says,
<br />
typedef UINT WPARAM;<br />
typedef LONG LPARAM;<br />
typedef LONG LRESULT;
so WPARAM can be anything as long as you dont want to pass a negative values,
LPARAM can take negative values,
Also both are used for polymorphic values, so anything from number of trees to pointers can go there
I generally use LPARAM for pointers only.
-Prakash
|
|
|
|
|
The guideline is indeed tied to the event. That's the point, a generate purpose param that can hold whatever the event wants to pass.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
HWND is a handle, so you dont know what value it would hold, so i would put that on LPARAM.
-Prakash
|
|
|
|
|
I am not sure if this still hold true, maybe someone else knows, but the WPARAM used to get trunated to the lower 16 bits when it passed through some message filters. Therefore, I am careful, still, to only pass 16-bit or less values in WPARAM. LPARAM never had any such issues.
|
|
|
|
|
Blake Miller wrote: but the WPARAM used to get trunated to the lower 16 bits when it passed through some message filters
Can you suggest message filters. I would like to know.
So in your opinion what should I do for consistency sake. A few guidelines from you would be helpful.
Or maybe what do you do normally.
Jesus Loves <marquee direction="up" height="40" scrolldelay="1" step="1" scrollamount="1" style="background:#aabbcc;border-bottom:thin solid 1px #6699cc">
--Owner Drawn
--Nothing special
--Defeat is temporary but surrender is permanent
--Never say quits
--Jesus is Lord
|
|
|
|
|
I am not sure which message filters would truncate WPARAM to 16 bits. However, that is WHY it was originally called WPARAM - because it was limited to being a WORD (16-bits).
I limit WPARAM in my work to 16 bits. I use LPARAM full 32 bits.
Usually I do not try to pass pointers or much data through the messages. I pass messages as notifications only between 'subsystems' and rely upon data retrieval function calls to be made to collect the data itself. Some programmers rely upon SendMessage to pass pointers to data via the message queue between subsystems, but that ends up being more trouble to synchyronize with the sending and receiving windows' other activities and other events occuring in a multithreaded envionment. Sure I guess it works okay if the application has a signle thread, but that is not the type of code I am typically writing anyway.
|
|
|
|
|
Hello there,
I am relativly new to C++ and am currently programming for windows in Visual C++. What I want to know is this:
I created a program in which a user enters commands and these commands are compared to functions stored in a seperate .cpp file. This file is in the same folder as the executable but is not part of the solution. Is there a way for the user to enter a command such as 'update' and the program will seek an updated version of the command file and download it from a specified server? i can get everything to work, but I do not know even where to begin will this update feature.
ALL YOUR BASE ARE BELONG TO MICROSOFT!
Demonware Studios Leader
|
|
|
|
|
Do some form of HHTP reuest against your server to see if a 'newer' file exists. Then download the new file as 'text' so it can pass through HTTP and the firewall, then replace your old command file with the new one.
|
|
|
|
|
Thank you
ALL YOUR BASE ARE BELONG TO MICROSOFT!
Demonware Studios Leader
|
|
|
|
|
I'm working on a CEdit derived class that requires that I put a bit of text in the window on creation. I'm doing this in PreSubclassWindow, which may or not be the right place for it but it works. The problem I'm running into is the cursor positioning. If I use SetSel(0,0) in PreSubclassWindow the text ends up being completely highlighted. For the moment I've included a SetSel in the SetFocus handler. But this isn't practical long term. Without any attempt at setting the position selector I still get a completely highlighted edit space.
Where would be the best place to set the original position?
Thanks,
Lilith
|
|
|
|