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

Other related posts: