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

Other related posts: