Change Client Area Background Color

[donkey]

I was trying to pass Dave a simple enough example without extra the complexity.

I wasn't saying your way was wrong just suggesting that you delete your brushes. The issue in the loop is SetWindowText, remove that and the loop runs fine, however the difference in available physical memory between using DeleteObject and not using it is around 434KB on my system, not much considering a million iterations but good coding practice to avoid it all the same. You are right that creating the brushes in global memory solves the problem of deleting them after each change perhaps Dave could use that approach.

It just happens to be that the brush handle set in the WNDCLASSEX structure is not selected into a device context so there does not appear to be any purpose in trying to delete a non selected object.

Every object created by the Windows Executive consumes resources whether it is used or not and you never delete an object while it's selected into a device context, that's verbotten.

[dedndave]

nice try, Hutch
but, i'm afraid you're too late - i already complicated the hell out of it
maybe you didn't see the first few posts of the thread   :lol

as for whether or not to delete the brushes - or to use pre-made ones - i think it depends on how they are used
the plan here was to offer the user a color chooser dialog and let them pick any color
that being the case, deleting the old brush is probably a good idea

[hutch--]

This is the one you will have fun with if you put it into a large loop.

Code Select Expand


mov redbrush,   rv(CreateSolidBrush,000000FFh)


The propblem as I see it is the same API call to set the class brush can be used with pre-defined system brushes with no difference in how they are passed to the SetClassLong API and you clearly do not delete the system brushes.

The rough rule with GDI based functions is if you select the object you delete it after its used. The WNDCLASSEX structure reference says this.

The operating system automatically deletes class background brushes when the class is freed. An application should not delete these brushes, because a class may be used by multiple instances of an application.

[donkey]

This is the one you will have fun with if you put it into a large loop.

Code Select Expand


mov redbrush,   rv(CreateSolidBrush,000000FFh)


The propblem as I see it is the same API call to set the class brush can be used with pre-defined system brushes with no difference in how they are passed to the SetClassLong API and you clearly do not delete the system brushes.

The rough rule with GDI based functions is if you select the object you delete it after its used. The WNDCLASSEX structure reference says this.

The operating system automatically deletes class background brushes when the class is freed. An application should not delete these brushes, because a class may be used by multiple instances of an application.

That's an incorrect assumption. You are not deleting a class brush, once you use SetClassLong the brush it returns is no longer a class brush, its just a normal brush and should be deleted. Once you change the class background brush the old one is not deleted when UnregisterClass is executed, only the one returned by GetClassLong is deleted. You can verify this by creating a class, assigning it a different brush then checking to see if the returned brush is destroyed when the window is destroyed and the class is unregistered, it isn't, I checked  :wink

[dedndave]

also - i read somewhere in all that documentation that...
it is ok to attempt to delete a system brush because the attempt is ignored and system brushes are not deleted

[hutch--]

Dave,

One of the lessons I have learnt with Windows API coding is be careful about deallocating what has not been allocated. Often it just does not matter and it will be silently ignored but there are also times when it trashes the app so I have long been careful to match what goes up with what goes down.

When you start working with GDI graphics, the simple rule is write your code so that anything you select as an object is deselected and replaced with the original once you have finished with it. It sounds a bit complicated but the logic is simple enough.

Code Select Expand


oldobject = SelectObject(newobject)
  ; use new object
SelectObject oldobject
DeleteObject newobject


Its basically a replace then restore operation and particularly with GDI objects that are selected if you mess this up you get a memory leak that gets worse as the function is called more often. In 16 bit Win3.? it would crash the OS after a while.

You avoid most problem in this area and similar by designing the allocation and deallocation at the same time them write the code inbetween. Tracking down leaks after code has been written is no joy at all so you code a style that saves you the problem. It is also worth checking your return values to make sure the deallocation worked correctly.

[dedndave]

well - there is no need to delete any system brushes, actually
i can create a brush to begin with, so i don't have to use GDI stock brushes at all
i have Edgar's code implemented - and it works great
every bit as fast or maybe faster than my original DIB/BitBlt code - which was extensive
(both are so fast, you'd have to measure to tell a difference)

this thing is almost done   :P
i really appreciate all the help, especially the explanations, that you guys have provided   :U