a2k - weird code behaviour I can't explain...

[Deano]

Here's the code;
Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
If txtName isn't a null then I see the code jump to Else (the line marked B)
and then jump back to the first If - i.e it doesn't run the code after the
Else statement.
This happens around 25 times then finally the pointer moves on and finally
reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead moves to the
line marked C. It then moves to A. This second loop keeps going for quite
a while and I'm still stepping through it as I write.

I really have no idea why this is happening - I can only assume it's caused
by some weird combination of events, yet I am stepping through everything
and only the lostfocus event is firing.
Any ideas?

thanks
Martin

[Phil Stanton]

How many lines on your subform?
"Deano" <de*********@hotmail.com> wrote in message
news:Hn****************@wards.force9.net...

Here's the code;
Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
If txtName isn't a null then I see the code jump to Else (the line marked B) and then jump back to the first If - i.e it doesn't run the code after the
Else statement.
This happens around 25 times then finally the pointer moves on and finally
reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead moves to the line marked C. It then moves to A. This second loop keeps going for quite a while and I'm still stepping through it as I write.

I really have no idea why this is happening - I can only assume it's caused by some weird combination of events, yet I am stepping through everything
and only the lostfocus event is firing.
Any ideas?

thanks
Martin

[Deano]

Phil Stanton wrote:

How many lines on your subform?
46 filtered records.


"Deano" <de*********@hotmail.com> wrote in message
news:Hn****************@wards.force9.net...

Here's the code;
Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
If txtName isn't a null then I see the code jump to Else (the line
marked B) and then jump back to the first If - i.e it doesn't run
the code after the Else statement.
This happens around 25 times then finally the pointer moves on and
finally reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead
moves to the line marked C. It then moves to A. This second loop
keeps going for quite a while and I'm still stepping through it as I
write.

I really have no idea why this is happening - I can only assume it's
caused by some weird combination of events, yet I am stepping
through everything and only the lostfocus event is firing.
Any ideas?

thanks
Martin

[Phil Stanton]

Can't help then I was wondering if it was requerying the subform once for
each record, but no

Sorry

"Deano" <de*********@hotmail.com> wrote in message
news:EV*****************@wards.force9.net...

Phil Stanton wrote:

How many lines on your subform?

46 filtered records.

"Deano" <de*********@hotmail.com> wrote in message
news:Hn****************@wards.force9.net...

Here's the code;
Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
If txtName isn't a null then I see the code jump to Else (the line
marked B) and then jump back to the first If - i.e it doesn't run
the code after the Else statement.
This happens around 25 times then finally the pointer moves on and
finally reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead
moves to the line marked C. It then moves to A. This second loop
keeps going for quite a while and I'm still stepping through it as I
write.

I really have no idea why this is happening - I can only assume it's
caused by some weird combination of events, yet I am stepping
through everything and only the lostfocus event is firing.
Any ideas?

thanks
Martin

[Deano]

Phil Stanton wrote:

Can't help then I was wondering if it was requerying the subform once
for each record, but no

Sorry
Thanks anyhow, i think i'm going to have to live with it until inspiration
strikes. It doesn't do any harm but i am wondering why it's happening. Or
if it only happens when I debug line by line, which would be ironic....

"Deano" <de*********@hotmail.com> wrote in message
news:EV*****************@wards.force9.net...

Phil Stanton wrote:

How many lines on your subform?

46 filtered records.

"Deano" <de*********@hotmail.com> wrote in message
news:Hn****************@wards.force9.net...
Here's the code;
Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
If txtName isn't a null then I see the code jump to Else (the line
marked B) and then jump back to the first If - i.e it doesn't run
the code after the Else statement.
This happens around 25 times then finally the pointer moves on and
finally reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead
moves to the line marked C. It then moves to A. This second loop
keeps going for quite a while and I'm still stepping through it as
I write.

I really have no idea why this is happening - I can only assume
it's caused by some weird combination of events, yet I am stepping
through everything and only the lostfocus event is firing.
Any ideas?

thanks
Martin

[David W. Fenton]

de*********@hotmail.com (Deano) wrote in
<Hn****************@wards.force9.net>:

Here's the code;

Private Sub txtTeachName_LostFocus()

If IsNull(Me.txtName) Then 'line A
Forms!frmMainform!frmSubform.Locked = True
GoTo Exit_txtName
Else 'line B
Forms!frmMainform!frmSubform.Locked = False 'line C
If IsEmpty(oldName) Then
oldName = Me.Name
GoTo Exit_txtName
End If
End If

Exit_txtName:
Exit Sub

End Sub
Here's code that does the same thing:

Forms!frmMainform!frmSubform.Locked = IsNull(Me!txtName)
If (Forms!frmMainform!frmSubform.Locked) _
And IsEmpty(oldName) Then
oldName = Me.Name
End If

Now, I don't know what "oldName" refers to, but I assume it is a
form-level or public variable. I don't know why you're testing it
for "IsEmpty," which I only know about using with variants, and
even then, it's not entirely reliable.

If you're storing a string (the name of a form), then the variable
ought to be a string variable. And you'd test it with:

Len(strOldName)=0

So, your code seems vastly more complicated than it needs to be.
If txtName isn't a null then I see the code jump to Else (the line
marked B) and then jump back to the first If - i.e it doesn't run
the code after the Else statement.
Then that means that txtName is never Null. Does the field it's
bound to allow zero-length strings? If so, then it may very well be
"empty" from a human point of view and still not be Null.
This happens around 25 times then finally the pointer moves on and
finally reaches the Exit Sub at the end.
However it does NOT exit the code as I would expect but instead
moves to the line marked C. It then moves to A. This second loop
keeps going for quite a while and I'm still stepping through it as
I write.
I don't quite understand the relationships of the form. Is the form
referred to by Me the subform you're trying to lock? If so, then
you really can't do this from the subform.

I also question why you're using the LostFocus event, and not the
AfterUpdate event. I'm not certain, but there may be circumstances
where a control, loses focuses but does not fire the update events
(such as when the form the control is a part of loses focus), so
you could be testing for Null before it actually *is* Null.
I really have no idea why this is happening - I can only assume
it's caused by some weird combination of events, yet I am stepping
through everything and only the lostfocus event is firing.

I don't know what you are trying to accomplish.

Please explain what your code is doing and why, and then maybe we
can diagnose it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Deano]

David W. Fenton wrote:

de*********@hotmail.com (Deano) wrote in
<Hn****************@wards.force9.net>:

<snipped>

Thanks for the tips David.

At the moment it *is* working OK but I'm so busy looking at other things I'm
not going to have time to take this further (maybe later). The issue with
the oldname variable etc is to be able to know when the name's been changed
and the control in question is on the main form. It's a validation thing
and was done many months ago. Knowing what I know now I think it could be
done alot better.

What I was hoping that this was some fundamental Access glitch or well-known
behaviour that was easy to rectify....

[David W. Fenton]

de*********@hotmail.com (Deano) wrote in
<OD*****************@wards.force9.net>:

David W. Fenton wrote:

de*********@hotmail.com (Deano) wrote in
<Hn****************@wards.force9.net>:

<snipped>

Thanks for the tips David.

At the moment it *is* working OK but I'm so busy looking at other
things I'm not going to have time to take this further (maybe
later). The issue with the oldname variable etc is to be able to
know when the name's been changed and the control in question is
on the main form. It's a validation thing and was done many
months ago. Knowing what I know now I think it could be done alot
better.

What I was hoping that this was some fundamental Access glitch or
well-known behaviour that was easy to rectify....

I still don't know what your problem could be because I don't knoiw
the context in which the code is running.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Deano]

David W. Fenton wrote:

de*********@hotmail.com (Deano) wrote in
<OD*****************@wards.force9.net>:

David W. Fenton wrote:

de*********@hotmail.com (Deano) wrote in
<Hn****************@wards.force9.net>:

<snipped>

Thanks for the tips David.

At the moment it *is* working OK but I'm so busy looking at other
things I'm not going to have time to take this further (maybe
later). The issue with the oldname variable etc is to be able to
know when the name's been changed and the control in question is
on the main form. It's a validation thing and was done many
months ago. Knowing what I know now I think it could be done alot
better.

What I was hoping that this was some fundamental Access glitch or
well-known behaviour that was easy to rectify....

I still don't know what your problem could be because I don't knoiw
the context in which the code is running.

It's OK, i'm content to drop it for the time being. At the moment I'm not
keen on revisiting code unless i have to since it means i have to work out
what it all meant in the first place. My initial post was tangential to
something else but now that is cleared up so I will leave it for the time
being.

I do however think it is an interesting problem that might be of interest to
others and will post back on this subject when time permits and I can supply
the correct level of detail.