Support subdirectories

[BaronBodissey]

Hi chelh,

Thx for this wonderfull tool. I did the same in the lame way using automation :-( . You win by KO ;-) .

What I think would be usefull for everyone is to support subdirectories in the extract/publish directory. That is to say, that in our office project we have tens of modules classes and forms. So It would be nice to kinda sort them in the subdirectories Modules, Classes, Forms (or other as any user would want).

So when extracting/publishing VBASync would scan the subdirectories of the project directory and try to find the equivalent file to be extracted/published.

For instance, at the first extraction VBASync would extract everything in the root directory. So then the user will reorganize the files as he wants. And then VBASync would respect the arrangement done by the user.

Thx again.

[chelh]

I've thought about this feature before, but from a different angle. Rubberduck supports folders via annotations like '@Folder Directory.Subdirectory. If I make VBA Sync respect those annotations, it will allow you to specify subdirectories, but in code, not by moving files around yourself. So it's not exactly what you're looking for, but it may be better in the long run, especially for people who are using VBA Sync and Rubberduck at the same time. Thoughts?

[BaronBodissey]

I didn't knew this feature of Rubberduck. I'll have a look.

Nonetheless, although I think of using Rubberduck for some times, we still don't. In fact it's not so easy to adopt Rubberduck as you have to install it on every developper's computer. You have to make the effort to convince your colleagues to adopt it also. My colleagues are quite open-minded, but still, habit changing is always challenging for one's mind.

VBASync have the advantage over Rubberduck to be a "back-end" process. I can use VBASync in our process without challenging the team habits.

So it still would be nice to have the subdirectories scan, even if by default VBASync would uses @Folder. That way you don't force users to adopt Rubberduck, but still you nicely propose them to adopt it...

[chelh]

Oh no, I'm not suggesting that you just switch to Rubberduck at all 👎 I'm just proposing an alternate implementation, where you have to use the '@Folder Directory.Subdirectory annotation to tell VBASync where the file goes, rather than having VBASync monitor the repository for file movements itself.

Let's call mine the “explicit” method, and yours the “implicit” method.

Something that occurs to me: What if a user has bad version-control (cough TFS), and makes expedients like …\Repo\Backups\ and …\Repo\Experimental\? They would have a reasonable expectation that VBASync won't touch those. Yet under the implicit method, VBASync might delete or overwrite files there. So it seems to me that the explicit method is safer.

[BaronBodissey]

Well...I think your idea is neat....but still I'd prefer having the subdirectories scanning mecanism. I do have several arguments for it.

1. the @Folder would be understood only by VBASync

• so it ties us to VBASync (and I don't like being tied, it's an "architectural smell")

• although @Folder is kinda clear in it's meaning, we cannot be sure of it is really meant to be and how it works. I must say that in general I avoid [Attribute] at all costs for this same reason...and @Folder is kinda attributee.

2. it's more complicated to add something in the code than to handle the file location. Otherly said, the file location is self taught as for the @Folder attribute I would have to provoque a meeting with my team, explain the attribute and convince them to use it. Indeed for the file location...well they already manage files location and organization.

Thx

[chelh]

Hm, okay then. I'll start work on doing it the implicit way, but it'll be turned off by default to prevent the problem I discussed earlier. You'll find the new checkbox under session settings.

[chelh]

Okay, this took a while, but I think I have all scenarios covered. Please give this release candidate a spin…

Portable VBA Sync Tool 2.2.0.zip

@hectorticoli Could you please translate the new string in the settings window? There also may still be some untranslated strings from the hook implementation as well.

[chelh]

New release candidate – double-clicking a change that’s in a subdirectory should work now:

Portable VBA Sync Tool 2.2.0.zip

[hectorticoli]

Hi chelh,
Could you please give me more details about a few texts?

• "Search repository subdirectories", with "repository, do you mean "VBA project folder"? repository is a versioning control system term, so I suspect the word to be inappropriate. If you don't mean "VBA project folder", could you elaborate so that I can find an appropriate translation?
• "Add new document modules when publishing (expert option)": this option is about (for example) the case of importing a sheet related module to an Excel file that doesn't contain the sheet, right?
• "Delete document modules when publishing (expert option)": Could you describe a use case for this option (and/or the associated issue number)?

I've just translated the most recent file "out of context", so the translations might or might not be appropriate. I'll fix an upload the file as soon as I'll get your feedback about above points.

Thanks!

[chelh]

“Search repository subdirectories”, with “repository”, do you mean “VBA project folder”?

Yes. I've just changed the English text to “Search subdirectories of VBA project folder” to be more clear.

“Add new document modules when publishing (expert option)”: this option is about (for example) the case of importing a sheet related module to an Excel file that doesn't contain the sheet, right?

Yes. I've just changed the English text to “Allow adding new document modules when publishing (expert option)”, to be more clear.

“Delete document modules when publishing (expert option)”: Could you describe a use case for this option (and/or the associated issue number)?

This came up in the last few comments to #30. Previously if you deleted a document module in the VBA project folder (like ThisDocument.cls for Word projects) and then published to an Office file where that document module still existed, VBA Sync would outright delete the document module from the project. In Word at least, this could corrupt the VBA project. So the new default behavior is to just remove the code from the module, leaving behind a placeholder so that the VBA project isn’t corrupted. The “Delete document modules when publishing (expert option)” option re-enables the old (dangerous) behavior.

Similarly, I've just changed the English text to “Allow deleting document modules when publishing (expert option)”.

[BaronBodissey]

Hey chelh,

Sorry I've switched project for now. And as holidays are coming, I've to finish mandatory projects first...Think I'll not been able to test until september.

Sorry to read that you want to retire from the project. Hope it's not my fault ;-).

See ya.

[hectorticoli]

Hi chelh,

It took longer than expected, but this time I was able to compile and test the version with the translation. So here is the updated french resource file. Enjoy!
VBASyncResources.fr.resx.txt