This is what I meant when I said:
You can wrap the whole thing up in a function, which takes the message
and
button captions as arguments and returns the value of the selected
button.
It's not really a "class object" as such, but neither is the MsgBox
function provided by VB. The constants that are provided (vbYesNo,
vbCancel, etc) are defined in Enum statements in the VBA object library.
If you open the object browser in the VBE window and search for vbok, you
will see there are two Enums, VbMsgBoxStyle and VbMsgBoxResult, which
define the values you can pass to the MsgBox function and the values which
may be returned by it.
You can define your own Enums for these values, and include as many
different styles and return values as you like. It is then up to your
form to interpret those values.
You still have the problem of passing all the different options to the
form (not just which buttons to show, but also the message text and window
title text) and of retrieving the return value (which button was clicked).
Albert's article shows how to make the dialog form invisible instead of
closing it, so that your calling code can extract data from the form
before closing it. However, this does not solve the problem of passing
data *to* the form. In simple cases this is best done via the OpenArgs
property, but with multiple arguments of different type it can become
messy. One general way is to use a global collection of collections,
where the key of the global collection is passed in OpenArgs and the child
collection under that key contains the arguments. However, in this case
where you will be using the function over and over again, I think global
variables are the best way to go.
--
Good Luck!
Graham Mandeno [Access MVP]
Auckland, New Zealand
SleeplessTexas said:
That is a valid approach I could take regarding this issue but isn't
there a
way to 'CLASS' type vbObjects just as we do when writing VBA code for a
MsgBox where you can select within the arguments for example: vbYes/No
or
vbOK/Cancel? There is got to be a way I can create a class-type object,
then
reference it...e.g., MsgBox("Do you wish to 'Upload' data
now?",vbUpload/Cancel + vbExclamation,"Utilities")...so in essence the
client
would see two cmdButtons that displays 'Upload Data' and 'Cancel'
Graham Mandeno said:
You will need to create your own modal popup form. On it you can put
locked
and disabled textboxes to display the message/question and a the maximum
required number of buttons. When the form opens, fill in the
textbox(es)
and the captions on the buttons, and hide the buttons which are not
required.
The only tricky part is getting the variables to the form, and then
getting
the result (which button was clicked) back to your calling code. The
easiest way is to use a bunch of global variables. Load up the
variables
with your message text and button captions, then open the form (with
WindowMode set to acDialog). The form's Load event procedure can take
the
values from the global variables and set the texts up appropriately.
Each
button can set the value of another global variable (the return value)
and
then close the form. Your calling code can then use the return value as
required.
You can wrap the whole thing up in a function, which takes the message
and
button captions as arguments and returns the value of the selected
button.
--
Good Luck!
Graham Mandeno [Access MVP]
Auckland, New Zealand
message
My clients prefer to see command buttons that describe a specific
action
to
take, for example: if the MsgBox ask you whether or not you want to
upload
your submitted data, then the button caption would display "Upload
Data"
and
"Cancel Process" as opposed to vbYes/No ="Yes" and "No" etc.. Would I
have
to create a CLASS MODULE and/or 'TYPE' declaration with certain
variables?
I've tried to research this topic but it seems that I can't find
anything
regarding this issue....