I think it was more a case of little things, rather than a single smoking gun.
Please note that I'm not trying to be mean/condescending, just descriping the approach I use. After several years and 7k posts on forums, you tend to develop a list of 'usual suspects' when debugging code.
That said, first, when I check/write code, I use
At top of the module. This forces me to have definitions for all variables. Not only does this help with compile speed, but helps me catch typos. For instance, at the part where you open the Billing files, part in bold is a typo
Since wbp was an undefined variable, that never gets assigned anything, this was always going to evaluate to True. Granted, the code then just tries to open up the wbIC file, so it might not cause a problem.
Next, I check With statements and parent-object tracing, making sure everything properly traces back up. If VB has to 'guess', where na object belongs, it assumes the active workbook/sheet. Again, this might work, but introduces risk as we don't always know what is going to be active.
An example of this was near end:
The highlighted Cells had no leading period, so was tracing up to active sheet, which would have been in the Rep workbook, not the Billing file.
The other part is parent tracing I mentioned. Things like this:
can be risky when dealing with multiple workbooks. If the active workbook has the sheet you meant to grab, great! If it wasn't...oops.
You should be able to look in the lastest file's code and see the corrections/changes I made. Let me know if you have any specific questions over what I did.
Please note that I'm not trying to be mean/condescending, just descriping the approach I use. After several years and 7k posts on forums, you tend to develop a list of 'usual suspects' when debugging code.
That said, first, when I check/write code, I use
Code:
Option ExplicitSince wbp was an undefined variable, that never gets assigned anything, this was always going to evaluate to True. Granted, the code then just tries to open up the wbIC file, so it might not cause a problem.
Next, I check With statements and parent-object tracing, making sure everything properly traces back up. If VB has to 'guess', where na object belongs, it assumes the active workbook/sheet. Again, this might work, but introduces risk as we don't always know what is going to be active.
An example of this was near end:
The highlighted Cells had no leading period, so was tracing up to active sheet, which would have been in the Rep workbook, not the Billing file.
The other part is parent tracing I mentioned. Things like this:
can be risky when dealing with multiple workbooks. If the active workbook has the sheet you meant to grab, great! If it wasn't...oops.
You should be able to look in the lastest file's code and see the corrections/changes I made. Let me know if you have any specific questions over what I did.