Solved Determine What Code Is Still Running? (2 Viewers)

dalski

Member
Local time
Today, 13:37
Joined
Jan 5, 2025
Messages
140
When I go to debug I'm getting "This action will reset your project, proceed anyway?". The problem occurs in a certain sub-form, with classes & user-declared events... My code is running fine, but this does not seem good practice; or am i being pedantic? I've stepped through code looking at the call-stack & I cannot see any issues.

Is it inevitable that when there are user-declared events/ normal events the code will be in a 'suspended' fashion (do not think so) & the IDE will always prompt this warning or do I have something seriously wrong here? Seems https://www.mztools.com/ will identify the issue but I'd rather save some money & try to figure out where I'm going wrong if possible. Annoyingly I cannot post the db as it something I have been working on for a long-time. I thought it may be when I set a TempVar elsewhere but this is not the case as I'm not getting the prompt when this is done (in another form/ procedure). Any advice on what to look out for?
  1. Hitting Ctrl & Pause (break appears in top of the IDE window) & it works fine then for that instance of Access. I only need to do this once in that instance of Access & I can open & close the relevant form/ subforms repeatedly without the problem occurring again for that instance of Access - as per https://stackoverflow.com/questions...y-with-message-code-execution-has-been-halted but does not seem a proper fix.
  2. Some suggest putting DoEvents somewhere in the code to free the App to process events so put this in the Form load event but no joy (nor would I want it to really as this doesn't seem right).
  3. Some advise repairing Microsoft Office as Office can generate a bug apparently; like ghost break-points. Forcing a rebuild of Office's native COM Components. EDIT - did this no joy so problem must be code-related.
  4. I put an Error trap in the Load event & this has shown a type mismatch Error-13; currently investigating where this is & if it bears fruit. I'm not optimistic as if I clear the error I still encounter the issue.

  • Decompiles fine with no errors
  • Form & relevant sub-forms are not currently open in modal view/ acDialog awaiting user-response. I do have buttons/ procedures to open some in acDialog but these have not been executed in the open event...
  • Compact & Repair done
 
Last edited:
Sorry - if I create a new sub/ function from the problematic form/ sub-form I will get the prompt indicating some code is 'suspended/ running'.

If I create a new sub/ function I do not get this prompt.
 
Last edited:
Can you open the file in shift bypass mode and still get the error when you hit Ctrl+G?
 
Thanks, I still get the error.
Supposedly, when you open the app using the shift bypass, no procedure should be running, so you seem to have an odd situation going here. Are you able to post a sample db to show this problem?
 
To clarify I do not get the error outside of the form/ sub-form in question; from starting up normally or from shift-bypass. All other areas are fine. The process is only running because I loaded the form after loading up from shift-bypass; alas I get the error.
 
Last edited:
To clarify I do not get the error outside of the form/ sub-form in question; from starting up normally or from shift-bypass. All other areas are fine. The process is only running because I loaded the form after loading up from shift-bypass; alas I get the error.
Ah, but that wasn't the process I asked you to do. I merely said to hit Ctrl+G and didn't say to open any form. So, I guess you don't get an error if you did what I asked then, right? Still, a demo file would really help make things clearer for us, no?
 
Last edited:
If you modify code while the process is suspended I believe you will get that notification.

Do you have code running in the loading events?
 
I have a few events firing & yes the load event is the first that kicks things off. Tracing through them I cannot see any 'suspended' code relating to the events/ code in question. Appreciate I might be a bit cavalier/ wrong here; but I have cautiously watched the calls & sequentially terminate. It is after this (Load event completion and all called procedures/ events) that the fault is found. Could be an unclosed pointer of an object not properly closed maybe.

Appreciate a db should be uploaded but I cannot do this. I thought I would ask the question in case someone was aware of any likely issues they had previously encountered.
 
Last edited:
I have a few events firing & yes the load event is the first that kicks things off. Tracing through them I cannot see any 'suspended' code relating to the events/ code in question. Appreciate I might be a bit cavalier/ wrong here; but I have cautiously watched the calls & sequentially terminate. It is after this (Load event completion and all called procedures/ events) that the fault is found. Could be an unclosed pointer of an object not properly closed maybe.

Appreciate a db should be uploaded but I cannot do this. I thought I would ask the question in case someone was aware of any likely issues they had previously encountered.
I have run into that warning but only while in dev mode. I have never encountered it on a production copy.
 
Interestingly if I comment out all code in the problematic form I still get the error. Close the form, open another form (various) - no issues!
Created a copy of the form. Commented out all code again. Still get the issue as if there is suspended code. But there cannot be. No other processes have been initiated since. Must be a problem with the record source; which is based on a union query.
 
I think if fixing the debug error needs certain code logic to change, then the debugger can't always continue, and has to close. Sometimes you can fix an issue, and sometimes not, in my experience.

This is all part of testing, and developing a robust app that handles any circumstance without encountering any unhandled error.

It's one reason why you need to save program edits before running code, as some errors will cause you yo lose the edits. I know I've been there.

ALso if the error handling is not precise it may not be obvious which circumstance actually caused the error when you jump to the error handler.
 
We may have a conceptual disconnect here, but maybe not. You want to know what code is running that would be affected if you take the DEBUG option. But I don't believe you can EVER take a DEBUG option unless at least one event with your code is running, even if suspended. Access - more specifically, the code that is built in to MSACCESS.EXE - will not show a DEBUG option for its own code. You cannot debug Access itself.

Perhaps you should open the code window as suggested via CTRL/G and then from the Menu Bar, open the View Stack to see if it tells you anything. I could be wrong on this, but I think you will always see at least one event on the stack. There is also the odd chance of having a timer active, which could represent running code.
 
Interestingly if I comment out all code in the problematic form I still get the error.
Error?
What error?
The message you mentioned is a friendly reminder/question that your code change will cause the running application to be stopped. It is not an error!

if I create a new sub/ function from the problematic form/ sub-form I will get the prompt indicating some code is 'suspended/ running'.

If I create a new sub/ function I do not get this prompt.
This behavior is perfectly normal.
Once you start your application by either explicitly running code from one of your Access objects or by instantiating a VBA class (opening any form/report with HasModule=True) the application including its VBA code will be running. It will continue to run until lit is explicitly stopped.
The VBA environment has a very amazing(*) ability to let you make code changes while the application keeps running. Some changes however, like those that would affect the public representation of elements currently in use by the running code, cannot be made without stopping the running application. - That's when the VBA environment will ask you whether you want to terminate the running code or discard your code change.

*=It took Visual Studio 15 years to get a similar capability (Hot Reload) for .Net code. - Hot Reload might be somewhat more powerful, but it still encounters situations where it can't patch the running code and the application must be explicitly stopped and recompiled.
 
You can set a break point to halt a program while the code is running normally, and the debugger will open and let you step through the code a line at a time. You can check the value of variables and so on. It's helpful for fixing hard to find problems.

In this case you can edit the code, but sometimes the edit you are trying to make will cause the program to reset.

If you are running code and the program gets an unhandled error, then the debugger will automatically open, at the line that caused the problem. As already noted you may not be able to alter the code in every case at this point.

If the code is not running, you are just editing code modules.
 
Let's say you have a problem with something when you move to a different record in a form. You will either have a current event with code, or the form/program will just sit and wait for you to do something.

If you don't have a current event, the program can't jump into your code at this point because there is no active code line. The program is waiting for an interrupt that tells it you have moved a mouse or pressed a key which caused an event in your program to be activated. If you have no event handler for the actions you still won't be able to jump into the code. Eg, you are just typing into a text box, or several text boxes until you save the record , and move to another record.

Either all of these things happen correctly without any program intervention, until something unexpected happens.

It might be that you press a command button, which caused code to run (on click event). So you can set a breakpoint for the clock event.

If you have a current event and want to see what happens put a breakpoint at the the first line. Now at this point the debugger will take you to the first line in the current event code. Now you can press F8 and step through your code a line at a time to follow the code execution. It can be tortuous as you may have some loops that require a lot of F8 options. You can set more breakpoints and use F5 to run the code and it will stop at the next breakpoint.

Doing this sort of thing you might find that a section of code that you think is working is not actually getting called because your logic isn't quite right.

Once you get this fixed, you can clear all the breakpoints, and continue with your development.

If you don't have a breakpoint you can't step into the debugger. Your program just runs until it actually reaches a breakpoint, or reaches an unhandled error.

A different sort of error is that an automatic record save might fail because you have a duplicated record key which access has to reject. Now you get a run time error. Now you may have set a form error event handler and that code event will run. That's what you need for a data management error. You may not have any error handler and the program will stop with an error message and the program will let you jump to the active line.

Offhand I am not 100% sure which line you see in this case, or whether you can always fix it at run time. You may have to stop the code, add the appropriate error handling, save and restart the code.

Note that your error handling can't just be "on error resume next". That might be appropriate for some errors but other errors need to be reported and acted on, or your program will misbehave and not do what you expect.
 
Last edited:
When an event such as 'On Load' of a form is raised, you can not only respond to it using code in the corresponding module of the form (Code Behind Form) (in which case the event property would contain '[Event Procedure]').
You can also enter the name of a function with the corresponding scope directly in the event property (in this case, in the form property 'On Load'). The event property will then contain, for example, '=MyProcedure()'.

It's best to check the properties of the form for this too.
 
Thanks, I think I muddied the waters a bit in post-01 with talk of user-declared events. Been using Access' standard events for sometime & fine with them. I am referring to user-declared classes & class-instantiations handling events raised from other classes...

In Nr-12 commenting out all code in the problematic sub-form & reopening the db - this should have eradicated the problem completely. But it did not. This can only be bug/ unintended memory retention. There were no procedures unterminated at this point & the problem has been traced to the specific sub-form. Removing all code should have fixed this but it did not. Maybe restarting the computer has completely flushed the memory.

Error?
What error?
The message you mentioned is a friendly reminder/question that your code change will cause the running application to be stopped. It is not an error!

This behavior is perfectly normal.
Once you start your application by either explicitly running code from one of your Access objects or by instantiating a VBA class (opening any form/report with HasModule=True) the application including its VBA code will be running. It will continue to run until lit is explicitly stopped.
The VBA environment has a very amazing(*) ability to let you make code changes while the application keeps running. Some changes however, like those that would affect the public representation of elements currently in use by the running code, cannot be made without stopping the running application. - That's when the VBA environment will ask you whether you want to terminate the running code or discard your code change.

Thanks @sonic8 , I think you solved it:
  • Yes there are open user-declared class instantiations open. So if an open class instantiation generates this prompt then that is the thread solved.
    • Tested by creating a new self-terminating class. No prompt generated when creating a new sub. Repeated the exercise, set properties to the class; assigned values to the properties; did not terminate the class - PROMPT GENERATED (confirming @sonic8 's logic).

The Counter Argument
BUT Access has it's own class instantiations open all the time (forms, queries, controls/ sub-controls...) & never throws the prompt when a new sub is being created.
 
Last edited:

Users who are viewing this thread

  • Back
    Top Bottom