Yes No Dialog - REVISITED

I understand based on the flow in a Web App message dialogs (similar to a Yes/No MsgBox on a desktop app) don’t work the same. I actually like the slide down dialogs to communicate with the user since the background screen is “dimmed down” and forces focus on the new dialog.

My initial solution was to set a Session Property before opening the dialog and based on clicking the YES or NO in a dialog I would run specific code based on the Session Property. While this works it gets pretty “ugly” as the app grows in complexity because of the number of choices.

Is there a better way to structure things to make this easier?

Why not set a property on the Dialog of whether Yes or No was clicked (I usually use a boolean for simplicity) and then use AddHandler to direct the Dismissed event to a method based on what you’re asking. In the method you could say:

If dlg.confirmed then // do the Yes action end if

Roll your own method ?

The trick is realizing that the Dismissed event fires when the dialog is closed and that you can inspect to see what was pressed.

OK … The Dismissed Event helps a little by consolidating where to check for all of the user button clicks all in one place
** BUT **
What I was hoping to avoid was having several different Webpages use the same YES/NO Dialog and that dialog have code in it to do work where it was called from multiple Webpages. The code for YES on Webpage1 is different than Webpage2. My technique has been to set a session property and use it in the called dialog to know where it was called FROM. I would end up with either a CASE statement or a series of IF / ELSEIF statements. After a few it gets pretty messy.

To get the “my standard” YES/NO Dialog on a Webpage I just drag it from the object list on the left.

The simple solution would be to duplicate the YES/NO Dialog for each Webpage that uses it but that does not seem like a great idea either but it would be much cleaner.

** Am I missing the point ?? **
In the “object world” can I do something like sub-class the original YES/NO Dialog and create a new instance that is used only on one Webpage and add code in the Dismissed Event that is private to that instantiated version of the YES/NO Dialog?

Did I say all of that correctly?

If it can be done would this really be any better than just duplicating a YES/NO Dialog to be specific to one Webpage?

I can’t say I am a huge OOP fan so I don’t spend much time trying to “force fit” OOP features but this seems like a good reason to use it if it would work this way.

Create a subclass of modal dialog (or sheet dialog) in your app (drag one from the library all the way across to the navigator)
add whatever buttons etc you need

if its just yes no then you can just put a property on the dialog that is “DidPushYes as boolean” and make its action just be
DidPushYes = true
self.close
and the NO button just
DidPushYes = false
self.close

now drag that new subclass on to your web page
now you can implement the dismissed event on that specific page and you can look at that instance property - DidPushYes

you have access to whatever was on that page - no session variables required etc

This is what I’m thinking of http://great-white-software.com/miscellaneous/webdialog.zip

If you use the MonkeyBread plugins I have a WebDialog that displays the question then runs a Method (e.g. doDeleteUsers) on any window/container (usually self) using the Call CallMethodMBS(myWebPage, myMethod) command. I just drop the WebDialog onto any window or container, rename it, then call it where needed.

You call it like this:

YesNoWAD.doCreateDialog(self, "doDeleteUsers", "Are you sure you want to delete all the data from the Users database?")

It does the Show command for you, you have the option of giving it a message (like above) and you can even set the Yes/No captions if you don’t want them as Yes/No.

Please feel free to download it from:
http://www.webappdevelopments.com/HMSDownloads/dlgYesNoWAD.zip

David,

The link is broken to your example. Is it still possible to get a hold of it?

Thanks

Here it is again. I’ve put it into a sample WebApp as a demo:

This is what it looks like:

FWIW, I’m not a big fan of Yes/No dialogs. It’s very Microsoftish and unless the question is extremely clear it can be awkward to understand. I prefer to have Actions in my buttons. In the above example I’d prefer “Continue” and “Cancel”.

The code is then like this:

Dynamic Dialogs:

Static Dialogs:

FWIW, this example (as well as over 200 videos) is included as part of our Training Video subscriptions at http://xojo.bkeeney.com/XojoTraining/

not to help at all with the code, but i would think that

Yes /No fits better with the question “Are sure you want to perform…”

Confirm/Cancel fits better with a statement not a question. “A Dangerous long running process is about to start which cannot be undone.”

I adhere to the principle that most people don’t read dialog text. But they do read button text. The above is poor example but if I was doing a “Delete” method I would do something like this:

Confirm Deletion?
You are about to delete ‘x’. Do you really want to do that? This action is undoable.

Delete, Cancel

And if I’m doing this on a desktop app I make the Cancel the Default button so people just can’t hit return (unless it’s common to do that then I flip them). Harder to do that on a web app.

But then this is the Mac way of doing things. Windows apps have a lot of the yes/no/cancel options. I’ve never liked them for a lot of reasons. I prefer to have actions for the button text.

In the YesNoWAD.doCreateDialog() method you can pass on other values (e.g. languages) for the default Yes and No. I use these dialogs whenever the user is going to delete something — that’s why I also mention that it cannot be undone (to help wake them up)!

Sure, I get that. I’ve just seen some convoluted dialog statements that I’m not sure whether answering yes is good or not. I’ve even seen some folks go the extreme of explaining what Yes and No means in the dialog text. If you need that then you should really use the action words. Again, this is going under the assumption that most people are too lazy to read the text.