By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,148 Members | 765 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,148 IT Pros & Developers. It's quick & easy.

Sub keeping ACCESS.EXE open

P: n/a
It seems that the following sub is keeping the ACCESS.EXE process
running in task manager after I close the program. I can't see why. I
call it from several places throughout my program to highlight all
characters in a field.

Public Sub SelectAll(Control As Control)
Control.SelStart = 0
Control.SelLength = Len(Control.Text)
End Sub

Jan 13 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Bryan wrote in message
<11*********************@g49g2000cwa.googlegroups. com> :
It seems that the following sub is keeping the ACCESS.EXE process
running in task manager after I close the program. I can't see why. I
call it from several places throughout my program to highlight all
characters in a field.

Public Sub SelectAll(Control As Control)
Control.SelStart = 0
Control.SelLength = Len(Control.Text)
End Sub


One thing to try, is to avoid reserved words as names of objects.
Control is one of those. Maybe you are confusing Access about what you
are trying to manipulate

Public Sub SelectAll(ctl As Control)
ctl.SelStart = 0
ctl.SelLength = Len(ctl.Text)
set ctl = nothing
End Sub

Do also see if releasing the object variable helps.

--
Roy-Vidar
Jan 13 '06 #2

P: n/a
Thanks for the suggestions. I changed the code to match yours

Public Sub SelectAll(c As Control)
c.SelStart = 0
c.SelLength = Len(c.Text)
Set c = Nothing
End Sub

But it still keeps ACCESS.EXE open. I made sure it was this sub and
not any other sub causing the problem. Everytime the control that runs
this wub gets the focus ACCESS.EXE will not close out. ???

Jan 13 '06 #3

P: n/a
Bryan wrote in message
<11**********************@o13g2000cwo.googlegroups .com> :
Thanks for the suggestions. I changed the code to match yours

Public Sub SelectAll(c As Control)
c.SelStart = 0
c.SelLength = Len(c.Text)
Set c = Nothing
End Sub

But it still keeps ACCESS.EXE open. I made sure it was this sub and
not any other sub causing the problem. Everytime the control that runs
this wub gets the focus ACCESS.EXE will not close out. ???


Sorry, I don't know - I just can't understand code like this keeping
an instance of Access live (on second thought about releasing,
shouldn't
be necessary).

What I would usually look for, is usage of DAO recordsets that are not
closed or released, database variables not being closed (if they where
opened) and released (usage of both, and not released in the correct
order?), and such things.

If none of those are found, I'd guess corruption (I'm perhaps a bit
hasty in guessing corruption?), and try /decompile on a *copy* of the
db. If you're not familiar with it, try the step by step instructions
from here
http://www.granite.ab.ca/access/decompile.htm

--
Roy-Vidar
Jan 13 '06 #4

P: n/a
Thanks for your input, i've never decomplied before in access, I will
try that.

Jan 14 '06 #5

P: n/a
Bryan wrote:
Thanks for the suggestions. I changed the code to match yours

Public Sub SelectAll(c As Control)
c.SelStart = 0
c.SelLength = Len(c.Text)
Set c = Nothing+*
End Sub
Why are you setting c to nothing?

Does it matter what control it is when ending the report? Is it a
specific form or any form? Specific control or any control?

Does the sub that calls SelectAll have an OnError ResumeNext statement?

Since you have this called throughout the app, did it ever work?

What event for the control calls this sub?

Since the sub keeps Access open, can you get to the debug window. If
so, you might want to add
Debug.Print c.Name

Are you setting focus from another control to the control that causes
the problem from within an event?

But it still keeps ACCESS.EXE open. I made sure it was this sub and
not any other sub causing the problem. Everytime the control that runs
this wub gets the focus ACCESS.EXE will not close out. ???

Jan 14 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.