By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,759 Members | 1,778 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,759 IT Pros & Developers. It's quick & easy.

Strategy for form instantiation: is it a good idea?

P: n/a
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub
Nov 13 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
I have seen few cases where it was useful to instantiate a form from code,
and those only when multiple copies of the same form were to be displayed
concurrently. The simple way is often best... and the simple way is to
design your form and set its properties in design view, then use
DoCmd.OpenForm to open the single copy that is usually all that is needed.
Access is not your typical programming language that is code intensive, and
that is one of its very strong points.

If there's followup to this thread, I hope someone can pick it up, because I
am going to be out of the newsgroups for several days.

Larry Linson
Microsoft Access MVP
"Raposa Velha" <jm******@hotmail.com> wrote in message
news:69**************************@posting.google.c om...
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub

Nov 13 '05 #2

P: n/a
rkc
Raposa Velha wrote:
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.


Yes.
What's the point?
Nov 13 '05 #3

P: n/a
You have discovered one of the many limitations of the technique of
instantiating forms using the New keyword. In general, you can find another
way to do the same thing, and avoid the problem.

In the rare cases when the techniquer really does add enough value to
compensate for the added complexity and instability (e.g. the form will close
if the code gets reset), at least make sure you write your code in an
event-driven manner so that you don't need your code to halt and wait for the
form to close. Instead, use events on the form to trigger the follow-up
action.

Note that you can bootstrap a form reference by having the form reference
itself, so it doesn't close when the procedure that opens it exits (the
alternative is some sort of messy open instances collection). Just make sure
the form sets its self-reference to Nothing on Form_Close, so all resources
are freed up.

On 28 Dec 2004 10:52:56 -0800, jm******@hotmail.com (Raposa Velha) wrote:
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub


Nov 13 '05 #4

P: n/a
Thanks Larry.
I see your point about keeping it simple. The main idea of this approach is
having a reusable form that would read some global variables and set some
other global variables. This is the alternative I can image for comunication
among different parts of the application with this generic form. This way,
it requires both the form and the rest of the application to be aware of
these global variables. On the other hand, the use of properties would
overcome the use of global variables.

RV

"Larry Linson" <bo*****@localhost.not> wrote in message
news:xpnAd.11836$tG3.85@trnddc02...
I have seen few cases where it was useful to instantiate a form from code,
and those only when multiple copies of the same form were to be displayed
concurrently. The simple way is often best... and the simple way is to
design your form and set its properties in design view, then use
DoCmd.OpenForm to open the single copy that is usually all that is needed.
Access is not your typical programming language that is code intensive,
and
that is one of its very strong points.

If there's followup to this thread, I hope someone can pick it up, because
I
am going to be out of the newsgroups for several days.

Larry Linson
Microsoft Access MVP
"Raposa Velha" <jm******@hotmail.com> wrote in message
news:69**************************@posting.google.c om...
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub


Nov 13 '05 #5

P: n/a
The point of commenting ofr what to be commented? :-)

"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:3J*******************@twister.nyroc.rr.com...
Raposa Velha wrote:
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.


Yes.
What's the point?

Nov 13 '05 #6

P: n/a
Hi Steve.
Good tips, thanks!
The instability argument it's a strong one, strong enough to make me give up
of this approach. A pity, because this makes the application more similar to
a set of black boxes. Actually this idea come because I wanted to use the
properties capability. The thing is if I use the DoCmd.OpenForm to open the
form, can I still set the custom properties before opening the form? After
the user presses OK (for example), it's no problem reading the custom
properties: it's just a matter of hiding the form instead of closing it.

RV
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:km********************************@4ax.com...
You have discovered one of the many limitations of the technique of
instantiating forms using the New keyword. In general, you can find
another
way to do the same thing, and avoid the problem.

In the rare cases when the techniquer really does add enough value to
compensate for the added complexity and instability (e.g. the form will
close
if the code gets reset), at least make sure you write your code in an
event-driven manner so that you don't need your code to halt and wait for
the
form to close. Instead, use events on the form to trigger the follow-up
action.

Note that you can bootstrap a form reference by having the form reference
itself, so it doesn't close when the procedure that opens it exits (the
alternative is some sort of messy open instances collection). Just make
sure
the form sets its self-reference to Nothing on Form_Close, so all
resources
are freed up.

On 28 Dec 2004 10:52:56 -0800, jm******@hotmail.com (Raposa Velha) wrote:
Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub

Nov 13 '05 #7

P: n/a
Bri

Steve,

Can you elaborate on this 'bootstrap' concept? I currently use a
variation of the 'messy open instances collection' (I use a Public array
variable that gets ReDim'd for each new instance) and didn't know there
was an alternative.

Thanks.

--
Bri

Steve Jorgensen wrote:
You have discovered one of the many limitations of the technique of
instantiating forms using the New keyword. In general, you can find another
way to do the same thing, and avoid the problem.

In the rare cases when the techniquer really does add enough value to
compensate for the added complexity and instability (e.g. the form will close
if the code gets reset), at least make sure you write your code in an
event-driven manner so that you don't need your code to halt and wait for the
form to close. Instead, use events on the form to trigger the follow-up
action.

Note that you can bootstrap a form reference by having the form reference
itself, so it doesn't close when the procedure that opens it exits (the
alternative is some sort of messy open instances collection). Just make sure
the form sets its self-reference to Nothing on Form_Close, so all resources
are freed up.

Nov 13 '05 #8

P: n/a
Bri
Raposa,

You can make a Form variable reference the form after you open it:
Air Code:
Dim frm as Form
DoCmd.Open acForm, "MyForm"
Set frm = Forms!MyForm
frm.Message= "Hello form!"
set frm = Nothing

This will not close the form when the frm is set to nothing. It will,
however, open the Form before applying the Property. This happens fast
enough that the user won't see the difference, but if there is code in
your OnOpen or OnLoad Events that depend on the Property, then those
events won't see it as it hasn't been set yet. An option to this is to
have the post Property code run in a Public Sub in the form, then you
could do this:
Air Code:
Dim frm as Form
DoCmd.Open acForm, "MyForm"
Set frm = Forms!MyForm
frm.Message= "Hello form!"
frm.MySub 'This is the Public Sub in the Form
set frm = Nothing

Hope that helps

--
Bri

Raposa Velha wrote:
Hi Steve.
Good tips, thanks!
The instability argument it's a strong one, strong enough to make me give up
of this approach. A pity, because this makes the application more similar to
a set of black boxes. Actually this idea come because I wanted to use the
properties capability. The thing is if I use the DoCmd.OpenForm to open the
form, can I still set the custom properties before opening the form? After
the user presses OK (for example), it's no problem reading the custom
properties: it's just a matter of hiding the form instead of closing it.

RV
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:km********************************@4ax.com...
You have discovered one of the many limitations of the technique of
instantiating forms using the New keyword. In general, you can find
another
way to do the same thing, and avoid the problem.

In the rare cases when the techniquer really does add enough value to
compensate for the added complexity and instability (e.g. the form will
close
if the code gets reset), at least make sure you write your code in an
event-driven manner so that you don't need your code to halt and wait for
the
form to close. Instead, use events on the form to trigger the follow-up
action.

Note that you can bootstrap a form reference by having the form reference
itself, so it doesn't close when the procedure that opens it exits (the
alternative is some sort of messy open instances collection). Just make
sure
the form sets its self-reference to Nothing on Form_Close, so all
resources
are freed up.

On 28 Dec 2004 10:52:56 -0800, jm******@hotmail.com (Raposa Velha) wrote:

Hello to all!

Does any of you want to comment the approach I implement for
instantiating a form? A description and an example follow.

Cheers,
RV
jmclopesAThotmail.com replace the AT with the thing you know ;-)

After discovering that access 2000 support form properties (I'm a
newbie, alright :-) ), I was pleased with the idea of organizing my
code with some object oriented approach. Something like:

- instantiate a form
- set form properties
- display the form
- read form properties
- do whatever required

Then I realized (at least I didn't find how) that I couldn't open the
form in a way that the procedure execution would stop until the form
is closed. With the following code, the form is displayed but the
procedure continues its execution and, when it ends, the form is
destroyed:

Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.visible=true

MsgBox f.Message
Set f = Nothing
End Sub

So I solved this problem as follows. The idea is after the form is
displayed, the procedure loops while the form is visible. The form is
made not visible when the user presses the OK in that form.
'-------- NEW VERSION of my_proc() -----------
Sub my_proc()
Dim f As New Form_my_form
f.Message = "Hello form!" ' Message it's a property I added to
the form

'The user would enter some text in a textbox,
'which the form returns with the property Message
f.Modal = True ' one can set the form to modal to have a popup
behaviour
f.visible=true
While f.Visible
DoEvents
Wend

MsgBox f.Message
Set f = Nothing
End Sub


'-------- MY_FORM PROCEDURES -----------
Private Sub btnOk_Click()
Me.Visible = False
End Sub

Private Sub Form_Unload(Cancel As Integer)
'Don't unload the form, just hide it so the properties
'are still available to the caller
If Me.Visible Then
'only cancel the unload if the form isn't hidden
Me.Visible = False
Cancel = 1
End If
End Sub


Nov 13 '05 #9

P: n/a
Bri <no*@here.com> wrote in news:oxDAd.602327$Pl.99862@pd7tw1no:
Can you elaborate on this 'bootstrap' concept? I currently use a
variation of the 'messy open instances collection' (I use a Public
array variable that gets ReDim'd for each new instance) and didn't
know there was an alternative.


Have you considered a class module, which would automatically
re-initialize the stored values when it is re-instantiated?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
rkc
Raposa Velha wrote:
The point of commenting ofr what to be commented? :-)


VBA has OOP capabilities. You can define and create your own
objects with their own properties and methods. There's no need
to rig a form up as a simple property container. If you want a
really simple property container look at the VBA.Collection object.
Nov 13 '05 #11

P: n/a
Bri
David,

I'm not that skilled at class modules, but I can't see how they would
help here. I admit that not knowing a lot about them I may not see what
might be obvious to others with more knowledge about them.

What I am doing is opening a Contact form from a Search form. I then
allow for more than one Contact form to be opened at the same time but
with different Contacts in them. This is useful when comparing two
records to see if they might be the same people and that a duplicate
record exists. (I know that this particular issue is one you have spent
a lot of time dealing with). The redimmed array global variable works
well as there are rarely a large number of forms open in the course of
the day. It does take some resources, I suppose, to hold this array of
form variables, but since only the currently open forms are holding
anything (the closed forms are set to nothing) it can't be too much.

I asked about the 'bootstrapping' as it seems a way of not having to
worry about these resources or worry about the global variable being
reset. Also, it was a bit of work to get this all to work the first time
(had to learn about several things I hadn't tried before), but now that
its done and working I don't want to rewrite it unless it can make
things a lot better (ie more stable, less resources).

Of course, if there is a better way to do it then I'd like to learn it
for next time.

Thanks,
--
Bri

David W. Fenton wrote:
Bri <no*@here.com> wrote in news:oxDAd.602327$Pl.99862@pd7tw1no:

Can you elaborate on this 'bootstrap' concept? I currently use a
variation of the 'messy open instances collection' (I use a Public
array variable that gets ReDim'd for each new instance) and didn't
know there was an alternative.

Have you considered a class module, which would automatically
re-initialize the stored values when it is re-instantiated?

Nov 13 '05 #12

P: n/a
Bri
RKC,

The original question was about multiple occurances of the same form not
about using the form as a collection. As I understood it, the properties
being set were used in the Form's Open Event to change the form for that
particular occasion (ie a generic form that is modified for several
similar purposes). The OP wanted to know if they were using a good
method for doing that.

Just to clarify things. I hope I got it right too.

--
Bri

rkc wrote:
Raposa Velha wrote:
The point of commenting ofr what to be commented? :-)

VBA has OOP capabilities. You can define and create your own
objects with their own properties and methods. There's no need
to rig a form up as a simple property container. If you want a
really simple property container look at the VBA.Collection object.

Nov 13 '05 #13

P: n/a
rkc
Bri wrote:
RKC,

The original question was about multiple occurances of the same form not
about using the form as a collection. As I understood it, the properties
being set were used in the Form's Open Event to change the form for that
particular occasion (ie a generic form that is modified for several
similar purposes). The OP wanted to know if they were using a good
method for doing that.

Just to clarify things. I hope I got it right too.


Everyone else in the thread seems to have interpreted the
question the same as you.

After reading the rest of the thread, I'm still not sure that
was the op's original intention.
Nov 13 '05 #14

P: n/a
Bri

rkc wrote:
Bri wrote:
RKC,

The original question was about multiple occurances of the same form
not about using the form as a collection. As I understood it, the
properties being set were used in the Form's Open Event to change the
form for that particular occasion (ie a generic form that is modified
for several similar purposes). The OP wanted to know if they were
using a good method for doing that.

Just to clarify things. I hope I got it right too.

Everyone else in the thread seems to have interpreted the
question the same as you.

After reading the rest of the thread, I'm still not sure that
was the op's original intention.


I'm reasonable sure, but until the OP replys back again we won't know
for sure.

--
Bri
Nov 13 '05 #15

P: n/a
Bri <no*@here.com> wrote in news:hoIAd.618275$%k.572920@pd7tw2no:
I asked about the 'bootstrapping' as it seems a way of not having
to worry about these resources or worry about the global variable
being reset. Also, it was a bit of work to get this all to work
the first time (had to learn about several things I hadn't tried
before), but now that its done and working I don't want to rewrite
it unless it can make things a lot better (ie more stable, less
resources).


The point is that you could wrap your array in a class module and
have it be self-healing, i.e., it would re-initialize itself it its
values were lost by a code reset.

Of course, it couldn't retain data that was only stored in the
previous instance of itself.

I've done this kind of thing, myself (though not using multiple form
instances -- I just wanted to give users and easy way to navigate
back to records they'd recently visited), and simply find it easier
to wrap the thing in a class module, simply because those have an
INITIALIZE event that allows me to do all sorts of things that
simply using global variables does not allow.

The other advantage is that different instances of the class module
could hold values for different purposes. Say, for instance, that
you had two different data forms that you wanted to do this with.
You couldn't use the same global array, you'd two of them, one for
each form. With a class module, you'd write the code to handle
multiple instances of any form, then initialize a class instance for
each of the two forms.

As you can tell, I'm a big fan of class modules.

But you're right, they might not help you here.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #16

P: n/a
Bri
David,

I keep hoping to find an excuse to create my first class module so I can
learn more about them. Reading about them isn't the same as getting your
feet wet by doing one. I can see that they offer a lot, but they do
require a different viewpoint while coding that I haven't completely
grasped.

As for making code 'self-healing', I've started wrapping global
variables in Public Properties, ala Michka, and that seems to be a
fairly simple solution to code resets. So, if I was to put all of my
globals into one class I could reinitialize all of them together after a
reset?

--
Bri
Still hoping that Steve comes back with more info on 'bootstrapping'.

David W. Fenton wrote:
Bri <no*@here.com> wrote in news:hoIAd.618275$%k.572920@pd7tw2no:

I asked about the 'bootstrapping' as it seems a way of not having
to worry about these resources or worry about the global variable
being reset. Also, it was a bit of work to get this all to work
the first time (had to learn about several things I hadn't tried
before), but now that its done and working I don't want to rewrite
it unless it can make things a lot better (ie more stable, less
resources).

The point is that you could wrap your array in a class module and
have it be self-healing, i.e., it would re-initialize itself it its
values were lost by a code reset.

Of course, it couldn't retain data that was only stored in the
previous instance of itself.

I've done this kind of thing, myself (though not using multiple form
instances -- I just wanted to give users and easy way to navigate
back to records they'd recently visited), and simply find it easier
to wrap the thing in a class module, simply because those have an
INITIALIZE event that allows me to do all sorts of things that
simply using global variables does not allow.

The other advantage is that different instances of the class module
could hold values for different purposes. Say, for instance, that
you had two different data forms that you wanted to do this with.
You couldn't use the same global array, you'd two of them, one for
each form. With a class module, you'd write the code to handle
multiple instances of any form, then initialize a class instance for
each of the two forms.

As you can tell, I'm a big fan of class modules.

But you're right, they might not help you here.


Nov 13 '05 #17

P: n/a
Bri <no*@here.com> wrote in news:C2XAd.617838$nl.590350@pd7tw3no:
As for making code 'self-healing', I've started wrapping global
variables in Public Properties, ala Michka, and that seems to be a
fairly simple solution to code resets. So, if I was to put all of
my globals into one class I could reinitialize all of them
together after a reset?


Yes. Only Class Modules have an Initialize event to fire this kind
of process.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #18

P: n/a
Hi David,

I've been reading this thread with interest and I was wondering if you
could clarify what you mean by a 'code reset.'

Thanks!

Michael.

Nov 13 '05 #19

P: n/a
de******@yahoo.com wrote in
news:11**********************@c13g2000cwb.googlegr oups.com:
I've been reading this thread with interest and I was wondering if
you could clarify what you mean by a 'code reset.'


Any time there is an unhandled error that causes the running code to
be reset all global variables are re-initialized. A class module
that is called after a code reset can re-initialize the values it
stores, assuming those values are derived from sources that are
stored in some persistent format that survives a code reset.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.