-
Notifications
You must be signed in to change notification settings - Fork 35
Conversation
See issue #4 and #5. This commit presents a solution which I think is simple and appropriate. #4 #5 The screenshot was removed because it is no longer relavent. Perhaps @spences10 can make a new one :)
I hope these instructions are clear
To make development easier, I set up a template Excel file. This Excel file is blank and has references to the nessesary libraries set already. To build the Add-in, open the template file and then import the files listed in the CodeExportFileList.conf (perhaps using a version of this tool already installed). Note that I have had to leave an empty module in the template file because Excel will delete the library references without it. This may be a problem to address with this tool.
My own decision bite me faster than I expected. I decided to add the template file to the gitignore file so that people wouldn't accedientally commit changes to it. Turns out that loosing work is worse then commiting mistakes.
The project was being renamed in the MakeFileList method. This was for historical reasons which now don't apply. The project name should be set at build time, not at run time.
If the Add-In is password protected it can't be accidentally edited in the VBE. This will keep you sain.
The project name was left as the default. This resulted in the built add-in having the default project name. This change fixes that.
The rubberduck VBA IDE code inspection tool shows possible problems with VBA code. Using this a few bits of the code was improved. * Accessors (Public / Private) were explicitly stated. * Procedure parameters / arguments "pass by" types were explicitly stated. * The use of the Is keyword was removed as it will most likely confuse others. * Some unused variables and procedures were removed. * Short variable names were replaced with more descriptive names I tried to apply a consistent code style based on the existing code style.
Previously, the format used for the config file was a simple list of key-value pairs which was represented in a text file using line breaks and colons. Additionally, square brackets had special meaning as well. Even for this simple serialization requirement, there was already a lot that the developer has to think about. For example there was a function which cleaned out strings to make sure the didn't break the serialization. A feature which will be implemented soon would be a lot easier to do if the config file was in a format such as JSON. Since JSON is fairly easy to read and write it seems like it doesn't introduce complexity. There is a popular open source VBA library for reading and writing JSON called VBA-JSON. I used this library and this simplified the data serialization code dramatically. I changed a few details of how the actual importing and exporting works, however there should be no loss of functionality. Relative and absolute file paths should now be supported, however I have not tested this yet. I have only tested the case where all files are in the base directory.
Hmm, strange. So the problem is that Dictionary.cls is being imported as a standard module instead of a class module. How are you importing the modules? Are you manually importing them? The config file has been changed to Json format as well so you won't be able to use a previous version of the add-in to automatically import the modules. |
I opened the VBA-IDE-Code-Export.xlsm, dragged and dropped the component into the VBA IDE, is that not how you want to do it now? |
That should work. What version of Excel are you using? |
I use office 360 |
I found the following issue with another bit of code made my timhall: VBA-tools/VBA-Web#24 It seems like exactly the same thing that is happening with Dictionary (which was written by timhall) |
Here is the issue for this exact library VBA-tools/VBA-Dictionary#5 (comment) It seems to be a problem with line endings. A quick solution is not to use the Dictionary from VBA-Dictionary and instead use the Dictionary from the Microsoft scripting library. They are interchangable. |
@Spence10 was having trouble importing the Dictionary.cls. The VBA-Dictionary project has encountered this same problem before and concluded that the problem was due to having Unix style line endings in the VBA source files (especially class modules). Firstly, a git attributes file was set up to make sure that VBA modules are converted to windows style line endings. Secondly, the use of the drop in Dictionary replacement is so that Excel for Mac is supported. However, the Microsoft scripting library is already used for file system purposes and therefore Mac isn't supported anyway. So there should be no loss of compatibility by using the Microsoft scripting library instead of the Dictionary drop in replacement. The Dictionary class was removed.
Ok I think I have fixed the problem. Give it a shot to see if it works now. |
No still not able to import the class, I tried drag and drop and the manual process same with #11 |
Make sure you are fetching and checking out the latest version of the branch from github. I have removed the Dictionary.cls completely. Unless you are now having troubles with the other class? |
Using the VBA-JSON library, the config file is now using JSON. This has simplified the task of serializing the configuration data. No need to worry about escaping anything, parsing complex structure or handling many different styles of whitespace.
While I was doing this I some changes to how the import and export is done but functionally it should be the same.
The new "Module Paths" configuration property gives a mapping from modules to file paths. These file paths may be either relative or absolute. However I have not done any testing of this beyond the default (all files in the same directory).
The addition of more configuration is now a piece of cake. Simply add more properties to the configuration object.
This branch (json) is based on my housecleaning branch which was submitted for a PR in #9 .