Some wxWidgets Questions.

This is a discussion on Some wxWidgets Questions. within the A Brief History of Cprogramming.com forums, part of the Community Boards category; If I'm going to be painting to a window (panel, etc.) will I need to create a Member DC and ...

Some wxWidgets Questions.

If I'm going to be painting to a window (panel, etc.) will I need to create a Member DC and associate it with the window or is it okay to create a local copy in the paint event? What if it is buffered?

Also, should I dynamically allocate message boxes and modal dialogues, or have pointers and destory them at the end of their cycle.

If I'm going to be painting to a window (panel, etc.) will I need to create a Member DC and associate it with the window or is it okay to create a local copy in the paint event?

You should create a wxPaintDC stack object on the onPaint event if you wish to only paint the window during OnPaint events. When you wish to paint outside OnPaint events you create a wxClientDC stack object on those events. Check the documentation for the proper constructors and usage.

What if it is buffered?

Here is just a tad little different. You have two; wxBufferedDC and wxBufferedPaintDC.

The first is to be used outside OnPaintEvent and you simply create it on the stack after creating a wxClientDC. The constructors for the wxBufferedDC take a pointer to a wxDC object. You usually fill that in with that wxClientDC.

The latter is to be used inside OnPaint events and you simply declare it on the stack instead of a wxPaintDC.

Also, should I dynamically allocate message boxes and modal dialogues, or have pointers and destory them at the end of their cycle.

I'm drawing a blank here. But will confirm when I get home if nobody else does it in the mean time, but modal boxes should be created on the stack, modeless in the heap.

Have you ever tried wxFormBuilder, it's a very nice tool that allows you a lot of freedom with it's subclassing feature.

I decided to invest some money on wxWidgets. I bought DialogBlocks (from library author) and their Book.

I really can't stress this enough Indigo, buy the book! It's very well written. Your knowledge and understanding of this library will increase by leaps and bounds. It leaves very little to be explained. And what it doesn't talk about you rarely will have a need to use. And if you do, its on the web at the distance of a google search string. The book is the main reason why I have so much fun programming with this library. If not for it I would still be in pain.

Really, it teaches you from the perspective of the source code. No layout aiding software is assumed.

Let me tell you however that I don't suggest you rely too much on wxFormBuilder. DialogBlocks is, in my opinion, superior and I still don't. I only use these type of tools (and I used them extensively on other environents like WYSIWIG web editors) to design my dialogs and windows. Then I move them away and rename variables, tweak the code, change it if I need to, and such. You'll end with a more robust and simpler code structure.

Only use them for what otherwise would be the boring part of visual design. After that, you want to take control over your own code and not have any tool tell you how you should program.

Well you kind of have to with wxFormBuilder. It only lays out the windows, then you have to use the inhereted class and implement it. Codeblocks has a project generator for it so you just generate the files, lay it out, and then go in and handle the advanced properties and events.