Hello, I was wondering why sometimes in VBA I cant press Run to test out my code. I'm not sure how to simulate it, so I hope somebody just recognizes what I mean. It seems like Visual Basic gets in some sort of state where it looks like it is done running all the code, but it isnt. In order for it to run again, at least its what I do, I press the Reset or Pause button and or via menu Debug -> Compile VBAProject. Its something with code debugging/code cancelling..
Does this ring a bell with anybody? I would like to pinpoint what this behaviour is exactly. If nobody does I'll figure out a routine where this happens
And I'm quite sure it relates to the state of module level variables as well: when a class is instantiated in a global variable, after some procedure is done running the code, even though the class_terminate was called and executed, it seems like there is still something in memory. Any clues?
When I'm reading about it in the docs, it always talks about "which lasts for the entire time your application is running.".. But even when code ends normally, something of a state is remembered and later used
@jonadv This sometimes happens when I think something has finished but it hasn't. Maybe there's a userform up somewhere but hidden. Generally I just mash the square stop button and it's all fine, never have to recompile. Also state can persist in module scoped variables, so you run a Sub and it exits but there are still some event listeners in a collection declared in outside the sub (although these won't stop you being able to run things).
Like if you want to set up an event listener for Worksheet_Change events, the VBA isn't constantly running but you still have objects floating around in memory. VBA is built on COM which means objects manage their own lifetimes by counting things which reference them, so it's totally fine for them to stick around after the code "ends normally" if that makes sense? Sorry not sure this is what you're getting at.
Also watch out for circular references. But again, all these objects hanging around in memory shouldn't grey out the run button, that's only if some other code is currently running the VBA interpreter and you don't know about it. Are these RD unit tests?
"VBA is built on COM which means objects manage their own lifetimes by counting things which reference them, so it's totally fine for them to stick around after the code "ends normally" "
Thanks, this makes perfect sense. Even though I dont use UserForms or Worksheet_Change events, over time probably snuck into my code library (just 1 .xlam file) which causes this
I have VBA developer (github.com/hilkoc/vbaDeveloper) installed since a few months and that has some workbook_[events], might be a cause. I tried RD for a bit, but couldnt find any big advantage for the work Im doing in vba
So its not with RD tests/I tried and then uninstalled it a couple of months ago
is there any way to view the " things which reference them," (after code ends)? Does RubberDuck have such a feature?
VBA Rubberducking
VBA Rubberducking