delay in closing a form

  • Thread starter Thread starter oldguy
  • Start date Start date
O

oldguy

Hi,

Access XP on Windows XP.

After using a form, I'm closing and then deleting it, all in VBA.

I get the error message saying that I cannot delete an open form.

My deduction is that, the closing of the form is still in progress when the
line to delete it is processed. Therefore I need something to tell me that
the form is actually closed.

I'm sure (and I hope) this is a common problem, and there is a solution.

Any suggestion is welcome with thanks.

Engin Tarhan
 
oldguy said:
Access XP on Windows XP.

After using a form, I'm closing and then deleting it, all in VBA.

I get the error message saying that I cannot delete an open form.

My deduction is that, the closing of the form is still in progress when the
line to delete it is processed. Therefore I need something to tell me that
the form is actually closed.

I'm sure (and I hope) this is a common problem, and there is a solution.
Click to expand...


This is absolutely NOT a common problem. I can not think of
good reason for deleting a form in a running program. It
sounds like your design has wandered down a strange path and
just now come to the edge of a cliff.

Have you tried using DoEvents between the Close and
DeleteObject methods?
 
Hi Marshall,

Many thanks for your reply. The addition of doevents seems to have solved my
problem

While I accept that sometimes I try things rather on the extreme ends, I
don't think that what I'm doing on this occasion is very strange.

What I'm trying to do is that, I have a template form that I use as the
skeleton of a number of forms, each of which is used in one part of the
program that I use to process orders.

For example, when the user wants to import some incoming orders to the
database, the skeleton form is copied under appropriate name, the option
group is filled with option buttons, with the label of each showing the name
of the order file itself (an excel file, stored in a predetermined
directory). The user selects one of the option buttons, and the
corresponding file is imported and processed. Once imported, the original
order file will be erased from that directory and the output of the process
will be placed in a different directory, to be the input of another process,
whenever the user selects the routine to process it. Due to the fact that
the number of files in that directory is not known, and will always be
different, I had to create the controls on the fly.

As if this is not enough, I delete the form after any file is processed, and
rebuild it from scratch to reflect the new structure of the directory, with
the processed file deleted.

If I just close the form and check for its existence whenever I need to use
the routine again, I don't have any problems to delete it, presumably
because the db engine has had the time needed to close it properly.

It could be said that I did not have to close it. Indeed, it was my first
choice just to delete the option buttons and recreate them as needed, and I
had built it this way. After some time, and just by chance, I read about the
"lifetime number of controls" that can be created on a form, which is
something like 745. Therefore, I had to rewrite a lot of things to avoid
getting a "too many controls" error message every couple of months.

Now, thanks to you, I think I'm going to have a working scheme.

Regards,
Engin Tarhan
 
oldguy said:
Many thanks for your reply. The addition of doevents seems to have solved my
problem

While I accept that sometimes I try things rather on the extreme ends, I
don't think that what I'm doing on this occasion is very strange.

What I'm trying to do is that, I have a template form that I use as the
skeleton of a number of forms, each of which is used in one part of the
program that I use to process orders.

For example, when the user wants to import some incoming orders to the
database, the skeleton form is copied under appropriate name, the option
group is filled with option buttons, with the label of each showing the name
of the order file itself (an excel file, stored in a predetermined
directory). The user selects one of the option buttons, and the
corresponding file is imported and processed. Once imported, the original
order file will be erased from that directory and the output of the process
will be placed in a different directory, to be the input of another process,
whenever the user selects the routine to process it. Due to the fact that
the number of files in that directory is not known, and will always be
different, I had to create the controls on the fly.

As if this is not enough, I delete the form after any file is processed, and
rebuild it from scratch to reflect the new structure of the directory, with
the processed file deleted.

If I just close the form and check for its existence whenever I need to use
the routine again, I don't have any problems to delete it, presumably
because the db engine has had the time needed to close it properly.

It could be said that I did not have to close it. Indeed, it was my first
choice just to delete the option buttons and recreate them as needed, and I
had built it this way. After some time, and just by chance, I read about the
"lifetime number of controls" that can be created on a form, which is
something like 745. Therefore, I had to rewrite a lot of things to avoid
getting a "too many controls" error message every couple of months.

Now, thanks to you, I think I'm going to have a working scheme.
Click to expand...


Sheesh, this is the third time this week there's been a
question about creating a form and controls on the fly. Is
it something about the season? Is it contagious? ;-)

This whole idea is kind of the wrong way around, so don't
thank me for anything having to do with it. I hope you at
least used acSaveNo when you closed the form to at least
avoid one more blast of changes to the mdb file. Just
copying a form is enough to make your application unstable
in terms of increased potential for corruuption and
certainly a major cause of bloat.

The standard way to deal with this kind of situation is to
precreate a sufficient number of invisible option buttons.
Then, instead of creating a new form object and new
controls, just use the one form and make the existing
controls visible as needed. No need to copy the form, no
need to create controls, no problems.
 
Hi Marshall,

It must be the Spring, which makes the blood boil.

I get the point, and I consider myself wise enough to bow down in the
presence of wisdom. In fact, your recommendation to use a precreated, fully
populated form had occurred to me, but I had felt too tired to create a form
with 45 option buttons and changing some of my code for the umpteenth time.
Now I'm going to take a breath, stretch myself a bit, and start producing
that form.

Many thanks again.
Engin Tarhan
 
oldguy said:
It must be the Spring, which makes the blood boil.

I get the point, and I consider myself wise enough to bow down in the
presence of wisdom. In fact, your recommendation to use a precreated, fully
populated form had occurred to me, but I had felt too tired to create a form
with 45 option buttons and changing some of my code for the umpteenth time.
Now I'm going to take a breath, stretch myself a bit, and start producing
that form.
Click to expand...


Hey, old? guy, if you're going to back up to where you took
the wrong turn at the fork in the road ;-)
You can save yourself the tedious task creating umpteen
controls by using the logic you already have for
CreateControl. Just make yourself a quicky design time
procedure that does it for you. This is what CreateControl
is for.

Depending on how much you can't do a design time, you might
want to use most of the logic (if not the actual code) in
the form's Open event. It's the same kind of thing, just a
little easier since common properties will be preset.

Another thought that might make managing all those option
buttons is to name them something like opt1, opt2, ... so
you can refer to them with the syntax:
Me("opt" & k)
so you can loop through your file folder and just grab the
next available option this way
k = k + 1
Me("opt" & k).Visible = True
. . .
 
Hi Marshall,

Thanks again for proving that the commonsense is common, after all.

This morning, after a good night's sleep and with a refreshed brain, what I
had done was exactly as what you have described. Even the control names are
used like that, and creation of a template form containing 45 option buttons
took about 3 minutes, including the transformation of code.

The form works like a charm.

I feel good, despite the heavy rain outside.

Thanks again.

Engin Tarhan (old equals 54)
 
Alright! Original problem solved, future problems avoided,
and all in 3 minutes of coding. That makes me feel pretty
good too. Although, right about now, rain sounds good
compared to what I've been getting lately.

I do have one more correction to another one of your
misperceptions. 54 is not enough to call yourself oldguy.
From my point of view, you're just a young whippersnapper
;-)
 
Back
Top