51 Dialogs 1. Premise and Code.
From: zavpublic-spamblock-mac.com
Subject: Re: [DIRECT-L] UI framework code. Dialogs 1. Premise and Code.
Date: February 5, 2007 9:55:23 PM CST
To: DIRECT-L-spamblock-LISTSERV.UARK.EDU
Reply-To: DIRECT-L-spamblock-LISTSERV.UARK.EDU
At this point, I would like to think that it has has been demonstrated that we've got something good here. But so far, most of what has been done has shown what I like to think of as "simple" functionality. As you have seen, this is not simple at all but we all know that there are much more complex types of UI elements that need to be implemented in Director. It would be nice if it worked with what I've already proposed and in the spirit the previously demonstrated code.
You might think that this is an odd time to propose tackling dialog display but as you will see, a dialog is a complex element that may contain other elements. We need to get used to this while seeing a little more of the power enabled by these UI controls.
As anyone has seen who has tried to work with built in MUI Dialogs, creating dialogs is a pain in the ass. It's hard enough to get them to do what you want and to think that you can define them in one line of code is not fair to the user.
But how are we going to create fully featured dialogs with the look that we want in a way that works with everything else laid down? In specifying the contents for a dialog, we actually know what we want. It's mostly the ability of drawing it, putting everything else on hold and putting the proper scripts in the proper places. Oh, and of course, doing what you want when it is dismissed and restoring control to all the things that were put on hold. But that's really it. To start, we have two really good things going for is. One is that Director is really pretty good at displaying stuff. Two is that we have this code library with the capability for us to ask it for all of its stuff and the ability for us to tell it to disable all of said stuff.
Hmmmmm.
Since Director is so good at displaying stuff we tell it to, and we know the stuff we want to display, AND we can temporarily turn off all the UI when we want to, we could build a list or two of stuff to display, how to display it, what script to put on it and build a display mechanism that would do the following:
- Get a list of all enabled clickable items
- Turn them off
- Get the lists of stuff to display and how to display them
- Pass those lists through a displayer
- Hang out till the dialog is closed
- Reenable all the UI elements that were disabled.
- Bask in the glow of our resplendent accomplishments.
- Turn over lest we get glow lines
That's the plan. But um, if we are going to be dynamically displaying and undisplaying all this stuff at will, it would be useful to know some part of the score that is unoccupied. We can do this be finding the last used sprite and adding one. Then, the list of stuff to display could be passed through a sprite server and pumped out to the screen on demand. Sweet.
Now that we are going to be allocating sprites into unused channels, we'll have to set up a number of properties for those sprites we are about plop graphics into. The sprite properties we are going to need to set are the following:
- member
- location
- scripList
- Ink
- blend
This means that we will need to set up lists to specify these properties for all items displayed. At this point, it is good to note that now it a god time to take note of all the elements that will make up your dialog. At the very very minimum, you have a background, an OK button graphic and an OK button mask. Most dialogs have other stuff in them, like text and graphics, so it's good to write down all the things that will make this up.
In thinking of a code structure to handle this collection of data, it seems like a great choice for some inheritance where we can declare the basics and override it with our specifics. Looking at all the sprite properties we would have to set, a generic parent script would look something like this:
Script: Generic Dialog Class
property pElementMemberList
property pElementLocationList
property pElementScriptList
property pElementInkList
on new me
return me
end
on GetNumberOfElements me
return count(pElementMemberList)
end
That's it. Then for each dialog, we'd create a class that inherits that and sets it with our specifics. So in the absolutely minimal dialog I mentioned before, we'd have something sort of exactly like this:
property Ancestor
on new me
me.ancestor = new(script "Generic Dialog Class")
Init me
return me
end
on Init me
me.pElementMemberList = [:]
addProp me.pElementMemberList, #background,"Dialog Background"
addProp me.pElementMemberList, #OKButtonGraphic, "OK Active"
addProp me.pElementMemberList, #OKButtonMask, "OK Mask"
me.pElementLocationList = [:]
addProp me.pElementLocationList, #background, point(0,0)
addProp me.pElementLocationList, #OKButtonGraphic, point(50, 42)
addProp me.pElementLocationList, #OKButtonMask, point(50, 42)
me.pElementScriptList = [:]
maskSpriteScriptList = []
add maskSpriteScriptList, "Button sprite specific subclass - sprite - 1"
add maskSpriteScriptList, "Register/Unregister button based on name of the button graphic"
add maskSpriteScriptList, "Change cursor on rollover to hand"
add maskSpriteScriptList, "Dismiss Dialog"
addProp me.pElementScriptList, #background, [] --["Event Filter for Dialog backgrounds"]
addProp me.pElementScriptList, #OKButtonGraphic, []
addProp me.pElementScriptList, #OKButtonMask, maskSpriteScriptList
me.pElementInkList = [:]
buttonMaskInkList = [ 8: [ #blend:0 ]]
addProp me.pElementInkList, #Background, 32
addProp me.pElementInkList, #OKButtonGraphic, 0
addProp me.pElementInkList, #OKButtonMask, buttonMaskInkList
end
The key factor to remember here is that we are displaying a dialog where we are tossing in clickable items that can be from this code library. And in this library, clickable buttons are invoked on a Success event. Therefore, we need o create behaviours that have a Success handler in them where the call we want teh button to do when clicked. Also, dialogs dismiss when their ok, cancel or close buttons are clicked. It is important we close the dialog in these cases so we'll also need a behavviour that has a Success handler that calls DismissDialog. It's also good to execute this AFTER doing what the button is sposed to do. For simplicity's sake, the scripts are specified above by their member name so it is fitting that you create properly hamed behaviours to do what you want so they can be placed on the buttons in your dialogs.
Now, dialogs are a pain to lay out, and by looking above, I'd suspect that specifying all the coordinates for all the dialog items would be even twice the pleasure. It would be cool if you could lay out your dialog in a portion of the score and them type something in the Message window and have the code skeleton of the dialog generated for you. It's called MakeDialog and It's already done for you.
With all of this conceptual meat out of the way, I'd expect that you just might want to see this in action with all kinds of juicy source code that builds right on top of everything we've already done?
Well, OK then.
Buttons to display dialogs are in the middle of the screen. Dialog scripts are near the end of the cast. Enjoy.
- Zav
---
Macromedia Director Mailing List (Direct-L)
List Administrator: Eve M. Owens (emowens-spamblock-theserver.uark.edu)
To SUBSCRIBE or to UNSUBSCRIBE go to
and click on
"Join or leave the list (or change settings)"
For list archives
Learning Zav’s Libraries
