Solved Ugly new Access bug (1 Viewer)

[Pat Hartman]

When there is no error in the form name, the code works correctly. The fix is trivial. FIX the form name. The issue is that when there IS AN ERROR, Access will not let you close the form without resorting to Task manager. This error is not something you would encounter randomly in production. It is an error that would occur during testing because sometimes our code doesn't work right the first time.

 

[KitaYama]

Access will not let you close the form without resorting to Task manager.

You may have missed @Josef P. 's replies #31 & #39

 

[Pat Hartman]

You may have missed @Josef P. 's replies #31 & #39

Did you try the database I uploaded? The POINT is that I cannot close the form WITHOUT either fixing the erroneous form name or commenting out the code or resorting to task master. I can put the form in design view by selecting the debug button from the Access message but closing the form from design view persists in running the bad code in the unload event. When I close the form from design view, it should not be attempting to run any code at all. That is the bug. You are all correct but I do not expect the form to close correctly from form view because it will always have to run the unload event but once the form is in design view and the code is stopped. I should be able to just close the form without Access trying to run ANY of the form's code. Why when the form goes from design view to closed, is it insisting on running the unload code? That seems to be a flaw in the Access code. The form should simply close without running ANY of my form code at that point.

 

[KitaYama]

Did you try the database I uploaded? The POINT is that I cannot close the form WITHOUT either fixing the erroneous form name or commenting out the code or resorting to task master. I can put the form in design view by selecting the debug button from the Access message but closing the form from design view persists in running the bad code in the unload event. When I close the form from design view, it should not be attempting to run any code at all. That is the bug. You are all correct but I do not expect the form to close correctly from form view because it will always have to run the unload event but once the form is in design view and the code is stopped. I should be able to just close the form without Access trying to run ANY of the form's code. Why when the form goes from design view to closed, is it insisting on running the unload code? That seems to be a flaw in the Access code. The form should simply close without running ANY of my form code at that point.

I understand and understood your point from #1.
You insisted on "Can not close form without task manager" several times, and Joseph showed a solution to bypass the problem without terminating Access, twice. In both occasions you didn't reply if his solution is accepted or not. I just wanted to be sure you've not missed the possible work around. That:s all.

 

[Pat Hartman]

I understand and understood your point from #1.

Everyone else seems to think it is perfectly logical for Access to attempt to run form code when closing the form from design view.

I corrected that statement later on to either modify the code or use task manager. If I'm going to modify the code, why not just fix it? The fix was trivial once I realized what I had done, but I didn't know what the fix was until I managed to close the database using task manager and then see why the named form was missing. Adding a useless error trap to the code also allows the form to be closed.

 

[mloucel]

This just blow my mind.
I learn so much here.

 

[gemma-the-husky]

Did you try the database I uploaded? The POINT is that I cannot close the form WITHOUT either fixing the erroneous form name or commenting out the code or resorting to task master. I can put the form in design view by selecting the debug button from the Access message but closing the form from design view persists in running the bad code in the unload event. When I close the form from design view, it should not be attempting to run any code at all. That is the bug. You are all correct but I do not expect the form to close correctly from form view because it will always have to run the unload event but once the form is in design view and the code is stopped. I should be able to just close the form without Access trying to run ANY of the form's code. Why when the form goes from design view to closed, is it insisting on running the unload code? That seems to be a flaw in the Access code. The form should simply close without running ANY of my form code at that point.

@Pat Hartman
I demonstrated that you can error trap the call to an erroneous/non existent form, complete the unload and close the form gracefully, unless I was missing some other reason why there was an error. I didn't need to resort to having to terminate the Access process. My example will close the form in design mode without running the unload process.

However, in retrospect I did have an issue that the debugger kept objecting to the direct use of openargs, reporting bad null values, that sort of thing. On reflection I think that was happening in design mode also.

This is why I ended up used the fname variable, as I couldn't prevent it otherwise.

I thought maybe by the time the form tries to unload, openargs has become undefined/out of scope rather than just null. Maybe that's what you were seeing also. Anyway, I just couldn't prevent these openargs issues whatever I did, so I added the variable to store the openargs value. I don't normally use accdb's. I'm not sure whether it would have done the same with an mdb. Maybe there's been another change in Access that's causing this issue, and it's a new bug as you mention.

What do you think? Try using a variable to store the openargs value. See if it makes a difference.

 

[Pat Hartman]

@gemma-the-husky I'm not sure how many times I have to say this without hurting the feelings of those who are trying so valiantly to help which I reallllly don't want to do since I do appreciate the time spent on looking at this thread. I understand what the initial problem with my code was. It was trivial to fix. I fixed it before I made this post. I understand that adding error trapping in that particular event will prevent the error from being raised. I understand that at least some of the other code suggested would have hidden the problem. NONE of those things are what this thread is about. I don't need any help to fix what you all think is the problem. I fixed the code as soon as I realized that I had copied it from a database that used a different main menu than the one I copied the form into. I don't need any help to fix my code. Thank you anyway. Why is everyone so obsessed with fixing "my" code which was fixed before I made this post rather than trying to understand the question I posted?

But, It was the error caused by the faulty code that prompted this thread. The central question is WHY is Access trying to run form code when my form is in design view with no code running and I close it from that view. The form is technically not "open". WHY is Access opening the form so it can try to run the unload code when the form is being closed from design view? That is the question I asked for help with.

I thought maybe by the time the form tries to unload, openargs has become undefined/out of scope rather than just null.

No. The code works fine once I fix the bad form name.

 

[isladogs]

Everyone else seems to think it is perfectly logical for Access to attempt to run form code when closing the form from design view.

The central question is WHY is Access trying to run form code when my form is in design view with no code running and I close it from that view. The form is technically not "open". WHY is Access opening the form so it can try to run the unload code when the form is being closed from design view? That is the question I asked for help with.

Both of those statements are completely incorrect.
Nobody has stated that behaviour is OK and in fact it does not happen as you describe.

Once the form is in design view it will close without running any code

Steps to reproduce:
1. With your flawed code, attempt to close the form in form view then go to Debug & stop the code
2. You cannot change to design view as doing that requires unloading the form.
3. Comment out that code. Now change to design view - of course it now works without error as the unload code is disabled.
4. To prove the point stated above in bold, now reinstate the commented out Form_Unload code
5. Close the form from design view

 

[Josef P.]

A picture is worth a thousand words ...

You might expect similar behavior when switching to design view (from ribbon).

 

[Pat Hartman]

Once the form is in design view it will close without running any code

When the error happens, you have a message with four buttons as posted in #1.
Continue, End, Debug, Help.
Continue is grayed out. End stops the code from continuing but leaves the form open. Debug, puts you in design view with the error highlighted.
Help is useless.

So, continuing on the Debug option since none of the other three do anything even remotely helpful. I stop the code from running. That should allow me to close the quiescent form. It does not. The issue seems to be that the failing code is in the Unload event which Access insists on running.

I KNOW THAT I CAN STOP THE CODE FROM RUNNING if I comment it out. How many times do I have to say that? I hear you. I hear you. I hear you. Once the code is stopped, I think I should just be able to close the form without running ANY code. You disagree. OK, you disagree. I hear you. I hear you. I hear you. Thank you very much for your contribution. There is no reason to continue this circular conversation. Thank you. Thank you. Thank you. Can we please be done with this part of the lesson.



What we have learned from this discussion is that if you have any code in the Unload event, no matter how innocuous or how unlikely to fail, you MUST include error handling or you will never, ever be able to get past an error raised that that particular event. This may also apply to other events that run during form shut down. You end up with no graceful way to close the form. You MUST get rid of the failing code or use Task Manager to close the form. So, even if there is technically nothing wrong with the code, meaning the fix is something external to the form, you still MUST change code somehow to keep the failing instruction from running because Access can't take a joke and will NEVER let you close this form as long as the error is not removed. PERIOD. So, even though in my case, I initially thought I needed to import another form, I couldn't exit to fix the problem without modifying code that didn't need to be modified. Very friendly MS.

Ah Ha, @Josef P. has actually found the solution. He found a magical sequence of keystrokes which if executed in the described order, gets past the problem. Thank you Josef. But it shouldn't have been so hard to get out of this stupid loop.

 

[isladogs]

@Pat Hartman
I dropped out of this thread some time ago and only rejoined to respond to incorrect statements you made.

It would appear you missed the whole point of my last post even though I put the most important part in bold type.
Whilst you say you hear what people have been saying throughout this lengthy thread, you continue to make incorrect statements.

To repeat, you stated that code should not run in design view. I agree completely. It should not and indeed does not happen.
Nor does it happen using your example form with its flawed code.

 

[Josef P.]

But it shouldn't have been so hard to get out of this stupid loop.

Exactly!
As I wrote, I would have expected the same thing when switching to the design view via the ribbon as when switching via the VBE.
I would consider it acceptable that the form does not close "normally" because the closing process is interrupted by the error.

 

[gemma-the-husky]

When there is no error in the form name, the code works correctly. The fix is trivial. FIX the form name. The issue is that when there IS AN ERROR, Access will not let you close the form without resorting to Task manager. This error is not something you would encounter randomly in production. It is an error that would occur during testing because sometimes our code doesn't work right the first time.@pat h

@Pat Hartman

Surely a bad form name is an error like any other, and it needs to be tested and handled. If you did that in runtime, and didn't handle it, wouldn't it just crash the programme.

I don't see why you wouldn't just error trap the docmd.openform and handle it.

However, what I did notice was that I also got strange results when I tried to use your exact code initially.it wasn't the form name causing the issue. I kept getting unexpected errors to do with the code unexpectedly rejecting the use of openargs in the way you have it. I was only able to fix it by assigning the value of openargs to a variable. Therefore I think the openargs feature/argument itself is causing the issue, which may or may not be an existing bug, or even a new bug.

Hence I wondered if you rewrote your unload sub to set a string variable to the value of openargs, and then tested the string variable rather than openargs it would probably report the error with the form name and then close.

I say this because all I had was a single form, opened with no openargs value, and just the unload procedure, and I really struggled to get the unload code to run properly when I clicked the X to close the form because of the above issues with openargs. It only behaved when I used a variable to store the openargs value rather than an inline function, as it were.

I really am trying to be constructive because I did get unexpected results initially, and it was much harder to eliminate them than I expected.

Unexpectedly I noticed the thread is now closed, but I was able to save this post.