Kenneth Ismert
kismert at gmail.com
Thu Feb 11 14:28:04 CST 2010
> > Shamil: > > What I plan to do is a "lightweight" version of "EatBloat" within > > Access Developer Assistant add-in ... And it will need > > .NET Framework 3.0/3.5 installed on target system. > > > Ken: > Just so I'm clear, are you going to automate the EatBloat function using > only .NET, or will you be calling the existing VBA code from .NET? > > Shamil: > Just using .NET, Ken. > > A COM-Add-In developed using C# and "Add-In Express for Office and .NET" > ... > That sounds like a good idea. I bumped into the limitations of VBA when I developed an Access Rebuild application which rebuilt Forms and Reports control-by-control, property-by-property. The motivation for this was a monster frontend (almost 40Mb in mde format) with persistent corruption problems that not even SaveAsText/LoadFromText could fix. The program, while time-consuming to run, was remarkably effective in giving the frontend a 'new lease on life'. Several huge forms, with almost a decade of development history, could now be edited without aggressive bloat. It also reset the lifetime control count, which allowed extending forms which had long since run into this limit. I often thought that redoing the code in C# or VB.NET would have allowed a lot of extra flexibility in handling the coding issues that arose when tackling this problem. -Ken