A very commonly asked question is "Can I change a window's styles after it's created?" The answer is maybe, maybe not. It depends upon the particular type of window. There is, unfortunately, no standard mechanism for doing this kind of thing. So it becomes just a matter of experience as to what styles you can manipulate after the fact.
In a Perfect World
The obvious solution to this issue would be a formalized mechanism through which window styles can be modified, and through which a window could indicate to a client application what styles it will allow to be changed. For instance a WinSetWindowStyles() method would take a window handle, a set of new styles, and a relevant bits mask. It would get the current styles, weave in the new ones, and then send a message to the window telling it the new styles (WM_NEWSTYLES perhaps.) The window would look at the current styles and new styles, update itself with the ones it would accept, and return to PM the changes it could do. PM would return these to the client code. The update would be as efficient as possible since the window would know what parts of itself were affected.
In Reality
However, there is no such thing in PM. To a PM window, its styles are just a set of bit flags put into a predefined place in the window's extra data words (see Window Extra Data below.) During window creation, PM will place the styles (passed to WinCreateWindow) into this area. After that, there is no formalized usage of the styles flags. Each class of window is free to do one of 3 things.
Many simple window classes can work purely on the first 'stateless' principle. On each paint it just looks at its current styles and paints accordingly. For these types of windows, the window styles can be easily modified by extracting the current styles, modifying them as desired, putting them back, and invalidating the whole window (unless you know for a fact that only a particular area of the window is affected and can successfully calculate it.) This is obviously less desirable than the perfect world, since often this scheme will cause gratuitous repainting which is unsightly and wasteful of CPU time. But at least it can be done.
Some window classes only look at certain styles once at creation and then never bother to check them again. The most obvious example is when a particular window class can optionally create child windows (such as scroll bars.) Once those scroll bars are created, there is no real reason to look at those styles again, at least from the window's perspective. One reason for taking this approach is the very lack of a formalized mechanism for updating styles. For most controls, the only thing they can really do is look at the styles during a paint. But, for doing things like creating/destroying/moving child controls and whatnot, the paint event is not a very good place to do such things.
Frame Controls
Unlike normal window styles, frames do have a formal mechanism (separate from the window styles system) for addition and subtraction of standard frame controls. So, for the most part, you can cause them to come and go as you please. You just need to destroy unwanted ones or create new desired ones and then send a WM_UPDATEFRAME message with bits on for the controls you deleted or want added. Be sure to give them the correct FID_XXX window ids and make the frame their parent and owner, though some frame controls are not separate windows and have no id.
Confusingly enough, the frame window class has styles for most of the frame controls; but, you should only use them from a dialog resource (or so the documentation states.) When creating a frame via WinCreateStdWindow() or WinCreateWindow(), you should use the FCF_xxxx values. These are passed in via a FRAMECDATA structure as the window control data.
Copyright Notice
| Reply to Author
| Search
| Section Index
| Next Page
If you see a problem with this web site, contact
edm2_eds@iqpac.com.