- Forum
- Windows Programming
- Dialogue-based vs. Frame-based
Dialogue-based vs. Frame-based
Hello everyone!
I want to start implementing my win32 console program in a win32 API project. I'm using Code::Blocks with mingw and it's asking me whether I want to go with frame-based implementation or dialogue based. My program interacts with the user i.e. accepts text input and displays output, plus, I'm using Charles Petzold's book on the side, and his code seems kind of frame-based.
Which of the two is easier to work with? And what should I go for?
Any help is appreciated!
I want to start implementing my win32 console program in a win32 API project. I'm using Code::Blocks with mingw and it's asking me whether I want to go with frame-based implementation or dialogue based. My program interacts with the user i.e. accepts text input and displays output, plus, I'm using Charles Petzold's book on the side, and his code seems kind of frame-based.
Which of the two is easier to work with? And what should I go for?
Any help is appreciated!
Dialogs are easier to create for very rudimentary apps (for example, just something that you want to do some processing at the click of a button, and nothing more), but for anything more than that, I'd avoid them like the plague. I personally don't use dialogs at all. I code everything with CreateWindowEx().
See the deal is, dialogs make use of something known as the 'Windows Dialog Engine'. There is an internal registered window class for dialogs, and it uses a modified window procedure with different messages than a standard window procdure.
The problem comes in where beginners try to get off easy and use the Windows Dialog Engine for apps that should really be RegisterClassEx() / CreateWindowEx() apps. They save a little time at first, then run into excrutiating difficulties. Seen this happen countless times.
See the deal is, dialogs make use of something known as the 'Windows Dialog Engine'. There is an internal registered window class for dialogs, and it uses a modified window procedure with different messages than a standard window procdure.
The problem comes in where beginners try to get off easy and use the Windows Dialog Engine for apps that should really be RegisterClassEx() / CreateWindowEx() apps. They save a little time at first, then run into excrutiating difficulties. Seen this happen countless times.
| freddie1 wrote: |
|---|
| They save a little time at first, then run into excrutiating difficulties. Seen this happen countless times. |
May I ask what is the reason for that?? You said that dialogs uses a modified winproc, I wonder what modification that is..
Last edited on
I'm really a beginner in win32 API, and I would hate to break to MFC just because frame-based programming is bugging me at the moment. So I'll work with dialogs now, I believe those are the ones which you have an entire resource file for.
In both cases, it's not an easy thing to work with when you got minimum time on your back, and when your knowledge of the API is zero!
Anyway, I'll keep you guys posted for help.
Thanks!
In both cases, it's not an easy thing to work with when you got minimum time on your back, and when your knowledge of the API is zero!
Anyway, I'll keep you guys posted for help.
Thanks!
About all I can say Tony is that coding is a very intensive activity, and does take a lot of effort. If you don't have much time to work on it then some type of shortcut or easy application development environment is probably best. When I started with Windows programming in the mid 90s it was with Visual Basic 4. In that environment you were provided with a start up window without having to do anything whatsoever. No WinMain()s, no WndProcs, nothing. It was that easy. Its called RAD, i.e., 'Rapid Application Development'.
If you take a look at the code auto-generated by Code::Blocks for a 'Dialog' based GUI program you'll note its considerably less than for a 'Frame' based program. Note however that what passes for a Window Procedure isn't a window procedure at all but a 'Dialog Procedure'. The real Window Procedures for dialogs are inside Windows. You'll also note some of the messages are different. There is a WM_INITDIALOG message instead of a WM_CREATE message. Also, there is no registration of a window class nor a message pump. All this is within windows.
If you are content writting one window applications such as the template produced by Code::Blocks, and the structure of your window is quite simple, i.e., just push buttons or combo boxes and so forth, then it might work best for you to just use dialog boxes for a 'Main Program'. Where it seems that the problem comes in from my experience is that its so easy to produce a GUI this way, once someone does it they decide this is all there is to it and start trying to create more complex applications out of dialog boxes. In other words, they try to do fancy keyboard navigation, they want scroll bars, multiple forms, so on and so forth. That's where the trouble comes in. Truth be told, all these things can indeed be done with dialog boxes, but it soon becomes one hack after another, and it becomes more complex than just using a proper RegisterClass() /CreateWindow() setup, i.e., a standard Windows SDK style app.
If you take a look at the code auto-generated by Code::Blocks for a 'Dialog' based GUI program you'll note its considerably less than for a 'Frame' based program. Note however that what passes for a Window Procedure isn't a window procedure at all but a 'Dialog Procedure'. The real Window Procedures for dialogs are inside Windows. You'll also note some of the messages are different. There is a WM_INITDIALOG message instead of a WM_CREATE message. Also, there is no registration of a window class nor a message pump. All this is within windows.
If you are content writting one window applications such as the template produced by Code::Blocks, and the structure of your window is quite simple, i.e., just push buttons or combo boxes and so forth, then it might work best for you to just use dialog boxes for a 'Main Program'. Where it seems that the problem comes in from my experience is that its so easy to produce a GUI this way, once someone does it they decide this is all there is to it and start trying to create more complex applications out of dialog boxes. In other words, they try to do fancy keyboard navigation, they want scroll bars, multiple forms, so on and so forth. That's where the trouble comes in. Truth be told, all these things can indeed be done with dialog boxes, but it soon becomes one hack after another, and it becomes more complex than just using a proper RegisterClass() /CreateWindow() setup, i.e., a standard Windows SDK style app.
Topic archived. No new replies allowed.