by Cal Locklin and Bill Warner
Editor's note: The three lists are pulled from actual data (each list could be from a different table). This allows the user to select even the mis-spelled names. Many bad state abbreviations are visible
and all cities prior to Aaron are incorrect and/or start with a blank
space (although a filter could easily be used on the data). Buttons are provided to select commonly used dates. This
makes data entry faster, and also reduces typing errors. Horizontal scrolling was used for zip codes and city names,
because that method fit the overall layout better. Can be transmitted as a text file to other users. Can be compiled into an AEX file. Can be saved in the Code Library. No underlying table required, so it can be used across multiple databases. Loads faster than a form. Display multi-select and/or multi-column list boxes. Align objects easily.1 Change background/font colors easily; change font sizes/styles easily. Permit direct data-entry into table. Use with no/minimal coding.
There was a post on the message board last month about XDialog, and some of the material below was gleaned from comments made by many Alpha users. I'd like to thank all of those that contributed to the discussion.
WHICH TO USE??
The topic of the post was a comparison of XDialog to forms (in this case, using a form as a dialog). This elicited many comments, but it became quite clear that neither is the perfect tool for
everyone. For the same reason there is Action Scripting and Xbasic, Alpha has
given us two ways to display a dialog that, in many cases, can accomplish the
same thing. However, there's much more to the story.
Forms have been around forever, and are quite intuitive. You can put all sorts of objects on a
form, and the arrange toolbar provides tremendous flexibility for moving objects
around and lining them up (see Jim Chapman's article, Tools and Techniques to
Design Your Forms). In fact, many people use forms exclusively for all their
needs, including displaying dialogs. So, why use XDialog?
SIMPLE EXAMPLE
Here is one example of a dialog that was created using XDialog that would be either very difficult or impossible using a form (to see how this was created, which only took 5 minutes using
Action Scripting, click
here):
The main feature of this XDialog that makes it
different from something that might be created on a form is that you can select
more than one name (as shown above) - and, if you change your mind, deselect one
or more names - and get an output that has all the names selected.
I won't say it's impossible to do the same thing with a form - but I'd seriously
doubt that it could be done in 5 minutes!!
MORE
EXAMPLES
This was the easy way to do it. However, just as many users
like to start with an Action Script and convert it to Xbasic so they can
fine-tune it, you can do the same with XDialog.
After building XDialog
boxes for awhile, I'd say it's about like building Xbasic. Some features
actually are somewhat "intuitive" but you have to learn them just like you had
to learn how to use arrays, pointers, etc. When I first started with Xbasic it
was often very confusing. When I first started with XDialog it was also often
very confusing. To make XDialog easier to use, I started by using the genie (as
in the example above), and thought that I would always start this way. Today I
seldom use the genie but I do have a couple "starter macros" that I use when
building a new XDialog.
While many XDialog forms can be (nearly)
duplicated using a form, a form still looks like a form and, in some cases, that
doesn't look as professional as using XDialog. In particular, this would apply
to message boxes and certain "selection" boxes. I'm currently building an
XDialog message box that basically says "no records found - make a selection
=> Show Parts for All Jobs, Skip to Misc. Parts, Cancel" (see below). Can it
be done with a standard "ui" type message box? No. Can it be done on a form?
Absolutely! Does it look as good? Not in my mind. Once again, other users might
disagree, but this is the beauty of having two tools at our
disposal.
Here's another example that shows the tremendous
versatility of XDialog (this, as you might guess, took considerably longer than
5 minutes!):
Play a Flash
demo of the query dialog in use: Query Demo
Some features of interest:
ADVANTAGES OF XDIALOG
Note that all the above advantages make XDialog very portable.
ADVANTAGES OF FORMS
EXAMPLES OF SAVED XDIALOG ROUTINES
I have numerous generic XDialogs saved;
typically as functions. Some of them are:
- view_crlf() - just for
viewing crlf strings - mostly a development tool.
- xd_get_list_crlf() -
a generic XDialog for selecting from a crlf list. This is also often used as-is
and also as a starting point for something more specific.
-
xd_m_get_list_crlf() - you guessed it - a generic multi-select list.
-
AIMS_get_crlf_list() - similar to ui_get_list() but allows for 0, 1, 2, or 3
lines of header text and input list is a crlf list (unlimited length).
-
AIMS_Get_text() - similar to ui_get_text() except it allows for longer prompt
messages.
- AIMS_get_date() - I don't like ui_get_date() because it
doesn't automatically add the separator between day/month/year and doesn't give
the user a pop-up calendar. The ui_get_date_calendar() function provides a popup
calendar but no place for touch-typists to enter a date manually - which is
actually faster in many cases. The examples below use the same XDialog with
different input strings for the prompt (note that the box automatically resizes):
- Warning_msg() - A generic warning message using a developer
defined prompt via a crlf string similar to the above date routine.
-
Admin_chg_users() - a modified version of the built-in dialog for changing user
settings in password protected applications. It does not allow them to add
groups because the groups need to be worked into the coding of the scripts - at
least in some cases - therefore adding new groups would be a waste of time (and
could be confusing) unless the application was also modified.
My opinion: This is a tool that many Alpha users could find to be very helpful.
It's interesting to note that Alpha actually didn't develop XDialog for us; they
developed it for themselves and simply made that same capability available to us
as users.
For anyone interested, below are my two most used "XDialog
starter" macros:
---------------------------
dlg_text = <<%dlg%
{ysize=.3}{units=F}{sp};
{font=MS Sans Serif,12,b}This is a header line.{font=MS Sans Serif,8,n};
This is a {font=MS Sans Serif,8,b}bold {font=MS Sans Serif,8,n}test.;
{line=1,0};
<*15OK> <15Cancel>
%dlg%
DIM dlg_result as C
dlg_result = ui_dlg_box( "", dlg_text, <<%code%
%code%)
'Note: As noted on a message board posting, I actually use a function of my own
'called xd_set_fonts() which is a generic function that resets the font face
'and size so that I can quickly change them if I wish. The above example uses
'the standard MS Sans Serif font for the sake of simplicity.
----------------------------
DIM dlg_result as C
DIM dt1 as D 'That's dt[one] not dtL.
ok_pressed = .F.
dlg_result = ui_dlg_box( "TITLE", <<%dlg%
{ysize=.3}{units=F}{sp};
[%DATE;P=popup.calendar(dtoc(dt1));I=popup.calendar%.16,1dt1!dt1_*];
{line=1,0};
<*15OK> <15Cancel>
%dlg%,<<%code%
IF left(a_dlg_button, 4) = "dt1_"
IF a_dlg_button = "dt1_killfocus"
dt1 = ctod(dtoc(dt1))
END IF
a_dlg_button = ""
END IF
IF a_dlg_button = "OK"
'To use this, the "OK" button must be the default - ie, start with "*".
IF .not. (alltrim(ui_dlg_ctl_current("TITLE")) = "<*15OK>")
a_dlg_button = ""
sys_send_keys("{tab}")
ELSE
ok_pressed = .T.
END IF
END IF
%code%)
'Another note: Alpha has added a new method for using the Enter key in v6. I just
'haven't updated my routine yet - then couldn't find the method when I looked for it.