Connecting Tech Pros Worldwide Forums | Help | Site Map

Strategy for form instantiation: is it a good idea?

Raposa Velha
Guest
 
Posts: n/a
#1: Nov 13 '05
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

Larry Linson
Guest
 
Posts: n/a
#2: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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" <jmclopes@hotmail.com> wrote in message
news:69bab092.0412281052.5f5dbb33@posting.google.c om...[color=blue]
> 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[/color]


rkc
Guest
 
Posts: n/a
#3: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Raposa Velha wrote:[color=blue]
> Hello to all!
>
> Does any of you want to comment the approach I implement for
> instantiating a form? A description and an example follow.[/color]

Yes.
What's the point?
Steve Jorgensen
Guest
 
Posts: n/a
#4: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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, jmclopes@hotmail.com (Raposa Velha) wrote:
[color=blue]
>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[/color]

Raposa Velha
Guest
 
Posts: n/a
#5: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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" <bouncer@localhost.not> wrote in message
news:xpnAd.11836$tG3.85@trnddc02...[color=blue]
>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" <jmclopes@hotmail.com> wrote in message
> news:69bab092.0412281052.5f5dbb33@posting.google.c om...[color=green]
>> 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[/color]
>
>[/color]


Raposa Velha
Guest
 
Posts: n/a
#6: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


The point of commenting ofr what to be commented? :-)

"rkc" <rkc@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:3JoAd.46802$DQ3.32231@twister.nyroc.rr.com...[color=blue]
> Raposa Velha wrote:[color=green]
>> Hello to all!
>>
>> Does any of you want to comment the approach I implement for
>> instantiating a form? A description and an example follow.[/color]
>
> Yes.
> What's the point?[/color]


Raposa Velha
Guest
 
Posts: n/a
#7: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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" <nospam@nospam.nospam> wrote in message
news:kmp4t0pjfm9ojqe1tum07ec8tllbj89odd@4ax.com...[color=blue]
> 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, jmclopes@hotmail.com (Raposa Velha) wrote:
>[color=green]
>>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[/color]
>[/color]


Bri
Guest
 
Posts: n/a
#8: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?



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:[color=blue]
> 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.[/color]


Bri
Guest
 
Posts: n/a
#9: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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:[color=blue]
> 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" <nospam@nospam.nospam> wrote in message
> news:kmp4t0pjfm9ojqe1tum07ec8tllbj89odd@4ax.com...
>[color=green]
>>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, jmclopes@hotmail.com (Raposa Velha) wrote:
>>
>>[color=darkred]
>>>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[/color]
>>[/color]
>
>[/color]


David W. Fenton
Guest
 
Posts: n/a
#10: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Bri <not@here.com> wrote in news:oxDAd.602327$Pl.99862@pd7tw1no:
[color=blue]
> 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.[/color]

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
rkc
Guest
 
Posts: n/a
#11: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Raposa Velha wrote:[color=blue]
> The point of commenting ofr what to be commented? :-)[/color]

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.
Bri
Guest
 
Posts: n/a
#12: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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:[color=blue]
> Bri <not@here.com> wrote in news:oxDAd.602327$Pl.99862@pd7tw1no:
>
>[color=green]
>>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.[/color]
>
>
> Have you considered a class module, which would automatically
> re-initialize the stored values when it is re-instantiated?
>[/color]


Bri
Guest
 
Posts: n/a
#13: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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:[color=blue]
> Raposa Velha wrote:
>[color=green]
>> The point of commenting ofr what to be commented? :-)[/color]
>
>
> 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.[/color]


rkc
Guest
 
Posts: n/a
#14: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Bri wrote:[color=blue]
> 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.[/color]

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.
Bri
Guest
 
Posts: n/a
#15: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?



rkc wrote:[color=blue]
> Bri wrote:
>[color=green]
>> 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.[/color]
>
>
> 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.[/color]

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

--
Bri


David W. Fenton
Guest
 
Posts: n/a
#16: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Bri <not@here.com> wrote in news:hoIAd.618275$%k.572920@pd7tw2no:
[color=blue]
> 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).[/color]

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
Bri
Guest
 
Posts: n/a
#17: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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:[color=blue]
> Bri <not@here.com> wrote in news:hoIAd.618275$%k.572920@pd7tw2no:
>
>[color=green]
>>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).[/color]
>
>
> 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.
>[/color]

David W. Fenton
Guest
 
Posts: n/a
#18: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


Bri <not@here.com> wrote in news:C2XAd.617838$nl.590350@pd7tw3no:
[color=blue]
> 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?[/color]

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
deathyam@yahoo.com
Guest
 
Posts: n/a
#19: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


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.

David W. Fenton
Guest
 
Posts: n/a
#20: Nov 13 '05

re: Strategy for form instantiation: is it a good idea?


deathyam@yahoo.com wrote in
news:1104505624.674064.149530@c13g2000cwb.googlegr oups.com:
[color=blue]
> I've been reading this thread with interest and I was wondering if
> you could clarify what you mean by a 'code reset.'[/color]

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
Closed Thread


Similar Microsoft Access / VBA bytes