Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Scripting.Dictionary to support Word #33

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cxw42
Copy link

@cxw42 cxw42 commented Apr 3, 2019

Thanks for creating this project! I am using it on Word VBA. However, on Word, Dictionary is ambiguous, since it could be Word.Dictionary or Scripting.Dictionary. This PR specifies Scripting to avoid compilation failures.

All tests pass on both Excel 2013 and Word 2013.

Thanks for considering this PR!

@retailcoder
Copy link

Dictionary should probably be Tim's Dictionary class rather than Scripting.Dictionary - merging this PR as-is would break Mac support AFAICT.

@cxw42
Copy link
Author

cxw42 commented Apr 3, 2019

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:

#If scripting = 1 Then
    Dim d as Scripting.Dictionary
#Else
    Dim d as Dictionary
#End If

(and similarly for New calls). The README would then include the instructions for setting the variable if you're on Word.

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?

@retailcoder
Copy link

retailcoder commented Apr 3, 2019

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 Dictionary will never be a Word.Dictionary or Scripting.Dictionary if there's a Dictionary class in the VBA project; a fix would be to qualify the calls into the Word object model, which are resolved at priority 2, just after the VBA standard library, at priority 1.

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.
@cxw42
Copy link
Author

cxw42 commented Apr 5, 2019

@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 Scripting.Dictionary.

I have tested 9ead5d4 on Windows Excel 2013 and Word 2013, both with Scripting.Dictionary and with VBA-Dictionary. I don't have access to a Mac, so unfortunately can't test there.

(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 :) .)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants