hey guys, i wanna create an object of my own, that will proccess usual messages like WM_MOUSEMOVE, or WM_LBUTTONDOWN,how do i code a massage handler like this? for example if i draw a rect, and to make it get focus like an editbox.. with a caret and text within it.
i know i need to write a CALLBACK function but can i calculate a HWND to my object?
ps. i dont wanna use OwnerDraw methods.
thanks in advance

Maybe subclass a static control?

But I wonder if whatever you're trying to accomplish really calls for this sort of functionality? Your main input handler could simply parse input and pass it along to your object when necessary.

Subclassing is a great feature, but again, i wanna avoid creating WinAPI Windows, just using GDI Funcfions to draw rects, and give them life like Frankenstein! to make a rectangle and click it, and receive a message box "Rectangle Alive!!"

When you click inside that rectangle (or not) you get mouse coordonates too. Compare that with your rect coordonates to see if it matches or not.

Good luck reinventing these things, this is not a beginner job to do.

eventually i think all ways are leading to this solution, ok i will code it, and then will see where it goes from there. my vision was for the rectangle to send a WM_LBUTTONDOWN message, instead of the WM_LBUTTONDOWN message to check if its on the rectangle or not.

my vision was for the rectangle to send a WM_LBUTTONDOWN message ...

To send it where exactly? Call me crazy but shouldn't the rectangle be the recipient of the message? The rectangle should receive the message and react accordingly, there is no reason for it to say "Hey circle, look what I just got!", unless the circle is somehow involved in the response.

hey guys, i wanna create an object of my own, that will proccess usual messages like WM_MOUSEMOVE, or WM_LBUTTONDOWN,how do i code a massage handler like this? for example if i draw a rect, and to make it get focus like an editbox.. with a caret and text within it.

I take it you are a beginner at Windows Programming, and are only beginning to learn proper nomenclature, so its hard for us more experienced types to understand your explanations of what you want. But your above text makes me think you are wanting to make a 'custom control'. The way you do that is by registering a 'Window Class' that you'll use for your control. Actually, a custom control can have many Window Classes. And by doing that you end up with a proper HWND. There is no way you can manufacture a HWND - its something only Windows the Operating System cam bestow upon you. And in terms of receiving WM_LBUTTONDOWN messages as well as any and all others, your new registered Window Class will receive all of them through the Registered Window Procedure for your new class. I posted code here a long time ago that showed how to get started writing your own edit control. I could did that up again for you if you want it.

Ok, lets pretend that the Windows API functions dont exist, only the messages Functions such as GetMessage() and SendMessage() and the MSG structure, and All the rest Message related functions do exist, i wanna create my own "window" control to use the messages to communicate with each other.. is it programmaticly possible? i assume yes, if Microsoft done it, then is possible.. i know its not an easy task, my question is - how to start working on it.

No.

You can't get 'underneath' the Windows Api functions. They are as 'low level' as you can get. Even if you code strictly in assembler, that won't help you get below the level of the Windows Api functions. If you want to code in assembler and create a window the only way you can do t is by calling CreateWindow() or CreateWindowEx(). No ifs, ands or buts. That's it.

You have to realize that Windows is an object oriented system, but was created before C++ came into widespread use. So its a C based object oriented system. When procedural languages such as C are used to create objects you'll generally have 'Create' type functions that do what Constructors do in C++ - they perform low level memory allocations and create the object. Then they'll usually return a pointer to the created object. That's exactly how CreateWindow() operates; the HWND returned from it references internal memory to which you have no access, you can only access it through the provided Api functions. Also, you have to pass in a HWND to many other Api functions as the first parameter of the function call. This is essentially a 'this' pointer to the internal object.

So when you say you just want to just draw lines and do other fancy things to a part of your screen and have Windows recognize it as an object of your own you are just talking nonsense.

But if you are willing to work 'inside the box' instead of out of it, and create your own child window control that exists within the context of another parent window, or even the Windows Desktop itself, then you are in business. There are hundreds of Windows Api functions that you can use. And you start by registering your own custom window class, and providing the address of a Window Procedure for it. At that point you can use CreateWindowEx() to instantiate as many of these as your hearts desire.