This means it does not reset to initial state, but use the one active before Draw() was called.
Of course. It is totally expected for me. If I set the highcolor outside Draw(), then I expect it to be still active on the next Draw().
Sure it will. As Axel said, we're not talking about the high color, but about the graphics states that are used(pushed). Draw() is the method which shows us what that view is all about. It "gets" a "palette" and starts drawing. I seems odd to me (and maybe Axel) that there are other "pallets" which are active, when the "artist" should begin its master piece with a blank sheet of paper, a brush and a "palette".
Still, there is a catch that I missed. What if the user pushes states in which he has clipping regions and when Draw() is called, maybe he wanted the update to occur only in the common region. Hmm... at what use...?
Usually I configure a view in its constructor or AttachedToWindow(), and I expect it to be like this in Draw().
Exactly. That's what we're saying: the initial state, the state pushed just before Draw() and ->Draw(updateRect);
I don't know if that's good or bad... we have to decide.
I would rather think it's bad, ie. let's not follow the path set by R5, and see how many problems that bring us :-)
As a user of the API, I always found it rather logical, that a new state inherits from the current state. Isn't it much more convenient as well? Why would you want *default* params either? And I would expect quite a few problems if we changed this behaviour.
No no... we all agree that a new state should not be defaulted. It was a mistake that I made when I wrote that method. Didn't know as much as I know today. :-P We only should default the view origin, scale and clipping region.
Shouldn't we go back to the state which was active before Draw() was called?
Shouldn't we reset to the initial state, push a state and then enter Draw()?
Same as above, I think we should aim for the cleanest solution, and if that doesn't work out, get gradually worse until it does.
That one I agree on. If the BView is ment to be in the state as before Draw(), then it really should be.
I think so too. Otherwise I don't understand why Be chose to pop state when Draw() finished.