Calling a class' private method from a form

[ericellsworth]

Hi,
I'm trying to use a class to pass variables back and forth from a
form opened in dialog mode.
I have created a class which invokes a form in its show method, like
so:

Public Sub Show()
' This method shows the form used to get the info
If sWhereInt = "" Then
DoCmd.OpenForm sFormNameInt, acNormal, , , acFormAdd, _
acDialog
Else
DoCmd.OpenForm sFormNameInt, acNormal, , sWhereInt, _
acFormEdit, acDialog
End If
End Sub

I collect parameter values using:

Property Let SetParam(sName As String, vValue As Variant)

dParamDict(sName) = vValue

End Property

where dParamDict is a Scripting.Dictionary object which has been set on
class initialization.

I would like to define a private method (or property if necessary)
visible to the form to retrieve parameter values. All of my efforts so
far have failed.

Can anyone provide any guidance?

Many thanks,

Eric

[rkc]

er***********@gmail.com wrote:

Hi,
I'm trying to use a class to pass variables back and forth from a
form opened in dialog mode.
I have created a class which invokes a form in its show method, like
so:

Public Sub Show()
' This method shows the form used to get the info
If sWhereInt = "" Then
DoCmd.OpenForm sFormNameInt, acNormal, , , acFormAdd, _
acDialog
Else
DoCmd.OpenForm sFormNameInt, acNormal, , sWhereInt, _
acFormEdit, acDialog
End If
End Sub

I collect parameter values using:

Property Let SetParam(sName As String, vValue As Variant)

dParamDict(sName) = vValue

End Property

where dParamDict is a Scripting.Dictionary object which has been set on
class initialization.

I would like to define a private method (or property if necessary)
visible to the form to retrieve parameter values. All of my efforts so
far have failed.

Can anyone provide any guidance?

First off, just because the form is opened by code in the class does not
mean that the form has access to private methods of the class. You have
to provide a public interface to retrieve "things" from the dParamDict
object just has you had to to add "things" to it. Without further detail
of what you have tried I would say the simplest way to retrieve
parameters is to provide a public method that takes a key as an argument
and returns the value associated with the key from the dParamDict object.

If what you are after is to make the dParamDict object available only to
the form that is opened then create a similar dParamDict object in the
form's module and set it equal to the dParamDict object of the class
after you open the form.

[Albert D. Kallal]

<er***********@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Hi,
I'm trying to use a class to pass variables back and forth from a
form opened in dialog mode.
How are you going to use a dialog form? Using a dialog form means all code
STOPS and waits for the form to finish. In fact, you can't even use built in
menus here. I think you are confused between the concepts of a dialog form,
and a model form.

You can read about them here:

http://www.members.shaw.ca/AlbertKal...log/Index.html

I have created a class which invokes a form in its show method, like
so:
Ok, it is possible you understand the difference between model forms, and
dialog forms, but keeping the above in mind:


DoCmd.OpenForm sFormNameInt, acNormal, , sWhereInt, _
acFormEdit, acDialog

Keep in mind, a this point the code will wait unter the above form is
closed, or kicked out of dialog mode. If the form is closed, then you can't
grab the values from the form...can you?

You *can* expose propeites in the above form as long as you declare them as
public. And, assuming you just read my above article, then you can go:

msgbox "My Custom Properity is " & forms("sFormNameInt").MyCustomProp
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[John Mishefske]

Albert D. Kallal wrote:

<er***********@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Hi,
I'm trying to use a class to pass variables back and forth from a
form opened in dialog mode.

How are you going to use a dialog form? Using a dialog form means all code
STOPS and waits for the form to finish. In fact, you can't even use built in
menus here. I think you are confused between the concepts of a dialog form,
and a model form.

You can read about them here:

http://www.members.shaw.ca/AlbertKal...log/Index.html

I have created a class which invokes a form in its show method, like
so:

Ok, it is possible you understand the difference between model forms, and
dialog forms, but keeping the above in mind:

DoCmd.OpenForm sFormNameInt, acNormal, , sWhereInt, _
acFormEdit, acDialog

Keep in mind, a this point the code will wait unter the above form is
closed, or kicked out of dialog mode. If the form is closed, then you can't
grab the values from the form...can you?

You *can* expose propeites in the above form as long as you declare them as
public. And, assuming you just read my above article, then you can go:

msgbox "My Custom Properity is " & forms("sFormNameInt").MyCustomProp

You can kick the form (opened in Dialog mode) out of Dialog mode by
setting the form's visibility to False (typically using a command button
in the form opened in Dialog mode). This leaves the form open and its
variables accessible and allows code to continue past the .OpenForm
call in the calling code so that you can grab values and then do a
DoCmd.Close on the form.

--
'---------------
'John Mishefske
'---------------

[Lyle Fairfield]

John Mishefske wrote:

You can kick the form (opened in Dialog mode) out of Dialog mode by
setting the form's visibility to False (typically using a command button
in the form opened in Dialog mode). This leaves the form open and its
variables accessible and allows code to continue past the .OpenForm
call in the calling code so that you can grab values and then do a
DoCmd.Close on the form.

Very clever!

--
--
Lyle
--
From ADO28.chm

ODBC Provider (MSDASQL)
You are strongly encouraged to use one of the native OLE DB Providers
instead of the Microsoft Open Database Connectivity (ODBC) Provider.
Native OLE DB Providers provide better application stability and
performance. Furthermore, native OLE DB Providers will be supported in
the future, whereas MSDASQL will not have any new features added to it,
will not be available on 64-bit, and will not be accessible from the OLE
DB NET Data Provider.

[ericellsworth]

Yes, this:
----------------------------------------
If what you are after is to make the dParamDict object available only
to
the form that is opened then create a similar dParamDict object in the
form's module and set it equal to the dParamDict object of the class
after you open the form.
----------------------------------------

but how does the form actually reference that object? The object was
instatiated by the code that asked for the form, so I don't think it
exists outside that scope. That's precisely where I got hung up...

[ericellsworth]

Hi,
Thanks to all for the insightful answers...

John, you're on to something, but I can't quite fit it with what I have
in my head that I want to do which is:

-> Calling routine wants to use the form to get a value or values from
the user, and cannot properly proceed without this input (hence the
need for blocking)
-> Calling routine calls dialog form wrapper function, passing setup
parameters as arguments, or if the wrapper function is in object form,
setting properties
-> wrapper function instantiates form as dialog using
DoCmd.OpenForm, ..... , acDialog
-> form now has access to private variables of wrapper function/object,
and fetches variables into fields on form
[if I were really fancy and java-esque, I'd write a middle function
that the form used to auto-fetch anything it can get out of the
wrapper... hmmm maybe I can do that]
because the form is doing the fetching, the fact that the wrapper
function and the calling function are now blocking is not a problem, as
a you point out, the calling function unblocks when you set visiblity
to false.
-> user clicks dialog-response button (e.g., OK or Cancel), which sets
the return value in the private values of the wrapper function, then
closes the form.
-> Setting the form's visibility to false unblocks the wrapper
function, which returns the requested value.

All of this was working peachy in function form until I needed to
return multiple values, and wanted to be able to use named return
values. At that point I tried to change the wrapper function to an
object and ran into the above problems. I guess I can try return my
dictionary object as output.

Anyway, any further thoughts y'all have would be mightily appreciated.

Thanks,

EE

[rkc]

er***********@gmail.com wrote:

Yes, this:
----------------------------------------
If what you are after is to make the dParamDict object available only
to
the form that is opened then create a similar dParamDict object in the
form's module and set it equal to the dParamDict object of the class
after you open the form.
----------------------------------------

but how does the form actually reference that object? The object was
instatiated by the code that asked for the form, so I don't think it
exists outside that scope. That's precisely where I got hung up...

The dialog form gets it's own copy of the dictionary object. The
following code outlines the procedure. Notice that the form is not
opened in dialog mode, but ends up acting like it was.

<Class code>
Private dParamDict Scripting.Dictionary

Private Sub OpenDialogForm()
Dim f As Access.Form
DoCmd.OpenForm "frmDialogForm", acNormal
Set f = Forms("frmDialogForm")
Set f.ParamDict = dParamDict
f.Modal = True

Set f = Nothing

End Sub

</Class code>

<Dialog form Code>
'set the form's Pop up property to true in the property sheet
'set the form's Border Style to Dialog in the property sheet

Private m_dParamDict As Scripting.Dictionary

Public Property Set ParamDict(dParams As Scripting.Dictionary)
Set m_dParamDict = dParams
End Property

</Dialog form Code>

[Darryl Kerkeslager]

A bound form in Access is a class object already. It has:

-built in ability to display its data in a GUI
-built in events
-built in data container (bound table)
-the ability to add events
-the ability to add functions, and subs, both public and private
-the ability to add object variables and constants
-persistence
-easy referencing through the Form() object

Why use anything else?

Darryl Kerkeslager

[ericellsworth]

That looks like exactly what I'm trying to do, and I think that would
work nicely with the idea of the form automatically getting any values
it can from the calling function.

Only one key problem:

Setting form to modal does not cause the calling code to block.

Here's a timer after each statement:
Time started 2/9/2005 6:29:52 PM
Time after opening form 2/9/2005 6:29:52 PM
Time after set modal 2/9/2005 6:29:52 PM
(waits a couple seconds to close the form....)
Time form closed 2/9/2005 6:30:03 PM

To be honest, the lack of proper code blocking is a missing feature in
Access I've run up against a lot. I've seen people suggest that you
have the post-block code be fired by a on-close event of the form, but
I really don't like this because it means you have to unnaturally
segment your functions around places where you might want blocking
code.

Last time I tried using DoEvents and Sleep I got a fair bit of
crashiness - perhaps this has improved in Access 2003?

[ericellsworth]

Blocking. The only effective way in Access (AFAIK) to cause code
execution to block is either to use MsgBox or open a form as dialog.

Plus, part of what I'm trying to do is abstract a
"getInformationFromUser" function of class that is not specific to the
form used to do so.

Any ideas on making code block?

[rkc]

er***********@gmail.com wrote:

That looks like exactly what I'm trying to do, and I think that would
work nicely with the idea of the form automatically getting any values
it can from the calling function.

Only one key problem:

Setting form to modal does not cause the calling code to block.

By block do you mean suspend? I don't see why you need the code
to wait for anything unless getting the dictionary object to the
dialog form is not all you wanted to do. You do realize that any
changes made to the dictionary object by the dialog form will be
reflected in the calling form.

[ericellsworth]

Sorry, didn't realize I was being unclear. By blocking I do mean
suspend execution of code. Your point that since the dictionary object
on the dialog form and the on in the calling function are the same they
have the same values is well taken.

I guess that might make it work. I'll try passing a dictionary object
with my parameter values...

Thanks,

EE

[rkc]

er***********@gmail.com wrote:

Sorry, didn't realize I was being unclear. By blocking I do mean
suspend execution of code. Your point that since the dictionary object
on the dialog form and the on in the calling function are the same they
have the same values is well taken.

I guess that might make it work. I'll try passing a dictionary object
with my parameter values...

There's also the WithEvents keyword whereby the calling object can
subscribe to the dialog form's Close event and run code in the calling
class when the dialog form closes. That gives you the same 'blocking'
affect as actually opening the form in dialog mode via docmd.openform.

[John Mishefske]

er***********@gmail.com wrote:

Blocking. The only effective way in Access (AFAIK) to cause code
execution to block is either to use MsgBox or open a form as dialog.

Plus, part of what I'm trying to do is abstract a
"getInformationFromUser" function of class that is not specific to the
form used to do so.

Any ideas on making code block?

Other than opening the form with the acDialog option that I mentioned
in my previous post you could cycle waiting for the form to close:
Const conObjStateClosed = 0

DoCmd.OpenForm "frmReportsOutput"

Do While SysCmd(acSysCmdGetObjectState, acForm, "frmReportsOutput")
<> conObjStateClosed
DoEvents
Loop
Note that one of the lines wrapped. Beyond these two examples you'll
have to investigate the Win Sleep() API (there is one of those
isn't there? or am I thinking of BSD??).
--
'---------------
'John Mishefske
'---------------