VB6

Cleaning up legacy mess by functional composition

Submitted by Vidar on

In my experience Vb6 is used mostly as a procedural language, with objects used without the author knowing it's actual objects (like the auto instantiating of forms.) In a lot of cases you'll inherit (no sane person would start a new greenfield Vb6 project, right?) a collection of subs and functions that are mostly global.
You'll find that after a while common functionality got called from several different places, and the original author found that something needed to be done slightly different for the latest use case.

Categories: 

Bending Vb6 in the functional direction

Submitted by Vidar on

Update:Code available and developed further on GitHub

A substantial amount of my day to day work is spent maintaining a legacy VB6 codebase.
Unfortunately I also create new features for our users on slightly less ancient platforms.

This has the unwanted side effect that back in the land of VB6 i miss some of the language features from the newer platforms.

The feature I miss the most is probably an efficient way of working with collections.
In C# there's linq, in most functional languages there are som variant of map/reduce functionality.

In VB6 you have loops.

Categories: 

Adventures into VB6 "reflection" and error handling

Submitted by Vidar on

I've started working on a testing framework for VB6.
To be more specific, a testing framework that it should be possible to integrate into even the most hairy of legacy applications.
I tried reading up on existing tools, but there where not many, and the documentation left much to be desired. But the one thing I found was that they all required ActiveX dll's or exe files.
If your legacy application is not designed using this technology, for example if it's just a standard vb6 executable, your pretty much left out in the dark.

Categories: 

Registration Free COM Interop Deployment

Submitted by Vidar on

Today I ran two rounds of deployment of to our production servers. This led me to start pondering a blog post on the strategy we've chosen to make this as painless as possible.

Our operational requirements demands that deployment of new versions is done continuously, without downtime, while our users are actively using the software.
As long as the deployment environment is controlled, .net applications can be xcopied directly, with no extra steps. But our application is a mix of .net and legacy VB6 components. This mix would lead many to believe that registration in the registry is unavoidable, which could lead to DLL hell.

But there is a solution:

Categories: 

Subscribe to RSS - VB6