0035 – Dialogs I - The About Dialog
Starting today, and for the next few weeks, we’ll be looking at
Dialog windows of various types. We’ll get started with one of the simpler ones, the AboutDialog, but to make it more interesting, we’ll toss in a
Let’s get going by checking out…
These are the ones we haven’t worked with yet:
main() is the same and we’ve seen
TestRigWindow more than 30 times, and these aren’t new, either:
HelpHeader(except for the name, anyway), and
And that brings us to…
We have a ton of string tied around the initialization section and maybe that’s so the other stray items don’t wander off:
You could probably leave most of these strings empty, especially if you don’t work with a team, but I filled all these in for demonstration purposes.
But as I breezed through that list of classes that hadn’t changed, there actually was one change worth mentioning…
Passing Down the Window
AboutDialog (or any other dialog) needs to know who its mommy is, we gotta give it an ersatz family tree, passing down the
Window pointer so when the
Dialog goes up, it can go
MODAL if it needs to. If you take a quick look through the code, you’ll see this is done very much the same way we passed along the
AccelGroup in Blog Post #32 - Adding Accelerator Keys to MenuItems.
Note: if you want your
Dialog to be
DialogFlags.MODAL which can be found in
Hooking up the MenuItem
In the constructor, we do this:
Like any other
MenuItem, we instantiate and hook up the callback, but then we have one more step. We assign the local pointer to the parent Window so we can use it in the callback.
The callback is quite busy:
We need a
responseID for any dialog, even if we ignore it like we do here. As we move deeper into dialogs, we’ll come back to this variable and look at it more closely.
And there’s the
Pixbuf I mentioned. Here, it’s used to show off the gtkDcoding logo.
Then we instantiate the dialog:
AboutDialog aboutDialog = new AboutDialog();
Fill in all the fields:
Note: There may be a bug in GTK that (apparently) stops the website link from working with some operating systems. Mac was mentioned as one that falls victim to this, but it does work with Windows (it does, however, spit out a warning). I haven’t tried it with Linux.
And finally, we open it:
And the last statement doesn’t get called until the dialog closes and program control comes back to this object (the
All this does is destroy everything we built. And if the
Dialog gets opened again? The entire dialog is rebuilt from scratch.
And that was a quick look at a simple
Dialog. As we go along, things could get complicated, especially when we dig into rolling our own dialog from scratch. Now, that will be an adventure.
Until next time… bye.
If you'd like to leave a comment...
Until I get time to research and install a commenting system, I ask that you try one of these options:
- come on over to the D Language Forum and look for one of the gtkDcoding announcement posts,
- drop by the gtkD Forum,
- follow the link below to email me, or
- go to the gtkDcoding Facebook page.
You can also subscribe via RSS so you won't miss anything.
© Copyright 2019 Ron Tarrant