flat assembler
Message board for the users of flat assembler.

Index > Windows > About Win API... :O)

Author
Thread Post new topic Reply to topic
denial



Joined: 12 Sep 2004
Posts: 98
denial
Hello,

at the moment I try to understand the WIN-API better for the usage in Flatassembler. Well I come along with two questions:

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?

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?

Thank you in advance...
Post 18 Apr 2005, 15:56
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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
Post 18 Apr 2005, 16:46
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 18 Apr 2005, 17:08
View user's profile Send private message Visit poster's website Reply with quote
denial



Joined: 12 Sep 2004
Posts: 98
denial
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?
Post 18 Apr 2005, 18:03
View user's profile Send private message Reply with quote
coconut



Joined: 02 Apr 2004
Posts: 326
Location: usa
coconut
yes 0 or NULL will work
Post 18 Apr 2005, 18:57
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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.
Post 18 Apr 2005, 19:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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? Smile
Post 19 Apr 2005, 12:41
View user's profile Send private message Visit poster's website Reply with quote
denial



Joined: 12 Sep 2004
Posts: 98
denial
Thank you for your help. It got more clear now.
Post 19 Apr 2005, 13:29
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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? Smile


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
Post 23 Apr 2005, 07:31
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile

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?
Post 23 Apr 2005, 11:29
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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 Smile


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.


Description:
Download
Filename: GetSetTest.zip
Filesize: 6.53 KB
Downloaded: 98 Time(s)

Post 23 Apr 2005, 12:49
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile.

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
}
Post 23 Apr 2005, 13:31
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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?
Post 23 Apr 2005, 13:59
View user's profile Send private message Visit poster's website Reply with quote
Shakain



Joined: 08 May 2004
Posts: 3
Shakain
denial wrote:
Hello,

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?
Thank you in advance...


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 Very Happy
Post 30 Apr 2005, 07:32
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.