Custom Controls

[Guest]

Hi,

I have been searching for weeks and I am not able to find any documentation about creating controls in wiondows completely from scratch. I don't mean getting an ActiveX base and drawing my control, I am talking about writing a control from scratch, even in assembly if need be, Im talking about sending the messages, updating the control, basically doing everything that windows does, except my own code doing it. I don't know if you will understand what I am saying, but if you do, can you give me any pointers. I know that Java creates and manages its own controls (I think anyway) and this is what I want to do.

bye.

[Tim]

A control is just another window, so use RegisterClass/CreateWindow as normal, and handle painting, mouse and keyboard messages in your control's window procedure.

[Guest]

Thanks, I never thought about it like that. Do you think that there could end up being alot of flickering?

bye.

[ark]

Any time you create a window there's a potential for flickering...that really depends on how you draw on the window. For one thing, you probably won't often use CS_HREDRAW and CS_VREDRAW -- they're probably some of the biggest causes of flickering. Another thing you might want to consider is drawing on a back buffer (i.e., a device context in memory) and then doing a BitBlt to the screen, which often helps with flickering problems, as well.

[Guest]

Thanks, I have been reading alot about flickering. I have also realised that I am going to have to learn how to draw in regions properly, as this is what the rcPaint item of BeginPaint() is. I was thinking of having a memory DC that holds what the window should look like and then copying the region directly from the memory DC to the DC returned from BeginPaint(), however when it comes to drawing windows that are really big, this would become very memory intensive, especially if there are alot of these windows. For example a window that is 500w x 200h x 24b will need a DC in memory that is 2.2MB, way too much memory for a single window.

Any ideas for other solutions?

Thanks again.

[ark]

500x200 at 24 bits per pixel needs less than 300 kilobytes of memory for a memory backbuffer.

500 * 200 * 24 = 2,400,000 bits

2.4 million bits / 8 bits per byte = 300000 bytes

300000 bytes / 1024 bytes per KB = approx. 293 KB

[Guest]

Oops, didn't even think about it being bits. ::)

300kb is still alot for each window, more than is reasonable anyway.

thanks for pointing that out.

[ark]

Well, ultimately you'll probably have to test your control out and see if it has bad flickering before you take any drastic measures to try to reduce flickering. For most controls, it would probably be sufficient to check the info Windows gives you about the invalidated region so you only redraw the parts you need to.

Look into the ScrollWindow function, as well, if you think scrolling might cause a lot of flickering.

I agree you wouldn't want a large back buffer in memory for child windows that you're going to have lots of. I was thinking about main application windows and things like that, for which a 300KB back buffer isn't at all unreasonable.

[Guest]

Hi,

Just wondering if anyone knows where I can get some info on how to create a custom edit box from scratch. I know the simple stuff like drawing the control, and managing the text buffer, but what I am really interested in is scrolling the text, ideas on how this could be done, how to determine what text to draw, I thought it would be possible to have a large memory dc and draw the text on it and then just display a portion of it, depending on how much text there was, if scroll bars were needed, etc...

any help or ideas would be appreciated. I want to do this using pure win32, no MFC or any other framework.

thanks alot.

[ark]

You could certainly have a large memory DC and just BitBlt portions of it to the screen. But in the case of an edit control, depending on font size and how much data you're going to allow you could very easily have an enormous backbuffer in memory. You should probably look into ScrollWindow, or if you're going to have a backbuffer, make it no larger than the control's screen DC and just erase it before drawing on it (fill it with the background color). The user won't see flicker if you erase the backbuffer, only if you erase the screen.

Is there some reason you need to create a custom edit control? Is the Windows max. edit control data size (64KB) insufficient? Are you doing it just for fun? Subclassing may prove easier unless you want to do something other than modify basic behavior.

[Guest]

To be honest I am really doing it just to learn, I have done it using subclassing, but I really want to learn how to do it from scratch, I am considering (once I have learned enough) creating a library of control classes that I can just plug into an app and use. I don't want the overhead of MFC, subclassing poses problems of its own, and besides this I want to learn as much as I can.

Thanks for your help, I will check out that ScrollWindow() function. I think the hardest part will probably be the algorithms that will be needed to manage the text, like word wrap, how much text to show, etc...

[Guest]

Hi again,

Does anyone know why my custom control would not be getting focus when clicked. I have created the control as normal using CreateWindowEx(), I only override WM_PAINT, WM_SETFOCUS and WM_KILLFOCUS. I use the focus messages just to see if I get focus and I don't get these messages unless I explicitly call SetFocus()??

Any ideas??

[Guest]

Problem solved!!

For some reason I have to manually set focus on WM_xxBUTTONDOWN messages and then I will get WM_KILLFOCUS messages.

[ark]

From Charles Petzold's "Programming Windows":

"when you click on a child window, the parent window rather than the child window gets the input focus. "

That means you have to set the focus to a child window manually and include the logic to make it happen the way you want it. Handling WM_xxBUTTONDOWN is one way, but I don't believe the child will retain input focus if you task switch away from the program and then task switch back again. The parent gets the input focus and if you want the child to get it back you have to keep track of which child window has it.

[Guest]

Indeed you are right!

So, basically I have to subclass the parent window to be able to manage the focus in child windows properly. This is a big bummer.

thanks for pointing that out.