Quoted Troberg, platform independant ActiveX is not realistically possible. I'm well aware of that. It would be a huge plus, as VB without ActiveX libraries is a pretty empty box, but I also realize that good does not equal possible. To be quite honest, I don't know how it could be done. The closestway I can think of would be some kind of dynarec, ie recompiling it at run time. The recompiling is fairly straightforward, but chances are that the ActiveX library does a lot of platform dependent s...

Quoted I'm working on it. Which parts are not compatible with your project? To be quite honest, I've only made preliminary tests yet, so I wouldn't go too far in analyzing the results. Some things that didn't work without fixing: * API calls * Database access * User controls (even when compiled within the same exe) * Compiling as a screen sacer. OK, not very common use, but it was one of the cases I tried. There were some smaller issues as well, I think I found some missing properties, but I do...

I like the concept of Jabaco, I like it a lot. It's exactly the right way of giving backwards compatibility and platform independence. However, I have some minor comments. Please, don't take them as criticism, just some random thoughts about how to best handle such a concept. * For it to be practical when you have an established code base, it needs to be almost 100% compatible with VB. If you need to correct something every tenth line, or even every hundredth line, it's usually too much work and...