priyank_bolia wrote:Sorry to say, but some of your initial remarks makes me to assume that you want all the current applications to break and removed support for window and make wxWidgets instead of cross platform just another linux graphical library. Or all windows users (whom you call minority) to learn again another programming language. wxWidgets similarity to MFC is just a great reason windows people adopt wxWidgets, only the intial starup time was large at my time, because there was no proper article about that, but once I had everything in place, the road ahead was very smooth as only the classes name were different, rest a lot was the same. I guess my article and wizard will help to decrease that initial learning curve too.
I don't remember asking to remove support for Windows? And did I ever try to call windows users a minority? Where are you coming up with that stuff?
wxSize, wxRect, wxPoint argument - thats the ease
I don't know what this means.
wxWindow::SetOwnBackgroundColour- even is the API is faulty we have to go by the way the environment does it, and not device our own standard.
The envorinment? What envorinment?
GetUpdateRegion and point are differnt things and used differently in real situations.
Again, I don't know what you are trying to say.
No, why can't you have a derived class which does it own painting, and it scrollable for very large pictures.
Put a picture into a wxScrolledWindow, like you are supposed to do anyway
wxWindow::ClearBackground, because windows people are used to override the erase background handler for flickr removal and when they need to erase the background, I think thats the choice given.
Whats the point in overriding erase background to remove flicker if you are just going to call a function which induces flicker in your application?