[VBA - Multiple Platforms] VBA Project Stopped Working - Possibly Due to Windows Update

Hi Chuck,

Have you checked that any references are all correctly pathed (i.e. VBA IDE Tools\References)?

Hi Chuck,

caddcop said:

my theory that a Windows Update may have broken these tools

Despite of many people will disagree probably, in my opinion Windows updates break anything in MicroStation really rarely.

But what may happen more often is that an update "makes visible", what is broken already (or not implemented as it should be), but still works ... until Windows update fixes security holes and clean some old garbage from system ;-)

caddcop said:

We have a number of VBA Projects

My experience with VBA is so bad that I never use it (and do not recommend as well) for anything more than simple macros, where only standard libraries are used (VBA engine itself, MicroStation API and VBA forms). The problem is that it's simple to break registered libraries, or to replace them with incompatible version.

caddcop said:

The tools perform some of their functions, but others fail.

I think in such case MicroStation / MicroStation VBA is not broken, because in such situation (e.g. when VBA engine in unregistered or reference library is removed), VBA is not loaded at all and another error message is displayed.

caddcop said:

Has anyone seen a similar occurrence on their systems and have any suggestions.

It's hard to guess when no details about VBA code structure is known. Especially about further dependencies and whether VBA code references another libraries or communicates with another systems, database etc.

caddcop said:

One issue that I notice that instead of the project name, the first error lists APC.ApcHost.6. I do not understand what that is and why.

It does not look like anything produced usually by VBA. Even when I searched for error value and the message itself, all findings were from another languages. And VBA itself does not know "collection" object.

caddcop said:

we do not have a contract vehicle to get the tool fixed if it requires recompiling and/or code modifications.

It sounds like a big threat, especially when one from core software development rules tells that that to develop application represents 20% of cost (and time, effort etc.), whereas the rest 80% is the application maintenance and operation cost.

With regards,

  Jan

They all appear to be. None show as "Missing". I cannot read all of the paths as the dialog box is too narrow for some. So I may need to do some detective work. A comparison between my home PC and Office PC look to be identical. The tool is password protected, so its unlikely anyone accidentally modified something.

We are going to reinstall the programs on a test PC and see if that fixes it. Searching Google for APC.ApcHost.6 has not really been fruitful either. Most hits seem to have code that specifically call out some APC property or method. I cannot find any evidence that there is similar code in this project.

It has 14 forms, 15 modules and 32 class modules! 

Our library of tools automate a number of very tedious processes and helps us produce consistent drawings. The problem comes when either something stops working or a new version requires code revisions.

I am stuck between a rock and a hard place - lose the productivity these tools offer, or find a way to hire the guy who wrote them.

I'm being asked to bring someone new on board to learn the ropes because relying on the original developer is not a place we want to be. But to do this in the middle of our Migration to the CONNECT platform is far from ideal as well.

And once the "new guy" learns all this we'll be nearly where we started, except now we'd have two possible programmes to call on instead of only one.

caddcop said:

They all appear to be. None show as "Missing".

When there is nothing displayed as red, everything is fine.

caddcop said:

Searching Google for APC.ApcHost.6 has not really been fruitful either.

I did some more search also and the situation is bit more clear now:

APC (Application Programmability Component) is the interface Microsoft provides 3rd party vendors (like Bentley) to interface with the Microsoft VBA engine to provide event handling and extensions to the "common" Microsoft COM VBA APIs.

Based on this information, I recommend to to try to start MicroStation (or other product) using Administrator rights (e.g. to open command prompt "As administrator") in this way:

ustation.exe /RegServer

... but it "refresh" the connection between MicroStation and VBA engine only, so when the problem is in corrupted VBA engine itself, it probably does not help.

caddcop said:

We are going to reinstall the programs on a test PC and see if that fixes it.

If the problem is in VBA engine issue, to reinstall MicroStation Prerequisite pack should be enough.

caddcop said:

It has 14 forms, 15 modules and 32 class modules! 

That is not small for VBA (because VBA has no tool for code management), but that's tiny application in context of general software development.

caddcop said:

The problem comes when either something stops working or a new version requires code revisions.

I understand. And it's where VBA always fails, typically in some disastrous way, because VBA does not allow to use any code management tool (like Git), so it's impossible to compare version, so quick testing etc.

caddcop said:

But to do this in the middle of our Migration to the CONNECT platform is far from ideal as well.

Yes, the migration to CONNECT Edition is a big challenge.

My experience is (fortunately) I was able to negotiate with all customers to migrate their VBA macros to C#. In general, to swap from VBA to C# is simple. Much bigger problem (and often it's what requires 99% of time) is to understand dirty old spaghetti VBA code, written by non-programmers, to ensure new code will offer the same functionality .... and the code itself is often the only source of information, because no formal documentation exists ;-)

Regards,

  Jan

caddcop said:

It has 14 forms, 15 modules and 32 class modules!

Jan Šlegr said:

My experience with VBA is so bad that I never use it (and do not recommend as well) for anything more than simple macros

Jan's comment may point to a solution.  I agree with him: on the couple of occasions when I have been obliged to work with a large VBA project the ability of VBA to self-destruct is astonishing. 

caddcop said:

a Windows Update may have broken these tools

VBA is perfectly able to break itself without the help of a Windows update.

Deflate your VBA Projects

Microsoft itself has admitted that VBA projects are 'full of air'.  I have observed anomalies when a VBA project becomes confused about its identity.  Rebuild your projects to compress and reorganize them.

You need to be rigorous in creating a file structure for the following steps, so files end up in the right place...

1. Backup: Make a copy of all your VBA projects and put them somewhere safe
2. For each of your VBA projects
   • Create a folder to contain the temporary files
   • Export each UserForm, Class and Module to a text file
3. Create a new set of VBA projects with names similar to, but distinct from, your existing projects
4. For of those new, empty, VBA projects
   • Import each saved UserForm, Class and Module from the text files

What the above, admittedly tedious, process does is to enable VBA to recompile each project's contents.  It eliminates spurious problems, such as the one you report, and leaves you with a clean sheet.

Hi caddcop,

caddcop said:

Recently, our users reported that these were failing to work as before. The tools perform some of their functions, but others fail. To test my theory that a Windows Update may have broken these tools

Open Windows Reliability History feature (Win + "Reli") and see if you can find evidence (by day or day before the event occurred) on both a good and bad machine if needed for comparing. This is a quick way to see most noticed and unnoticed software patches and upgrades along with being able to click on any Details present to find more detailed logs, crash/exception data, etc.

HTH,
Bob

Hi caddcop,

caddcop said:

They all appear to be. None show as "Missing". I cannot read all of the paths as the dialog box is too narrow for some. So I may need to do some detective work. A comparison between my home PC and Office PC look to be identical.

If you are having issues seeing a list of MicroStation VBA Projects (.MVBA) and respective Reference Details for each, feel free to use the VBEProjectsList() subroutine I posted. 

Alternately, if you are permitted to install free 3rd party utilities; one I find invaluable is Search Everything (Download by VoidTools).  This tool permits you to search across a large numbers of all files on your system (e.g. I have over 8M files) producing immediate results for partial and wildcard pattern file/folder names. From those results you can sort by date/time (most recent), open path (an explorer window), Run As Admin (for .exe's) conveniently with fewer steps to perform.

HTH,
Bob

Unfortunately, many of these tools are not used daily but only at certain milestone or as needed. So it is very difficult to nail down when they topped functioning.

I continue to hope someone has determined a fix that they applied and share that information.

If anything, being able to report on the References of each Project might help as I can than do a file by file comparison. I tried adding code to the VBAProject tool, but I am struggling with the syntax I can use. During a step into, I can look at the locals nd see them, but it would be more useful if I could get it to add them to the list it generates,

At least the references are on the users PC in a standard location. Since we work in ProjectWise, the list of projects only shows files in the PW working directory.

caddcop said:

I continue to hope someone has determined a fix that

Did you try my suggestion to deflate your VBA projects?