Solved Determine What Code Is Still Running?

[gemma-the-husky]

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.



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.

But the forms opened by access will (should) work correctly as supplied, and will never cause a debug error.
The prompt you are seeing must be caused because whatever you are trying to do is not compatible with currently running code.
You won't see that by editing code while the database is not running.

What is making you enter the code with the debugger? Are you seeing an error and trying to deal with it.

As an example, I have developed some code to amend modules. You can for instance iterate the modules, and add code to a module, or all modules. If I want to add code to me On Load routine I can do that.

Running this code does edit the modules correctly, but also silently stops the current database running. You don't see the message you are seeing, but the project does get reset. I think it's easy to understand why this would be outside the editor's ability to keep track of the project code. Making changes one at a time may or may not need the project to reset.