Closed A9G-Data-Droid closed 4 years ago
This is part of what inspired me to restructure the entire project around classes that implement the IDbComponent interface to give a consistent structure for working with the various types of components in an Access database. Since the exporting and importing are very closely related, I am incorporating both of these functions in this add-in.
Version 2.0 introduced the GUI and installer, Version 3.0 involved a complete restructuring of the project using classes, and we are getting close to a 3.1 release which will allow the project to build a database from scratch using the files in the source folder. Once we have the bugs worked out of the build process, we should be able to drop the binaries out of version control, and just compile the add-in (and other projects) completely from source code.
I am personally very excited about this potential! It could be a real game-changer in Microsoft Access development, opening the door to a greater level of collaboration between developers while greatly enhancing our ability to use Microsoft Access as a Rapid Application Development platform for front end pieces and integration projects.
You did a lot of work when I wasn't looking. I didn't know we were on version 3 until today.
My build tool works fairly well. I'm afraid that the code bases are very far apart now so it would take some work to implement my import modules. Is this something you are writing right now? Or do you want my help to implement my compiler in to this project?
That would be awesome to have your expertise in working out the final issues with building from source! We actually might be closer than you realize... If you open up the Testing.accdb database, you can see where I have created numerous test for various types of objects. You can export, then build that project right now using the integrated build functionality, and it successfully builds from scratch, including several more types of objects like shared images, saved imports and item property descriptions.
The approach I was taking was to open the test database, run an export using the add-in, then with the database still open, use the button to Build from source. This will back up the current database and completely rebuild it from a blank database using the source files.
Reopen the database to apply all the changes (like the database icon and custom object groups) Then make a copy of the source folder, run the export again on the new database, and use WinMerge to diff the two export folders. This tells us how close we are to completely recreating the database from source.
As you may have already noticed, when the Testing.accdb database opens, it automatically runs the tests to verify various database components to see if they were built correctly. As you find problems in the diff, you can add tests to verify those items programmatically.
Looks like there are a couple of bugs I need to fix to get the import running again, but I should be able to commit those shortly...
Also, don't worry to much about the Print Vars at the moment... I am rewriting that entire process right now, and the current code will be replaced by the new clsDevMode class.
Thanks again for your help on this project!!
I just pushed the fixes up to master so you should be able to build the Testing.accdb database now.
Just for fun, I used the build function to build this add-in file itself, and with a little hand-holding to work through some technical kinks, it does completely build the add-in from source. Once we get the build function to work (one-click) on the Version Control.accda
file, we can then drop the binary out of Git and just work with source code for the add-in. This will simplify development going forward since we will just be merging code changes at the source file level without needing to pass the binary back and forth. Feel free to take a stab at that if you like. 😄
(The main issue I encountered was that it choked while importing a form into the CurrentDB with the same name as the running form (frmVCSMain
), even though it was technically running in the add-in, not the CurrentDB.) We could potentially watch for that name, import it as a different name, then rename it after import.
I ran in to a similar problem. You'll see in my compiler that I am passing an Application object around to all of my import functions. This is because I spin up a new application and do all of my work in a clean space that only contains the new project being built. I don't ever want to confuse access about which project I am working on.
This is what I recommend for the most straight forward approach on import:
Look at my compiler as an example.
Dim newApp As Application
Set newApp = New Access.Application
newApp.NewCurrentDatabase outputFile
The main function is seen here: https://github.com/A9G-Data-Droid/AccessDB-BuildFromSource/blob/master/AccessDB-Compiler.accdb.src/modules/Make.bas
NOTE: I think that opening the new application this way will bypass loading things like the add-in so it won't exist in the new application. If not then we may need to unload the add-in, open a new application and then load the addin back.
I just released version 3.1.5 which builds fully from source! For ongoing development we can focus changes and pull requests for this project on the source code without requiring the binary. (Version 3.1.5+ will be needed to build the add-in from source.)
Wow! That's great news! I will take a look at this as soon as I get the chance.
Once the binary is removed from source control you will have to make a release after each merge in to master. Then attach the binary to the release. This allows us to merge multiple commits to master and then compile a release when they are all done, just like you would with any other software project.
I have been developing and testing a compiler for this purpose: https://github.com/A9G-Data-Droid/AccessDB-BuildFromSource
I am currently using a version of msaccess-vcs-integration that I built from source using my compiler.