atw: Re: Persistent Data in Userform List box [SEC=UNCLASSIFIED]

Heh. Multiple form invocation can get even messier. You are spot on but, so
that's good that you've learned something from my ravings - a rare
experience I am assured hehe


The Heretical Golden Rule for Forms Coding

Short version: DON'T!
Long version: If there is any possible way to remove code from a form DO SO.
Code in forms is generally INACCESSIBLE to callers. Let the caller have the
power!


In this case, we have a form (form 1) calling a form (form 2). So we are
trying to move code from form 2 into form 1 and read some values. If we ever
need to repurpose form 2, we can! Lucas' way we cant - we are stuck with the
returning mechanism.


Form 2 (frmSecurityEdit)

Public OptionSelected as Boolean 'we will return our 'selected button' value
here

...
Private Sub cmdOK_Click()
    OptionSelected = vbOK
    Me.Hide 'Dunno what the caller called us
End Sub

Private Sub cmdCancel_Click()
    OptionSelected = vbCancel
    Me.Hide
End Sub



Form 1 (frmWizard)

IF we wanted the second form to load with the old values set each time:

At the top

Private SecurityEdit as frmSecurityEdit

...

Private Sub Class_initialize()
Set SecurityEdit = new frmSecurityEdit
End Sub

Private Sub Class_terminate()
Set securityedit = nothing
End Sub

If we wanted the form fresh each time, we would do the dim, set = new and
set = nothing inside the routines that display the second form


Somewhere, buried deep instance an event that calls the second form, in a
galaxy far far away

  Me.Hide
  With SecurityEdit
    .Show
    if .OptionSelected = vbOK then
      'Synchronise Security list values with Edit List Values
       Me.lstSecurityRequirement.List = .lstAllSecurityValues.List
    end if
  End With
    

 

-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] 
Sent: Tuesday, 23 May 2006 4:50 PM
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Persistent Data in Userform List box [SEC=UNCLASSIFIED]

Thanks, Steve

You're very patient in your explanations. I realise it's a big ask to expect
someone to include a crash course in forms in a post to the list!
At the risk of trying your patience even further, I just want to make sure
I've got your message OK. 

Let's take Lucas's code as a concrete example. Lucas's Form 2
(frmSecurityEdit) had an OK button and a Cancel button whose _Click events
looked like this:

Private Sub cmdOK_Click()

    'Synchronise Security list values with Edit List Values
    frmWizard.lstSecurityRequirement.List =
frmSecurityEdit.lstAllSecurityValues.List
    
    frmSecurityEdit.Hide
    Unload frmSecurityEdit
End Sub

Private Sub cmdCancel_Click()
    frmSecurityEdit.Hide
    Unload frmSecurityEdit
End Sub

Your suggestion would involve removing everything except the
frmSecurityEdit.Hide (i.e. Me.Hide) from each of these. This makes the code
for cmdOK_Click and cmdCancel_Click identical, so the calling routine would
need to test which event actually handed control back. Not sure how you do
this - is there a return value you can use? You could, of course, pass a
different value from each event, but if you do this I can't see much
difference from putting

frmWizard.lstSecurityRequirement.List =
frmSecurityEdit.lstAllSecurityValues.List

in the OK event but not the Cancel. (In other words, if we're pushing values
from the form in any case, why not push the value of the List that we
actually want to set?)

Anyway, assuming we can tell which event actually happened, we accordingly
set the value of frmWizard.lstSecurityRequirement.List or not, then follow
with the statement

Set frmSecurityEdit = Nothing 

to do the actual unloading. Is that more or less how you would recommend
Lucas should proceed? And do you have a suggestion for testing which event
happened?

Howard


-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Hudson
Sent: Tuesday, 23 May 2006 13:32
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Persistent Data in Userform List box [SEC=UNCLASSIFIED]


No - I said quite clearly the unload wont unload and cant unload whilst the
form is in use, which is while the unload statement is running. It will
PREPARE the form for unload, but the unload doesn't occur until AFTER the
unload statement has finished executing, whereas if we unload externally the
unload, as all statements SHOULD, executes DURING the statement.

Thus it "works" in "most" instances, but it is not working as expected.
I'll dolly step what happens behind the scenes for you

Form is active
..    Statements executing, maybe just waiting on event like a button
press
..    The Cancel button event gets triggered by the user pressing the
cancel
button
..    Host environs (VBA) sends a "Cancel_Button_Pressed" event to the
form's event handler

(The form's event handler is all the code we tend to write in a userform
that works off _clicks etc. We don't have to explicitly declare With Events
like we do with other class modules, because forms are event oriented so its
ASSUMED and thus auto-provided by the OS. When you start designing your own
objects with event handling you'll immediately see the similarities and the
few pre-steps to activate event handling are not required for forms)

..    Time for the form to end
..    Unload gets issued from the form >>
..    ..     Host environs (VBA) sends a terminate event to the form
..    ..     Form cant process event because statements are executing
..    ..     Host VBA marks the form for destruction, doesn't fail the
event
and completes
..    Unload finishes executing - form is still is still in existence
..    A msgbox immediately after the Unload should still work, proving
the
form is present AFTER the unload.
..    Host VBA finishes executing the Cancel button event, leaving the
form
free to process new events


(note that step carefully, you cannot process events whilst processing an
EVENT! This makes a LOT of sense when you think about it.)

..    Form takes next queued event - a terminate request! It runs its
termination sequence. Provided all child objects are likewise destoryed, all
instances of the form and its variables are removed from memory.


Note the last step carefully as well - all variables removed from memory.
What if wanted to examine what the user had selected on the form? Its GONE.
We can push from form code, but its better to pull from reading code.

Now, the best way is more like this

....

MyForm.Show

'MyForm will use Me.Hide to return processing to me


'get what the user selected

MySelection = MyForm.Listbox(1).Value   

...




-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Silcock, Howard DR
Sent: Monday, 22 May 2006 11:10 AM
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Persistent Data in Userform List box [SEC=UNCLASSIFIED]

Are you changing your initial assertion from 'a form cannot unload itself'
to 'it's poor programming practice to get a form to unload itself'? As a
self-taught programmer, I'm always happy to get advice on better programming
practice.

But if you don't put Unload Me, or something like it, into an OK button's
code, how do you get the button to pass control from the form back to the
calling routine? The VBA Help file and books I've consulted seem to use
Unload Me. If there's a neater or more elegant way, I'm happy to use it.

Howard



-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Hudson
Sent: Sunday, 21 May 2006 21:10
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Persistent Data in Userform List box


<Shrugs>

Still don't make it so. Yes, it can and should happen AFTER the Unload, but
as the unload statement is executing the form is in use and cannot be
terminated. It is flagged for termination, but doesn't actually terminate
until after the unload has executed and is very poor programming practice.

A form is always invoked from a calling routine. The calling routine of any
object is responsible for its definition, creation and termination.
Additionally, should one be processing a termination event, it can also make
a difference.

Ideally:


Public Sub CallMyForm()
Dim MyForm as frmMyForm

Set MyForm = new frmMyForm  ' causes form's init event to run

MyForm.Show 'passes control to the form

MyForm.Hide 'can be in form's code, just very little point

Set MyForm=Nothing 'runs the termination event


Note Set MyForm=Nothing is effectively the same as Unload, the latter being
for use in magic form usages:

frmMyForm.Show
Unload frmMyForm

Another practice to avoid.



-----Original Message-----
From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Howard Silcock
Sent: Sunday, 21 May 2006 4:29 PM
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Re: Persistent Data in Userform List box

Steve Hudson says:

> A form cannot unload itself

Not true. Most OK (and Cancel) buttons for forms have code that finish with
Unload Me. 

Howard
  _____  

From: austechwriter-bounce@xxxxxxxxxxxxx
[mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Lucas Simpson
Sent: Friday, 19 May 2006 1:49 PM
To: austechwriter@xxxxxxxxxxxxx
Subject: atw: Persistent Data in Userform List box


Howdy Listies
 
Just can't seem to solve this so hoping someone can point out my stupidity.
 
Basic Scenario:
1. Have Form 1 with List box
2. Click Add button on Form 1 to load Form 2 and sync a list box on Form
2 with same list items as in Form 1 list box. 3. After Editing list, click
OK on Form 2 to pass Form 2 list items back to Form 1 list box.
- Have multiple list boxes on Form 1 (with a concommittant Add button) that
all use the same Form 2 for editing as per 1 to 3 above.
 
Code works no problem, can pass back and forth between Form 1 and Form 2
listboxes.
 
Problem is:
1. Add list values using above method to first listbox on Form 1. So far so
good. 2. Add list values using above method to second listbox on Form 1. So
far so good. 3. Attempt to re-edit first listbox on Form 1 and the values
from the second listbox on Form 1 still appear in Form 2 listbox.
Not good. 4. Cancel Form 2 (which unloads form) and then attempt step 3
again. Now the correct list values (ie. from first listbox on Form 1) load
into Form 2 listbox.
 
This suggests to me that Form 2 is not correctly unloading after passing
values back to Form 1 (on click OK). But buggered if i know why as Form
2 is instructed to unload on the OK click event, just as it is on the Cancel
click event.
 
Sure would appreciate someone giving me a clue.
 
OR Is there a better way for me to inform Form 2 about which list box in
Form 1 i am referring to. Can't seem to just pass the relevant Form 1 list
box object directly to the Form 2 Userform_Initialize sub.
 
 
Hope this makes sense.
 
Cheers
Lucas
 
 
Here is the code:
 
''++++++++++Form 1 (frmWizard)++++++++++ 'Private Sub
cmbSecurity1_1_Click()
 
    ''lstSecurityRequirement is Public Variable dim'd as Object used to pass
to Form 2 which listbox on Form 1 i am referring to
    ''lstFacilitySecurity0 is actual list name in Form 1
   Set frmWizard.lstSecurityRequirement = frmWizard.lstFacilitySecurity0
 
    frmSecurityEdit.Show  'Display Security Edit dialog
    frmSecurityEdit.lstAllSecurityValues.List =
frmWizard.lstSecurityRequirement.List 'Sync lists 'End Sub
 
'Private Sub cmbSecurity1_2_Click()
 
   ''lstSecurityRequirement is Public Variable dim'd as Object used to pass
to Form 2 which listbox on Form 1 i am referring to
    ''lstFacilitySecurity1 is actual list name in Form 1
   Set frmWixard.lstSecurityRequirement = frmWizard.lstFacilitySecurity1
 
    frmSecurityEdit.Show  'Display Security Edit dialog
    frmSecurityEdit.lstAllSecurityValues.List =
frmWizard.lstSecurityRequirement.List 'Sync lists 'End Sub
 
 
'++++++++++Form 2 (frmSecurityEdit)+++++++++++ 'Sub
UserForm_Initialize() ''No code 'End Sub
 
'Private Sub cmdOK_Click()
 
    'Synchronise Security list values with Edit List Values
    frmWizard.lstSecurityRequirement.List =
frmSecurityEdit.lstAllSecurityValues.List
    
    frmSecurityEdit.Hide
    Unload frmSecurityEdit
'End Sub
 
 
'Private Sub cmdCancel_Click()
    frmSecurityEdit.Hide
    Unload frmSecurityEdit
'End Sub



------------------------------

From: "Tony Cusack" <tony@xxxxxxxxxxxxxxxx>
Subject: Re: Un PC language?
Date: Sun, 21 May 2006 10:25:58 +1000

Hi Michael,
no, I didn't consider it, it just slipped out. For me it wasn't in either
case his conduct that was PM. Rather that he was prepared to go on the
record with his patently unbelievable excuses - tacitly acknowledging a
fundamental shift in communal values. rgds, Tony. 

> -----Original Message-----
> From: austechwriter-bounce@xxxxxxxxxxxxx
> [mailto:austechwriter-bounce@xxxxxxxxxxxxx] On Behalf Of Michael 
> Granat
> Sent: Friday, 19 May 2006 9:58 AM
> To: austechwriter@xxxxxxxxxxxxx
> Subject: atw: Re: Un PC language?
> 
> Hi Tony (C).
> 
> Did you consider that, perhaps, using seminal and Bill C's name in the 
> same sentence wasn't such a great idea?
> 
> Another "seminal post-modern event" comes to mind, about which I shall 
> abstain from commenting from this address.
> 
> Cheers,
> 
> Micky G.
> 
> At 07:44 19/05/2006, you wrote:
> >Hi Warren,
> >Thanks.
> >Apparently Westies is so post-modern that it holds meetings
> where one
> >newcomer but no one else turns up. Cool! Reminds me of Bill
> Clinton's
> >smoking dope but not inhaling - a seminal post-modern event. Cheers, 
> >Tony.
> 
> 
> Michael Granat
> Write Ideas
> www.writeideas.com.au
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.1.392 / Virus Database: 268.6.1/343 - Release
> Date: 18/05/2006
> 
> 
> **************************************************
> To post a message to austechwriter, send the message to 
> austechwriter@xxxxxxxxxxxxxx
> 
> To subscribe to austechwriter, send a message to 
> austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject 
> field.
> 
> To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
> with "unsubscribe" in the Subject field.
> 
> To search the austechwriter archives, go to 
> www.freelists.org/archives/austechwriter
> 
> To contact the list administrator, send a message to 
> austechwriter-admins@xxxxxxxxxxxxx
> **************************************************
> 



------------------------------

End of austechwriter Digest V4 #132
***********************************

**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
with
"unsubscribe" in the Subject field.

To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
with "unsubscribe" in the Subject field.

To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
with
"unsubscribe" in the Subject field.

To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
with "unsubscribe" in the Subject field.

To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field.

To search the austechwriter archives, go to
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to 
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to 
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with 
"unsubscribe" in the Subject field.

To search the austechwriter archives, go to 
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to 
austechwriter-admins@xxxxxxxxxxxxx
**************************************************

Other related posts: