Access doesn't shut down after boolean option group 1

[Frink]

Hallo,

I'm glad you're reading this. I wasn't sure if anyone would with such an obscure subject.

I had a problem with Access '97 not shutting down after running one of my applications. I narrowed it down to a single line of code relating to the value of a frame control on a subform.

The frame control fraFilterOn contains two buttons, On and Off. On has the value -1 and off is 0. I then treat the
frame control as a boolean. Quite reasonable, I'm sure you'll agree. Here's the line of code I use:

If Forms!frmMain!frmRecordFilter.Form!fraFilterOn Then

Now when this line is included, it works fine, but when I close Access, it just minimises and wont go away unless I end it's task.
If I replace the line with:

If Forms!frmMain!frmRecordFilter.Form!fraFilterOn <> 0 Then

then it works fine and shuts down properly.

Has anyone else found this a problem?
Are there any other reasons why Access doesn't close down?
Have I got completely the wrong end of the stick?

Please respond.

- Frink

P.S. Is 'Programmer' better than 'TechnicalUser'?

 

[ghubbell]

Programmer/TechnicalUser/ChromeMufflerBearingReplacer...they're all the same...

To the best of my knowledge, you pretty much have to explicitly do your check against a value when it's a control. With a boolean type variable you can neglect the comparison. Gord
ghubbell@total.net

 

[RickSpr]

The primary cause of Access minimizing instead of closing is dangling object references. Microsoft has a known bug in DAO that causes the problem if you exit a procedure without setting DAO object variables to Nothing first.

I wonder if you've found a similar bug. Your reference to the control object in the expression could be evaluated two ways: as an Object value, or as a Variant containing the value of the control's default (Value) property.

When you use it with &quot;<> 0&quot;, VBA assumes you want the default property. In this case, there's no need to create a temporary Object value to hold the value of the expression, so no extra reference to the object is created. But without the &quot;<> 0&quot;, the value of the expression IS the object variable. VBA won't let you refer to the real object variable, which is owned by the form, because that could cause side effects (bad things would happen if you were to set it to Nothing, for example). So VBA creates a temporary object variable for you.

This temporary object variable then gets tested for the IF. That involves converting it to a Boolean somehow. But it may be that the code generated by the IF fails to release the temporary variable, which leaves a hanging reference to the control. Because of the hanging reference, the control can never be released from memory, so when you try to close Access, it just minimizes, waiting for some running event to terminate and release the object. Of course, no event is running, so it hangs in the task bar forever. This is similar to the problem that happens with DAO objects that don't get released.

How about trying this experiment: Make your statement
If Forms!frmMain!frmRecordFilter.Form!fraFilterOn.Value
By explicitly referring to the Value property, you'll prevent the temporary object variable from being created. If it works, that would confirm my hypothesis. Rick Sprague

 

[Quehay]

Thank you for that tutorial Rick! You've pointed this type of problem out before--it helps to keep that in mind when writing VBA for Access.

Question: I use the following all the time--the original code comes from the Wizard. Does not explicitly closing this object variable invite a similar problem?

[tt]Private Sub cboFindSMO_AfterUpdate()
On Error GoTo ErrorTrap

' Find the record that matches the control.
Dim rs As Object

Me.DataEntry = False

Set rs = Me.Recordset.Clone
rs.FindFirst &quot;[SMOKey] = &quot; & str(Me![cboFindSMO])
Me.Bookmark = rs.Bookmark

ExitErrorTrap:
Exit Sub

ErrorTrap:
MsgBox Err.Number & &quot;: &quot; & Err.Description
Resume ExitErrorTrap

End Sub[/tt]

 

[RickSpr]

Yes, it seems to me that it would. I certainly wouldn't recommend Microsoft's wizard-generated code as an example of robustness, let alone good programming style.

Here's the link to the bug info, in case you're interested:

http://www.mvps.org/access/bugs/bugs0005.htm

Rick Sprague

 

[Frink]

Cheers me dears,

Thanks Rick for your insight. I have a couple of similar frame controls bound to Yes/No fields. I wonder if they're Ok?

I tried referring to the Value property in the condition and it worked fine.

Thanks again,

- Frink

 

[RickSpr]

Frink,

My hunch is that the problem would only occur in the context of VBA If statement execution. The way I figure it, the code generator for the IF statement failed to generate code that would release the temporary object that was handed to it by the expression evaluator code generator--a case of one hand not knowing what the other was doing. I expect this was an oversight on the part of the programmer who wrote the If statement code generator. But it would be limited to If statements, or possibly to any statements that generate branching code based on a Boolean expression. (Another example would be &quot;Do While <expression>&quot; where &quot;<expression>&quot; evaluates to an object.)

Another way to look at it is that, while the underlying columns are Yes/No, fields are always Variants. So your frame object would be being assigned to a Variant, not evaluated as a Boolean. Later, the field itself is being assigned to the database column--but by then it's a real variable, not a temporary any more. I don't doubt that object variables get handled properly. I think it's only temporary object variables that get dropped, and only in the context of VBA generated code.

Of course, I'm just guessing, but I do know a little about code generators and how they're organized. Rick Sprague