Commenter Chris 'Xenon' Hanson points out that fiddling with the
WS_ style directly via
SetWindowLong leads to strange behavior. However it isn't the case that "most widget classes work fine." Reaching in and fiddling the style bit directly is like reaching into a program's internal variables and just changing the values: All the other work that is associated with changing the value simply doesn't happen.
It's like taking a book you checked out of the library, re-shelving it, and then going into the library computer and marking it as "returned". The bookkeeping will say that the book has been returned, but all the other processes associated with a book return has not taken place: People who had placed a hold on the book aren't notified. The "number of books checked out" counter isn't updated. (Which gets interesting when you come to the end of your senior year and the system won't let you graduate because its records say that you still have 1 book outstanding, yet when you say "Show me all the books I have checked out" it returns no records.)
In the case of windows, merely setting the
WS_ style does not generate
WM_ messages, it doesn't generate accessibility notifications, it doesn't do focus bookkeeping, all it does is set the flag and goes home. Eventually, some code will stop working because something "impossible" happened (in this case, a window transitioning from enabled to disabled without ever receiving a
Similarly, the way to change a window's visible state is to use the
ShowWindow function and not to manipulate the
WS_ style directly.
"I think I filed a suggestion on MSDN2.microsoft.com's suggestion box to advise people not to fiddle with the
WS_ flag at runtime via
SetWindowLong() since it seems like a viable route if you don't know otherwise."
Actually, the advice already exists right at the top of the Window Styles page where it says "After the control has been created, these styles cannot be modified, except as noted." And for
WS_, it says "To change this after a window has been created, use