Code-modifying features should be disabled in Break mode

[Doev]

Hi,

I recognize this behaviour some times now, but finally I see the connection to the rubberduck addon. I can't reproduce the bug but this is what happend yesterday:

1) I pressed the "pending" button to analyze the project 2) I do a "indent" on the whole project

After that all event methods of all controls in all forms where disconnected. That means, that the vba-code was still in the modules, but in the visual designer, the event property was unset.

I remember that similar happend in the past, but I never saw rubberduck as the problem.

[retailcoder]

I presume Access forms are using member attributes to wire up with macros; if that's the case then rewriting the entire module would indeed lose the member attributes - this is a known issue and a rather hard problem to graciously handle, since the member attributes aren't visible in the VBE code panes: restoring them would require re-importing the modified modules.

Avoid indenting (or otherwise rewriting - this includes refactorings and inspection quickfixes) modules that have member attributes.

Note: ActiveX controls use a different interface-based wiring mechanism that isn't affected by this.

[bclothier]

No it doesn't use member attributes. Whether an event will fire is governed by another property of the form. In this example, I set the OnCurrent (displayed as On Current) property to string [Event Procedure]:

This wires up the event accordingly (and I added Debug.Print "hi"):

Now, if I were to delete the entire procedure, it automatically clears the OnCurrent property:

Likewise, when I use VBE's dropdowns to create the event handler... As soon as I select Form from the left-hand dropdown, Load event is selected by default, a empty stub created and the OnLoad property is then updated:

So, given this unindented code:

Indenting the module works and the property is still preserved:

Note, though, that pressing ctrl+z once to undo will lose the properties:

But redoing it or pressing ctrl+z for second time restores the properties as expected.

Do note that there has been known cases of the event properties becoming disconnected from VBA codebase in versions prior to Access 2010. Since Access 2010, the synchronization has been pretty robust.

I tried few weird indenting or different indenting commands but in no case could I reproduce the issue easily.

[retailcoder]

@bclothier so this is a no-repro for now?

[Doev]

I can reproduce the problem. If you start indent while the app is in debug mode, the events are disconnected.

1) create new Access Db 2) create a Form 3) create a Button (cancel the wizard) 4) create a click event on the button with one line of code: "stop" 5) go to Formview and press the button // VBE opens -> Debug mode 6) press pending 7) indent the project (maybe just the procedure works too) 8) the event is no more connected

[bclothier]

Hmm. I followed the same steps and I can't reproduce this. You didn't say which version of Access. Is it 2010 or newer?

[Doev]

2016

[bclothier]

I just tested on O365's 2016. Still can't reproduce it using same steps above... 😕

Can you give us the Rubberduck version? Maybe logs, too?

[Doev]

Windows 7 Microsoft Office Professional Pro 2016 I have done some tests. Only if the App is stopped in Debug mode, the events are unwired.

Version 2.2.6728.31668 OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office 2016 x86 Host Version: 16.0.4711.1000 Host Executable: MSACCESS.EXE

[bclothier]

Bleh, I'm retarded. I did not follow steps. I missed the part about changing to normal view and actually clicking button to enter the break mode.

So yes, I can reproduce. However, I also get the dialog asking me if I'd want to reset the project, which is expected given the command.

With that clarified, I'm inclined to say that this is going to be by design because we really should not be running a majority of Rubberduck commands while in break mode since it's most likely to reset the project's state. And resetting the project's state is something of a no-no in my book, especially when you have open forms since those get their states reset and who know what else wil happen.

Need moar caffine....

[Doev]

Same on this PC

Version 2.2.0.3918 OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4711.1000 Host Executable: MSACCESS.EXE

[Doev]

yes, after knowing the problem, it is not a big problem anymore. Maybe a test for "beeing in debug mode" when the user press indent, would be fine.