Re: Ever had to judge a new to-be-hired in interview?

Tech-Archive recommends: Fix windows errors by optimizing your registry

On Mon, 5 Dec 2005 23:04:02 -0500, "Dmitriy Antonov"
<antonovdima@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>
>"David Youngblood" <dwy@xxxxxxxxx> wrote in message
>news:%232mMDHh%23FHA.264@xxxxxxxxxxxxxxxxxxxxxxx
>> "Richard Jalbert" <richmann@xxxxxxxxxxxx> wrote in message
>> news:4394ee2d.43627156@xxxxxxxxxxxxxxxxxxxxxxxx
>>> On Mon, 5 Dec 2005 19:39:33 -0600, "David Youngblood" <dwy@xxxxxxxxx>
>>> wrote:
>>>
>>> >"Richard Jalbert" <richmann@xxxxxxxxxxxx> wrote...
>>> >> >>> ---------------------------------------------------------------------
>>> >> >>> A form is Unloaded specifically set to Nothing while one control
>>> >> >>> on
>>> >> >>> it is still referenced somewhere. What will happens?
>>> >> >>>
>>> >> >>> ---ANSWER
>>> >> >>> The form will be reloaded the instant that control is actively
>>> >> >>> referenced and will be loaded with default values instead of the
>>> >> >>> last values it contained.
>>> >> >>
>>> >> >>Incorrect answer. Form will be unloaded but not terminated and thus
>>> >> >>all
>> its
>>> >> >>state remains intact. Any reference to mentioned control will load
>>> >> >>the
>> form
>>> >> >>again but there will be no new initialization and all form level
>> variables
>>> >> >>will have the same values
>>> >> >
>>> >> >My exact experience was with loaded at runtime ActiveX. I will test
>>> >> >this.
>>> >>
>>> >> It works as I said. see the first posting by Saga, which I tested.
>>> >> To make sure, I put some default text in the second form textbox and
>>> >> the dialog showed this.
>>> >
>>> >You may want to retest this. Control contents will be lost when the form
>>> >unloads, but form level variables will not be lost until the form
>>> >terminates.
>>> >And in the case cited ("one control on it is still referenced
>>> >somewhere"),
>> the
>>> >form will not terminate, therefore form level variables are not reset.
>>> >
>>> >Try this example, and then try it without the reference to Form2.Text1.
>>> >
>>> >'* Form1 code
>>> >Private Sub Command1_Click()
>>> > Dim ctl As Control
>>> > Form2.Show
>>> > Set ctl = Form2.Text1
>>> > Unload Form2
>>> > Set Form2 = Nothing
>>> > Debug.Print ctl.Text
>>> >End Sub
>>> >
>>> >'* Form2 code
>>> >Public m_s As String
>>> >
>>> >Private Sub Form_Load()
>>> > Debug.Print m_s
>>> > m_s = Text1.Text
>>> >End Sub
>>> >
>>> >Private Sub Form_Terminate()
>>> > Debug.Print "Terminate"
>>> >End Sub
>>> >
>>> >David
>>>
>>> I just did.
>>
>> Perhaps you missed what I was saying, so I'll repeat it, since I don't
>> know any
>> other way to say it.
>>
>> "Control contents will be lost when the form unloads, but form level
>> variables
>> will not be lost until the form terminates. And in the case cited ("one
>> control
>> on it is still referenced somewhere"), the form will not terminate,
>> therefore
>> form level variables are not reset."
>>
>> And I'll add, yes Text1.Text is reset, but the variable m_s is *not*
>> reset.
>> And as you correctly observed, Form2 Terminate event does *not* fire.
>>
>> David
>>
>>> In Form2, the text box have a default text.
>>> But clicking the button changes that text and it is correctly captured
>>> in the following line.
>>> However, when the ctrl is called by "Debug.Print ctl.Text", the
>>> default text is back.
>>>
>>> See for yourself.
>>>
>>> ====================================================
>>> CODE FOR FORM 1
>>>
>>> Private Sub btnCtrl_Click()
>>> Dim ctl As Control
>>> frm_2.Show
>>> Set ctl = frm_2.frm2_txt_1
>>> ' The text is modified here
>>> frm_2.frm2_txt_1.Text = "Test reference"
>>> Unload frm_2
>>> Set frm_2 = Nothing
>>> ' Load does not reset the value: the control is called and the
>>> value passed is the default one, not the modifed one.
>>> Debug.Print "Called from ctl.Text :" & ctl.Text
>>> End Sub
>>>
>>> ====================================================
>>> CODE FOR FORM 2
>>>
>>> Private Sub Form_Load()
>>> ' This will get the default value in the control
>>> m_s = Me.frm2_txt_1.Text
>>> Debug.Print "On load:" & m_s
>>> m_s = Me.frm2_txt_1.Text
>>> Debug.Print "After load:" & m_s
>>> End Sub
>>>
>>> ======================================================
>>> Output is
>>>
>>> On load:Default test
>>> After load:Default test
>>> Text reset :Test reference
>>> On load:Default test
>>> After load:Default test
>>> Called from ctl.Text :Default test
>>>
>>> But the form never terminate.
>>> ======================================================
>>>
>>> Well, I'll pick up this thread tomorrow. old age is catching up with
>>> me and I need my beauty sleep <ggg>
>>>
>>> But I will pick it up tomorrow.
>>> BFN
>>>
>
>As David, I insist that the form will neither terminated nor its module
>level state is reset. I think the the code, which David proposed, not
>clearly demonstrates that. So I propose my version for testing. Start new
>regular.EXE project (Form1 added by default) and add the form (leave default
>name - Form2), add a textbox (Text1) and paste the following code into Form2
>
>Option Explicit
>
>Dim mlProp&
>
>Public Property Let Prop(val As Long)
> mlProp = val
>End Property
>Public Property Get Prop() As Long
> Prop = mlProp
>End Property
>
>Private Sub Form_Initialize()
> Debug.Print "Initialize"
>End Sub
>
>Private Sub Form_Load()
> Debug.Print "load"
>End Sub
>
>Private Sub Form_Unload(Cancel As Integer)
> Debug.Print "Unload"
>End Sub
>
>Private Sub Form_Terminate()
> Debug.Print "Terminate"
>End Sub
>
>Now add a CommandButton on the Form1 (leave default name) and paste the
>following code into Form1. Now you can run it. For better understanding I
>would advise to place breakpoint on the line after comment 'Initialize.

Of course I did that.

>Option Explicit
>
>Private Sub Command1_Click()
> Dim frm As Form2
> Dim txt As TextBox
> 'Initialize
> Set frm = New Form2
> 'Load
> frm.Show
> frm.Text1.Text = "test"
> frm.Prop = 123
> 'unload
> Set txt = frm.Text1
> Unload frm
> 'NO TERMINATE
> Set frm = Nothing
>
>
> 'application will not terminate after this procedure because after
> 'the following statement the form Form2 will be loaded again
> 'but remains invisible - but this is not important for this discussion
> 'since the form is reloaded, all controls reset their states
> Debug.Print txt.Text' will be default Text1
> 'but all module level state is preserved
> Debug.Print txt.Parent.Prop
>End Sub
>
>If this will not give you a prove of my point then I'll give up :-(
>
>Dmitriy.

I did your example exactly and it works exactly as you said.

My experienc bias on this was we kept all values in ListView and Text
controls. I thought that since a ListView is already an object, why
create a collection (for example) that would have to be updated at
each edit by the user.
Of course when I answered David Youngblood, I did the same thing.
More on this later.

It would seem the only really safe way of keeping all values in a
control (Form or ActiveX) would be to load them into module level
variable and get them back through properties.
In an ActiveX that is also a data entry and manipulation interface,
that seems redundant plus it brings about a lot of code that would be
triggered by cascading events.

This is behavior that could cause problem in maintenance as if a new
coder gets his hands on it and does not know the reason behind all the
property loading would take shortcuts and break the application.

It would be much simpler to make sure no control is ever referenced
directly and then destroy the object when uneeded or else keep it
around for as long as it takes.

I shudder when I think that at the company I worked for, we loaded
about 20 *huge* ActiveX that kept about a hundred values each in all
kinds of formats and we never stumbled on this before. I kept all data
loaded in ListViews and Text controls, not in control level variables,
available for the user to modify. When saving the data, all control
would be queried and the ActiveX would itself save tot he basic
document. THEN it would be unloaded (The only reason we went from VB5
to VB6 was, VB6 can create ActiveX at runtime)

But even them we were straining VB past its usefullness.

.

Quantcast