RC6 - New encrypt option for Sqlite DB: SqlCipher

[Niya]

Well, as long as the true COM-tools have no problem with referencing it (VB6 and VBA as well as TwinBasic and VBScript),
I'm not really interested in, what the .NET-Typelib-parser throws out as warnings.

Oh I'm challenging this for the mere fact that none of us on the .Net side have never had any problems using COM libraries in .Net. The most common use case you see is Office Interop(Word, Excel etc). .Net has never had a problems referencing these. I've personally used Excel interop and the Media player with no problem as far as referencing and instantiating objects go. I've also used the UPNP library successfully at one time which allows you to automatically forward internet traffic from your router to your application. I even showed in this very thread that ADO also works with zero problems despite the fact that it is completely unneeded in .Net.

Look, I get it. vbRichClient was made for VB6 users and that's fine. But what I absolutely will not co-sign is this fantasy of "true COM tools". This phrase is design to bamboozle innocent folks who don't know any better. COM at the end of the day is a binary standard. It is not a VB6 only thing. Folks have been using COM in C++ to access DirectX since the dawn of time. If a binary a implements a COM server, it should be consumable by any COM client. If any COM client cannot do that, as far as I'm concerned, it's broken. In this regard, it is vbRichClient that is not a "true COM tool". It's some kind of Frankenstein library that looks like a COM binary. No one could deny that you are a COM expert but Microsoft created the COM specification and if one of their tools is saying the type library for your tool is broken, who am I to question that. You are using your own standards, not the ones that Microsoft recommends.

I'm not saying you have to do anything about it. If you are satisfied enough that it works with VB6, hey that's fine. But I wouldn't dare say it's a proper COM tool if it commits so many COM violations that it breaks with certain COM clients.

This indicates, that the .NET typelib-parser goes "one level too deep" in its "COM-reference-imports" -
(trying to resolve also implemented interfaces, instead of being satisfied with the Default-interface of a Class) -
and besides, I'm not the Author of 'VB6.olb', Microsoft is...

I guess you know better than the people who invented COM about what it should and shouldn't be doing....right?

Well, SQLite-wise there's a lot more missing, as e.g.:
- Zip-support
- CSV-support
- superfast JSON-serialization of queried Resultsets
- JET-Sql-Function-support as e.g.: Left$, Mid$, Right$, DateDiff, DatePart

Graphics-wise:
- SVG Read/Write support
- Alpha-Channel-JPGs
- ControlPoints-support
- ...plus a lot more convenience-stuff, not found in .NET

At least proper JSON-support was recently included in .NET (though long after the RC-lib shipped with it).

There is far too much in the world for any single library to cover every thing there is. Even massive frameworks like .Net and the Java Platform won't cover all things. There were bound to be things that independent library authors like yourself would cover that have been ignored by the titans in the industry. Hell, even I have personal libraries that covers things that they missed.

What is important is that these Frameworks at least cover the more common cases. I don't think large populations of developers are going to lose their minds over Zip support in SQLite or transparent Jpegs. Also, who the hell even uses transparent Jpegs? Like 10 people?

At least proper JSON-support was recently included in .NET (though long after the RC-lib shipped with it).

This isn't saying anything. vbRichClient is still a 3rd party library and there were 3rd party libraries in the .Net ecosystem that covered JSON long before it became standard in the framework. Just like someone has to search for and install vbRichClient, they would have to search for and install a JSON library. I'd even go as far as saying .Net still had the advantage here because of things like Nuget that makes installing 3rd party libraries effortless as opposed to all the song and dance it requires to deploy vbRichClient.