Creating a VB6+Python framework

Hi all, it's been a while since I wrote about framework on the Windows desktop. Now, I'll be sharing with you the framework that my friend and I are working on.
The inspiration was Django so we decided to try and pattern our framework in the hopes of achieving something that will simplify and speed up coding and eventually the software development process.

We tried out various approaches like using JSON to create a common data format. Oh by the way, what makes this framework unique is that we also intended it to make use of the Linux environment. Here's the plan:

The front end (the view and controller) would be developed on Windows using VB6. Why VB6? Cause VB.Net already has it's own framework and making another would simply be reinventing the wheel. Plus there are still a lot of developers using VB6 and it would be great to contribute something to this community.
Anyway, going back to the topic, the Linux participation would be utilizing the power of Python. Django was written in Python and we really appreciate how easy data handling was using it. So we thought of delegating this task (the model) to Python on Linux. Of course Python also works on Windows but we wanted to test it accross (Windows<->Linux).


I did mention JSON, and we thought it was a cool idea to use it as a model dictionary or how the data is described (what it contains, their data types, etc). No problem with it under Python.
Okay, comes the test on VB6. Since it's basically a JavaScript (ObjectNotation), then the first thing we need to accomplish is making javascript run under VB6.
Sounds like a really dead-end idea to most of us...yah I know, I got that impression too.

But hey, good thing there is the scripting library of VB6, I was able to evaluate and execute javascripts from within VB6. So now the problem is solved....or is it?

Unfortunately, my joy of having been able to run javascript on VB6 was shortlived. Parsing basic JSON objects and dictionaries was no problem, but the solution failed when we tried parsing the JSON array.
In javascript, the square brackets denote array content but it was returned as a string in VB6.
I thought we made a typo so what I did was create an HTML with javascript.

Hmmm...HTML? Aren't we discussing desktop framework here?

Yes, but I'm no expert in Java and I only know a little of javascript so I needed to test the JSON array using javascript as my only option. Okay, it turned out that the JSON array was correct in format, I was able to prove it using javascript on an HTML page.
So I deduced the problem was how VB6 scripting handles the JSON code. I hope I'm wrong but back when I was testing it, I can't make VB6 scripting understand the array notation.

Anyway, out of frustration we turned our attention to another approach, another data holder.
We thought first of XML, then we thought it would be more complicated compared to JSON and YAML. We then looked at Dictionary of VB6.
Okay it worked. But there are times when you don't need a "key" for your list so we tested the Collection data type. Now, it was very easy porting VB6 dictionary to Python, but it was a dead-end using Collection.
In VB6 no problem, but in order for Python to use it, it has to know the Object.ClassID.
For dictionary it would be "Scripting.Dictionary", but in Collection not that possible.
We used VB6's object viewer to find out where this collection resides in.
So we saw "VBA.Collection". Nice, we found it!
Python was having problems using it. So I tested it under VB6, simulating how Python would call it.

So instead of using:

Set ThisCol = new Collection

I tested it using

Set ThisCol = CreateObject("VBA.Collection")

And it didn't work!!!! Darn!!!
I had to Google a solution but there's none. I searched several forums and most of them also had the same problem and none has found a solution. Quite frustrating don't you think?

I'm using Windows, VB6, and then tried to use another Microsoft Product (the Collection), and it won't work. This is one of the reasons other developers are parting away from MS, product incompatibilities (when they are all under on parent company).
But I'm not here to rant about my frustrations, so I'll get back to my topic.

So we're stuck. No. We won't just give up on this one. We'll find a way to make something work, even if we reinvent some wheels.
A solution we saw on the internet was to create a wrapper for the collection so it can be used on Python (or any other language). It would work, but for me it was like a dirty solution.
I wasn't content with having used it just for the sake of making it work.

If we were to create such a wrapper then we make a good one to start with.
After hours of drawing on paper and several combinations of data structure, simulations and questions on how the new idea would work, we found an acceptable solution.

Yes we did, we we're able to use successfully and have progressed faster compared when we first approached this idea.

Next time, I'll discuss some of the things we did and maybe some progress we made. Thanks for viewing! See you next time.