Settings

The settings are persisted in XML format under %APPDATA%\Rubberduck\rubberduck.config; each tab contains the settings stored under a corresponding tag.

Import/Export

You can easily export settings to and import settings from any XML file, using the linkbuttons in the upper right of every settings tab.

Reset

This button restores the settings to the defaults. You’ll find these defaults under %PROGRAMDATA%\Rubberduck\Rubberduck.Core.dll.config, assuming the installer installed Rubberduck in the default location.

Cancel

Clicking this button, or pressing the ESC key, will dismiss the settings dialog without saving any changes.

Ok

Accepts the changes and persists them to the user’s XML configuration file.

---

This tab contains application-level configuration, e.g. UI language, startup options, parser settings, logging, …all things that may or may not eventually be expanded into their own settings tab. The Hotkeys are only on this tab to fill up the otherwise empty space (they’re their under their own tag in the XML configuration file).

Display language

Determines the language to use for the Rubberduck UI. Rubberduck currently supports English, French, and German. Translations for additional languages are welcome!

Show splash screen at startup

Determines whether or not to display the Rubberduck splash screen.

Check if a newer version exists at startup

If checked, Rubberduck sends a single HTTP request to rubberduckvba.com/build/version/stable at startup, retrieving the version number of the Rubberduck.dll build that’s currently deployed on the project’s website – yes, Rubberduck is running on the website!

Compile code before parsing

One of the assumptions Rubberduck has been making since its early days, is that it’s working against compilable VBA code. Checking this option enforces this: code that can’t be compiled, won’t be parsed.

Parsing?

Rubberduck uses the VBIDE API (essentially your everyday VBE Extensibility Library) to get to the source code in the editor. This has implications:

• Rubberduck needs to “refresh” its internal representation of the user’s code whenever the code changes – the VBIDE API isn’t telling us! Changes made since the previous parse WILL be lost if you make Rubberduck work off an out-of-sync parse tree.
• Rubberduck needs to build its internal representation of the user’s code starting with a string that contains a whole module’s code. The tokenizing and parsing steps are actually pretty fast.. the longest part of “refreshing” is making sense of the code. Make the best use of parser state caching by modifying only a single module between two refreshes; after the initial parse, only modified modules are re-processed.
• Rubberduck can’t [yet] rewrite a module without blowing away any/all member attributes. Member attributes WILL be lost if you let Rubberduck make changes to a class/module with member attributes.  This is infuriatingly annoying, and addressing this is …complicated. But we have a plan. And in the meantime, we will soon be prompting to cancel the rewrite operation if a module contains member attributes.
• The VBIDE API does not expose breakpoints and bookmarks, so Rubberduck has no [easy] way to know anything about them. Breakpoints and bookmarks in a module are lost after Rubberduck rewrites the module.

Minimum Log Level

Determines whether logging is enabled, and at what level log entries are written. TRACE level produces the most verbose logs; ERROR level will only log exception details. Logging is disabled by default in a release build. Logs are written to the %APPDATA%\Rubberduck\logs folder, in plain text, and may contain identifier names such as modules and variables, VBA expressions that failed to resolve correctly, as well as line and column numbers; this helps locate a problem in the code, but generally does not provide enough information to reproduce the problem without the original code.

Hotkeys

Rubberduck wires up a number of commands to configurable hotkeys. Hotkeys require at least one modifier key (Ctrl, Alt), and must be unique.

Experimental Features

There are no features deemed “experimental” in release 2.2, however it’s not impossible that future versions include various IDE features that would be “opt-in” by default, for various reasons. This section is where you would enable/disable them.

---

This tab lets you configure “todo markers” – things Rubberduck can spot in a comment, keep track of, and then let you easily navigate there with the Todo Explorer toolwindow.

 Public Sub DoSomething() ' TODO rename this procedure
 End Sub
 

---

Each Rubberduck inspection has an inspection type; we use these to regroup the inspections and results. And because we’re starting to have quite a good number of implemented inspections (and there’s over 100 more down the pipeline), you can now filter by description using the textbox at the top of the Inspection Severities section:

Inspection Severities

This section lists all available inspections and their “severity” level, which controls whether they’re enabled and which icon the results will use. To disable an inspection, set its severity level to DoNotShow, and it won’t run at all. If trace logs indicate that a particular inspection is taking an exceedingly long time to process everything, disabling that inspection could be a way to improve overall inspection performance.

• DoNotShow disables an inspection.
• Hint is depicted with a white circle information icon .
• Suggestion is a blue circle information icon .
• Warning level is a yellow triangle exclamation icon .
• Error level is represented by a red circle cross icon .

[Fugue Icons by Yusuke Kamiyamane]

Note that not all inspections are enabled by default: this is by design, because some inspections flag the exact opposite of another inspection. If your convention is implicit ByRef, then you’ll want to enable the redundant explicit ByRef modifier inspection; conversely if you prefer ByRef modifiers to be explicit everywhere, then you’ll want to enable the implicit ByRef parameter inspection. This makes Rubberduck inspections less partial toward the developers’ own style/preferences, and more geared toward enforcing a (read: any) consistent coding convention.

Whitelisted Identifiers

The use meaningful names inspection will ignore these identifiers verbatim. The Hungarian Notation inspection will ignore them as prefixes. This means if you white-list ws, then wsCurrent will not be reported as a Systems Hungarian identifier, and Rubberduck inspections won’t suggest to rename ws with a meaningful name.

Miscellaneous

There’s a checkbox at the very bottom, that’s rather easy to miss (poor UX, admittedly). Checked by default, it determines whether inspections run/refresh automatically after a successful parse.

If this box is unchecked, inspections will only refresh automatically when the parse is initiated from the inspection results  toolwindow, or after applying a quick-fix.

---

These options are used by the unit testing feature, and will not affect existing test modules, only how new ones are created.

Binding Mode

If Early-bound, then the AssertClass is declared as such, and a reference to the Rubberduck.Core.tlb type library is added to the VBA project if it’s missing. Recommended if you’re unfamiliar with Rubberduck’s unit testing API.

If Late-bound, then the AssertClass is declared as Object, and no reference to the Rubberduck.Core.tlb type library is added to the VBA project.

Type Safety

By default, the AssertClass uses .NET equality rules, and the types must match exactly. Using the PermissiveAssertClass instead, makes equality rules more in line with VBA’s implicit type conversions, and a Double can be compared to an Integer if needed.

Test Module Template

Each checkbox determines whether Rubberduck should include a given set of members when creating a new test module.

• ModuleInitialize runs once per module, before that module’s tests run.
• TestInitialize runs once per test method, before the test runs.
• TestCleanup runs once per test method, after the test completes.
• ModuleCleanup runs once per module, after that module’s tests all completed.

“Insert test method stub” determines whether a new test module should be created with a stub test method. Useful if you’re unfamiliar with the feature, or with unit testing altogether.

---

This tab contains all the original Smart Indenter settings, and then some. If you’re using the original VB6 Smart Indenter add-in, Rubberduck will prompt whether to import the indenter settings from the Windows Registry.

There are a lot of settings here. Best way to introduce them is to play with them.
Try it online!

---

You may want some toolwindows to always be visible at startup; these checkboxes determine which toolwindow Rubberduck will ensure startup visibility of.