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
**************************************************

Other related posts: