G'day "Greg Maxey" <
[email protected]>,
You could also direct manipulate the form itself which is much easier
to understand. I'd present your existing four methods as traps to
avoid
You have my explicit permission to infinitely redistribute
an infinitely edited final form of this with accreditation using any
mechanisms you see fit - that is - stick it up on yer web site once
you've made it understandable
My apologies for the Fridayisms
No apologies for the TOTAL LACK OF
SUPPORTING CODE MY POOR OLE BRAIN HAS TO MUSH THROUGH TO UNDERSTAND
THIS STUFF!
(Also known as the "Look Ma, no variables!" method)
Option Explicit Sex Scenes
Sub WHShowsOffAgain()
'Uses the Maxey Form with Minny Code
Dim MyForm as frm1
Set myForm = new frm1
myForm.Label1.caption = InputBoxGregsEars("Gimme blah")
myForm.Show
MsgBoxGregsEars myForm.TextBox1.Text
Set MyForm = Nothing
End SubliminalMessaging
User form code
____________
Private Sub CommandButton1_Click()
Me.hide 'Dismiss the form and return processing to the caller
End Sub
Note Well here Greggles: User form code should pretty well only exist
in order to provide data validation through calling public procedures
(the API) from the supporting class.
For example, a field on the form asks you for your bra size. Obviously
a bra size of 4" is ridiculous, and it needs to be in the format of a
numeric of 2 digits followed by an alphabetic letter or three.
However, if we were to lock that validating code away in our user
form, we cannot access it from other programs. Later on, when I am
developing my IdealWomanFinder.V569.dot and I need a bra size
calculator, I will send you many frilly hankies for having isolated
your code as a publicly available function. The user form then merely
does a
LovelyBox.Text = Tailor.Physique.BraSizeValidator(LovelyBox.Text)
Using _Activate is very poor. To quote the help system:
The Activate event occurs when an object becomes the active window.
Only use this event to redraw to window if you kill the window on a
deactivate to conserve mem & processing cycles, or you need to
interogate other windows (within the Word shell only, so multiple
modal dialogs) that have been active in the meantime.
Really, you should be using the Init event. This is ONLY triggered
when you do a Set MyForm = new frm1. This should be used to prepare
data for the form such as preloading comboboxes and the like. Now, in
order to pull in such data, we have a SIXTH method mate. No offense,
but your article misses the only two truly useful methods!
OK,
method 2 comes close to this, but still, you confuse things by
suggesting a doc var is the only way to communicate! We have VBA as
well as the document!
Private Sub MyForm_Initialize()
'When will VBA localise to Aus with an S DAMMIT
With Me 'And no one else
.SomeLabel.text = GregsPublicObject.UselessTag
.AnotherLabel.text = AnAmaZinglyPublicVariable
End Me 'Bang
End SubmarineWarfareCozWeAussiesRuleAtItAlready
However, we need to be very Newtonian here. Every action needs an
opposite and equal reaction. VBA Gotchya #1: Destroy every OBJECT.
Strings, longs, shorts, thongs, singlets and other VARIABLES are OK.
After an old MVP suggested strings didn't undergo proper garbage
handling I ran some pretty extreme tests. They do hang around until
their container gets destroyed, so if they are in a std code module
(99% usage) then they are somewhat persistent, but you can rewrite
them a gadzillion times (1 gadzillion = infinity - 1 squillion) and
you will not lose memory over it. Drink alcohol and you'll lose
memory, but not from snorting strings.
To get back on track here, let's say that Init did something like
this:
Me.MyComboBoxYerXmasPresentsNow.AddItem "Chocolate"
Me.MyComboBoxYerXmasPresentsNow.AddItem "Beer"
Me.MyComboBoxYerXmasPresentsNow.AddItem "Ferrari"
There is some evidence to suggest that we should have, in our
_Terminate event (runs when you do a Set MyForm=Nothing)
me.ComboBox1.Clear
as the combox's contents are a collection tha should be destroyed.
However, there is no argument that you certainly must destroy your own
objects that aren't controls on the form (which MS have built some
extra strong hard-coded magix against). For example, if our form code
looked something like this
Option Explicit Language Muck Ya
Public MyStupidIdea as SomeObjectType
Private Sub MyForm_Initialize()
Set MyStupidIdea = New SomeObjectType
MyStupidIdea.MyPointlessProperty = SomethingElse
End SublimeMusicListening
(and I mean only SOMETHING right? ;-) ) then our terminate event (is
that when termites come and eat you alive?) would most certainly have
to include
Set MyStupidIdea = Nothing
However, for reasons explained above, (the bit where I said no code in
the userform) this sort of practice is best left for your custom
objects.
Finally, I did some pretty exhaustive testing, and asked around
inside, and found that effectively:
Unload MyForm is the same as Set MyForm=Nothing
and
Load MyForm is the same as Set MyForm = New DINGOFORM1
Load and Unload are only there for magic forms support, as in
Load DINGOFORM1
That is, no variable declaration required, no formal instancing of the
object. Instead, we have an informal instancing which uses the actual
object template in memory. Yech. Let alone lotsa problems, most
noticeable when working amongst several documents.
However, no matter which way you do it, VBA hides the mechanism
through which it obtains hWnd ('document') to attach to the window
(UserForm). It was the presence of hWnd that made me give up system
programming so I am kinda glad I don't see it in VBA. You can force it
if you have to but that's another story for another Friday when I have
had another dozen beers. Good luck with your editing
(I am working out of wordheretic at iinet dot net dotty au whilst I
get production services online if you need me for translation help
hehehheheeh)
