I was thinking about adding smooth scrolling... but to much hassle for now. I am converting it over into 2d, where I have a lot more control over how things are drawn. The purpose of this GUI was to test designs for an OS i''m writing. It will end up being 2d, with all sorts of alpha tricks, smooth scrolling, etc.. but for now, i''m just making it work, and error free .

I wrote it from the ground up, and I linked a demo with source code for you. It''s not as complete as a windows GUI, but it sure can look pretty . If you are really interested in the code, I have to ask if you''re familiar with linked lists, and class inheritance... if not, you''ll be completely lost, as the entire thing is based around this .

Wojtos and Ready4Dis, I can''t download either of your samples - I''d like to see them.

Currently my GUI supports passing input messages via the virtual function method, propogating the message down through to the bottom window, or control. Even this method is simple, anyone have any thoughts as to how microsoft handles messages? I know that they have some member function macro system set up that binds the functions, and decreases the overhead by eliminating the messaging handling functions that arent needed. This is comletely different than how I do it, in that every child window musta also contain all of the window handling routines.


so in my setup i have a generic window that has message functions like this:

window->mouse_dblclick();
window->mouse_rightclick();

etc...

and every window will inherit those same member functions, and I can fill them in to make them handle differently for each dialog, button, etc. that inherits. This is wasteful though it seems, to inherit all that data.


microsoft seems to only have those handling functions defined when needed within any arbitrary window. I dont understand how they add message handlers without all the inheritance. Anyone shed some light on this subject? My guess is they have function pointers or something within the base class declaration, and then they are bound to real member functions via these macro things when needed. I dont know tho, but somebody does.

Famine: Each time it is "inherited" I don''t beleive that it actually makes a copy of the functions, it just creates one instance of the function, and passes the "this" pointer to said functions.

Xori: Email me, or find me online... (could you at least view the images?)

Email: Ready4Dis@aol.com
AIM: CrazyGuy4Eva
MSN: Ready4Dis_1@hotmail.com

Wojitos: After reading through a few lines of code, I think I''m sick . You check EVERY single key to see if it''s depressed?! Also, some buttons are in front of windows that are above them, which looks rather odd. Also, your window class handles your object''s getting clicked, etc... while I have my objects handling what happens when they are clicked. I also noticed that you check EACH object type in seperate loops.... I have a base class object, that each object is inherited by, so I can simply check my single linked list (linked lists are much better for this, because you don''t have to re-allocate memory, copy objects, and delete old memory.. you simply allocate the new block of memory, and update the pointers.) You''re code would be VERY difficult to add new objects too, as you''d have to go through and implement you''re object code within your window code, add extra loops, etc. With mine, you can add new objects without modifying my code base AT ALL. You simply inherit from the base class, create the object you''d like (with functions to handle KeyPress, MouseClick, and a few other actions), make a call to my window class'' Add_Object with a pointer to your object, and it will automagically handle it . No need to implement more loops, or other types of handling things, and no need to even understand any of my underlying code .

ps. This is meant to be constructive, if it comes off as me picking on you, sorry . I am going to finish up on writing this section of code (I was writing some debbuging code) and then I will make the sources available to anyone interested.