Index
> Windows > About Win API... :O) |
| Author |
|
|
JohnFound 18 Apr 2005, 16:46
denial wrote: 1) If I create a Windowclass inside an application (WNDCLASS, WNDCLASSEX), I can use it for more than one window. However, they'll have all the same backgroundcolor / icon etc., To keep every window changeable, I wanted to create an own windowclass for each window I create. Does it cost much memory or does it have any disadvantages when I create serveral windowclasses? Or is there maybe a way to change backgroundcolor / icon / menue etc. at runtime, without having a new windowclass? Set NULL for hCursor and hbrBackground members of WNDCLASSEX. Then Windows will not try to set mouse cursor automatically nor to erase the background collor for you. Later you can handle WM_ERASEBKGND and WM_SETCURSOR. You even can set hCursor and hbrBackground members to some default values and then to handle above messages only for some of the windows instances. Quote: 2) I would like to handle serveral windows / windowclasses with one WndProc Function... How can I handle the windows seperately? Is there some kind of identifier? If you want to make different handling of some messages for several window classes with one procedure, you can try to use GetClassName function and to check the classname of particular window. But IMHO, this is ugly solution. Better use one class and one main procedure for common messages and subclassing with several small procedures for messages that differs in different windows. Regards |
|||
18 Apr 2005, 16:46 |
|
|
f0dder 18 Apr 2005, 17:08
Often, you don't even have to subclass - you can use Set/GetWindowLong with GWL_USERDATA, and store a pointer to a structure with the colors and brushes you want to use.
|
|||
|
18 Apr 2005, 17:08 |
|
|
denial 18 Apr 2005, 18:03
Does it mean, that I can fill the GWL_USERDATA attribute within the function SetWindowLong with any value I want? So I could just write there an identifier 0 - 100 or something inside?
By the way: How can I translate the NULL operator in C/C++ within FASM? Is it just a binary 0? |
|||
|
18 Apr 2005, 18:03 |
|
|
coconut 18 Apr 2005, 18:57
yes 0 or NULL will work
|
|||
|
18 Apr 2005, 18:57 |
|
|
JohnFound 18 Apr 2005, 19:25
f0dder wrote: Often, you don't even have to subclass - you can use Set/GetWindowLong with GWL_USERDATA, and store a pointer to a structure with the colors and brushes you want to use. These days I prefer to use GetProp/SetProp - more flexible and if the name of the property is not too long (or if the name of property is an ATOM) - faster than Get/SetWindowLong. Regards. |
|||
|
18 Apr 2005, 19:25 |
|
|
f0dder 19 Apr 2005, 12:41
I had totally forgotten about Get/SetProp - thanks for reminding me, John. It's certainly more flexible, it even allows you to do things like subclass "legacy" apps that store data in Get/SetWindowLong.
Sounds a bit weird that it's faster, I would have thought it needs at least the same amount of processing... well, anyway, can the speed be measured at all?  |
|||
|
19 Apr 2005, 12:41 |
|
|
denial 19 Apr 2005, 13:29
Thank you for your help. It got more clear now.
|
|||
|
19 Apr 2005, 13:29 |
|
|
JohnFound 23 Apr 2005, 07:31
f0dder wrote: Sounds a bit weird that it's faster, I would have thought it needs at least the same amount of processing... well, anyway, can the speed be measured at all? Hi, F0dder. Actually I made some benchmarks some time ago. Using string as a name of the property is really as far as twice slower than using Get/SetWindowLong. But using ATOM object as a name of the property turns the things and Get/SetProp becomes two times faster. So, Get/SetProp gives you speed if you need it and flexibility in all cases. See the results here: http://board.flatassembler.net/topic.php?t=2182 Regards |
|||
|
23 Apr 2005, 07:31 |
|
|
f0dder 23 Apr 2005, 11:29
Interesting - I find Get/SetProp to be more convenient than Get/SetWindowLong, and some extra speed never hurts. But you've tested on Win9x - things can sometimes look *very* different on NT, since it doesn't have the stupid 16/32bit mix that Win9x has. Do you still have the benchmark? I'd like to see how things are like on XP, and I'm lazy so it would be nice not having to write my own benchmark
Still, is there any "real world end-user" benefit from using Get/SetProp? I mean, extra speed never hurts, but is this in any way visible to the end-user? |
|||
|
23 Apr 2005, 11:29 |
|
|
JohnFound 23 Apr 2005, 12:49
f0dder wrote: Interesting - I find Get/SetProp to be more convenient than Get/SetWindowLong, and some extra speed never hurts. But you've tested on Win9x - things can sometimes look *very* different on NT, since it doesn't have the stupid 16/32bit mix that Win9x has. Do you still have the benchmark? I'd like to see how things are like on XP, and I'm lazy so it would be nice not having to write my own benchmark OK, I lost program I used in mentioned tests, but it was very simple, so I simply sketched one for several minutes. Check the attachement. Quote: Still, is there any "real world end-user" benefit from using Get/SetProp? I mean, extra speed never hurts, but is this in any way visible to the end-user? IMHO, this depends how frequently you set/get the property. If for example you use the GetProp for subclassing in Window procedure and there is only Windows message flow - the speed really doesn't matter. But if you try to send big amount of messages to this window from inside a loop (well this is not good style at all, but...) or you simply want to read this property in loop, then the speed might be important. Regards.
|
|||||||||||
|
23 Apr 2005, 12:49 |
|
|
f0dder 23 Apr 2005, 13:31
Thanks!
I've been using Get/SetWindowLong for a C++ windowing framework, where it's used for storing the "this" pointer. Which means that GetWindowLong is called for *every* window message. I designed this code a while ago, before I learned about Get/SetProp .
I still don't think it's going to make much of a difference at runtime, but Get/SetProp is certainly more elegant, and extra speed never hurts. I'm going to run the timing on my testbox in a bit as well, but here's for my workstation: AMD64 3500+, Running XP SP2. Property name: "fwnd::class" 100000 iterations { GetProp/SetProp: ~220ms GetProp+ATOM: ~15ms SetProp+ATOM: ~125ms GetWindowLong: ~65ms SetWindowLong: ~110ms } 1000000 iterations { GetProp/SetProp: ~1200ms GetProp+ATOM: ~170ms SetProp+ATOM: ~750ms. GetWindowLong: ~500ms SetWindowLong: ~700ms } |
|||
|
23 Apr 2005, 13:31 |
|
|
f0dder 23 Apr 2005, 13:59
Hrrrrrmmmmm....
PII-350, running win2000 SP4. Again, "fwnd::class" prop name. 100.000 iterations: { GetProp: ~820ms SetProp: ~880ms GetWindowLong: ~50ms SetWindowLong: ~220ms GetProp+ATOM: ~1280ms SetProp+ATOM: ~1300ms } 1.000.000 iterations: { GetProp: ~8270ms SetProp: ~9010ms GetWindowLong: ~530ms SetWindowLong: ~2215ms GetProp+ATOM: 12980ms SetProp+ATOM: 13270ms } ...and now, when running the tests again on my main machine, the ATOM versions are slow. This is... weird. Bug in your code? Me doing something wrong? Windows acting up? |
|||
|
23 Apr 2005, 13:59 |
|
|
Shakain 30 Apr 2005, 07:32
denial wrote: Hello, Assign each new window the same Winproc, using SetWindowLong. Then dispatch the messages to the correct routine, based on the windowhandle, that is passed to the winproc routine. _________________ Hi guys  |
|||
|
30 Apr 2005, 07:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|