How to return data from Modal form

  • Thread starter Thread starter Peter Hibbs
  • Start date Start date
P

Peter Hibbs

Hi All.

In my databases I often have a need to return data from a Modal form
(opened with the acDialog parameter) to the main form. I usually set
up one (or more) Global variables which are loaded with data in the
Modal form and then read back in the main form.

However, I noticed in a recent post that Albert suggested that this
was a bad, bad idea. OK then, why is that and what other alternative
is there, I've always thought that that was the whole object of Global
variables - to make data available to all forms and reports.

The only other method I can think of is to have a hidden form
permanently open and copy and/or read data in text boxes on it. Surely
though, this is less efficient in terms of resources, i.e. memory and
CPU time, etc.

Now don't get me wrong, I'm not suggesting that Albert is wrong (he
obvoiusly knows a lot, lot, lot more about Access than I ever will)
but if there is some other more reliable or more efiicient method to
achieve this then I would be interested to know.

Thanks in advance for any comments.

Peter Hibbs.
 
One approach I've used is add a property (or more) to each of the forms that
might be calling the dialog form, and then pass the name of the calling form
as an OpenArgs parameter in my DoCmd.OpenForm method call. In that way, I
can check which form called the dialog form in its Close event, and pass the
value(s) back to that form.

I've also created classes that call the dialog form, and have the class take
care of passing values back.
 
Peter Hibbs said:
However, I noticed in a recent post that Albert suggested that this
was a bad, bad idea. OK then, why is that and what other alternative
is there, I've always thought that that was the whole object of Global
variables - to make data available to all forms and reports.

first, I explain why the global are bad:

* if you copy the form to another database, then you have to remember
to copy the global vars...and where the heck are they? How do you know
which vars to copy?

* for each form you build, you have to define some new vars. And, worse
those new vars have to be global in another module.

* Global are a great source of bugs if you use them to hold values for
passing between forms. if you re-use some of the vars (because of the
above pain of defining them), then you have two forms that can trip
over each other..or at the worst ONLY have one of these forms open
that uses the same global vars

So, one the "great" goals in software is that you want to be able to change
one piece of code, or one form..and not have something else go crash, or
become "buggy" due you changing your code. the goal is that in a year or so,
you can't remember all of your code, and what form uses what variables
(heck, it hard enough to know what quires use what forms, and vice versa).
So, when you eliminate dependencies on some global vars (that are defined
outside of the form), you not only make your code more reliable, but also
more-re-usable. You can freely cut/copy/paste the code, and not worry about
some global vars. You can make copy of the form, and re-name it, and use it
for perhaps additional prompts, and again never worry that the current
values of the global are NOT STILL IN USE.

I could likely write on for some considerable time here, but you see that
global should only be for global values. Global vars are NOT for passing
values. sometimes you HAVE to use a global var to pass value, but when
alternative exist, you what to use those alternatives first.

So, how to pop up a form...halt the calling code....have user enter
values...return to the code?

I explain in detail here as to how to do this:

http://www.members.shaw.ca/AlbertKallal/Dialog/Index.html

So, it not really "wrong" to use global. It is just good if you can avoid
using global in your forms code, and general code. lots of globals makes
your code harder to read, and harder to maintain. And, further, if you need
to copy a form to another database, then you have to remember what global
are needed to be copied also.

So, the above shows a great way to return those values from the form. Keep
in mind that somethings are great as global (such as users name etc). So,
there is a difference between passing values between code, and that of
things that really are global. So, when you write a sub, and you need to
pass that sub values, you use the parmaters of that sub (you don't delcare
globals to pass the values for example).

I have to say it not a issue of "right" or "wrong"..but, as you develop more
code, you find those globals become very difficult to work with, and make
code hard to read, hard to maintain, and you less productive.

Try the above idea for return values. The above allows you to grab (return)
as many values as you want, and you don't have to declare global vars to
return those values.
 
If you have a Close button for the modal form, or an OnClose routine, you
can set Me.Visible=False instead of allowing the form to close. This returns
control to the calling routine. Then the calling routine can read any of the
form's properties, where you would have stored the data to be returned. This
keeps a nice degree of isolation- no global variables needed, and the modal
form doesn't have to know anything about the caller. The caller is then
responsible for closing the modal form.
Paul Shapiro
 
Thanks very much guys, and especially Albert, for the interesting and
useful ideas. I will definitely be using these methods in my code from
now on.

Peter.
 
Back
Top