Use Scripting.Dictionary to support Word#33
Conversation
|
|
|
Ah! I see that his dictionary is a drop-in, so using it would give us the same name issue on Word. What about conditional compilation? Word supports per-project variables, so this could work: (and similarly for The Dictionary class is referenced by name in only six places (and only two in the core), so I don't think this would be undue clutter. What say you? |
|
The drop-in replacement needs to be unqualified since it lives in the same VBA project, and thus is resolved at priority 0 - qualifiers are redundant here, an unqualified I don't think there's an elegant solution for this problem, other than making the Word library calls explicitly qualified in the VBA project (i.e. not in vba-test code)... Or to use a unit testing framework that doesn't involve importing VBA code - like Rubberduck's (Windows only). That said, I'm just a watcher here, Tim might have other ideas =) |
On Word, `Dictionary` is ambiguous, since it could be `Word.Dictionary` or `Scripting.Dictionary`. Therefore: - In README, explain how to use VBA-Dictionary (thanks to @retailcoder, VBA-tools#33 (comment)) - For folks who want to use the native `Scripting.Dictionary`, add a conditional-compilation parameter.
2af15cc to
9ead5d4
Compare
|
@retailcoder Since the original changes were not workable, I have changed it to include the instructions for VBA-Dictionary in the README, and to include conditional compilation for those who want to use I have tested 9ead5d4 on Windows Excel 2013 and Word 2013, both with (For what it's worth, I'd like to get Word support into master because my next trick is a multi-file test runner for Word VBA :) .) |
Thanks for creating this project! I am using it on Word VBA. However, on Word,
Dictionaryis ambiguous, since it could beWord.DictionaryorScripting.Dictionary. This PR specifiesScriptingto avoid compilation failures.All tests pass on both Excel 2013 and Word 2013.
Thanks for considering this PR!