When all VBA code is removed, library references are not saved about vba-ide-code-export HOT 13 CLOSED

Alright, I have done some research into the necessary API. Looks like this function will do the trick. Seems easy except for dealing with the config file. Looks like we will need to store the GUID, major and minor values in the config file. I would also like to store the name and description of the reference along side the other values to clarify the GUID for human readers. So that is 3 strings and 2 Long values. How should this be formatted in the configuration file?

I was thinking about changing the config file format to JSON and using the VBA-JSON library. This is a fairly big change, but it does have the advantage that it off-loads all future worry about data serialization to a pre-built solution. In my opinion JSON is not too bad to edit by hand (better than XML at least), but that may be because I have been recently using Javascript. What do you think? Is this overreacting? Is there a simpler solution?

Note: The same creator as VBA-JSON has also created VBA-XML.

from vba-ide-code-export.

The VBA-JSON library is just a VBA code module. I have been doing some more reading and realised that late binding is a much more robust and stable way of linking to external libraries. Sorry for all the fuss but I don't think I'll pursue this for now. Rather, I will try to implement late binding such that setting the library references is not needed.

from vba-ide-code-export.

Top idea @mattpalermo! Go ahead if you want

from vba-ide-code-export.

As long as the potential user can use it as a pure VBA experience [i.e. no need to install any software] then I'm all in. The idea is that this can be used by small teams that may not have admin rights on their machines and need to go cap in hand to admin to get a dependency installed

from vba-ide-code-export.

from vba-ide-code-export.

Update: Late binding doesn't work with the WithEvents keyword (used in the VBACmdHandler class). In this case, early binding is the only option. Additionally it seems that the general consensus is that the GUID of the extensibility library is fairly stable and there shouldn't be a problem with the portability of the reference. So I now see that there may be plenty of cases where early binding is the better option. And I have encountered one of those cases in the VBACmdHandler class. I will resume my effort of implementing the import and export of library references.

from vba-ide-code-export.

Problem solved by #11

from vba-ide-code-export.

Looks like this is still an issue, what was the reasoniong behind this again @mattpalermo

Was it just to have a completely empty project?

from vba-ide-code-export.

Ah yes. My reasoning for this is not clear. Initially there was the problem that when all the modules were removed, the references would be removed by Excel. The user would then have to re-add them manually. So, to fix this, I made it so that references will be automatically added from the configuration file when the import happened. For exporting, I thought it was good idea to remove the references which would be added back when the import happened, therefore mimicking the behavior of the modules.

from vba-ide-code-export.

I see you have an error in this section. Could you show the references section of the configuration file you are using? It appears that Excel refuses to remove MSForms. If that is the case, then perhaps MSForms shouldn't have to be in the configuration file.

from vba-ide-code-export.

from vba-ide-code-export.

I see what is happening now. The solution is to add "MSForms" to the "blacklist" here:

I'll get onto this sometime today.

from vba-ide-code-export.

PR #46 should fix this problem. The PR was pulled into the dev branch. It solved the problem for me and I think it will solve your problem as well. You may have to manually delete the MSForms entry from the configuration file.

from vba-ide-code-export.