Quote Originally Posted by dilettante View Post
I might be able to help a little, but right now I have a contract that is eating up a lot of my time. I'll look for the new thread and try to contribute where I can.
Ok - just in case... this new DirectShow-wrapper-stuff will not have a RichClient-dependency... ;-)

Quote Originally Posted by dilettante View Post
I haven't followed how vbRichClient has progressed but I'm not sure a single gigantic DLL with a mixed bag of things in it meets everyone's needs. Perhaps I haven't given the idea enough thought but I prefer things to be more granular.
As for "giving the idea enough thought" - please do ...
- when you write "single gigantic DLL with a mixed bag of things" - then think: "VB-Runtime-alternative"
(-> msvbvm60.dll is pretty much the same "mixed bag", containing beside the "compiler-runtime-functions" also
- a Form- and a UserControl-engine with dynamic-add/remove,
- a GDI-based drawing-engine supported on different "Canvases",
- a set of Controls, a Collection and a few other classes I've perhaps forgot).

The RichClient-development aims at replacing the msvbvm60.dll in the long-run completely.
Because of that it is based on platform-independent libs already (in its two most "weighty" parts; the DB-engine and the Rendering- and Control-engine).

As for Deployment-size (in modern LZMA-format, 7zip-archived):
VBRuntime: msvbvm60.7z = 519KByte
RichClient: RC5BaseDlls.7z = 1634KByte - so roughly 1MB more "to ship or to download" (which is still OK these days for the "bunch of additional class-functionality")

Quote Originally Posted by dilettante View Post
I have a hard time "selling" the idea of projects dependent on large 3rd party libraries. My clients have been bitten badly before by such things.
You mean "large 3rd party libs" as in e.g.: ... 'ADO' for example? ;-)

Just joking - but I think you see where I'm getting at ...
I mean, there *were* some problems with ADO-typelibs, caused by "the vendor" ...
and wellknown fixes for that in the meantime too - sure - but then... same thing recently with the CommonCtls...

Not sure what could go wrong in case of a RichClient-dependency in this regard ... what you (or your customers) should fear?
MS would need to break COM completely - to prevent the instantiation of COM-classes from the RichClient - but in this case no VBClassic-App would work anymore.
I'm the last person who has an interest in "breaking VBClassic-Apps" - and a bit of trust with regards to:
"Stuff from Schmidt" should be there in the VBClassic-community I hope (maybe not yet in this forum here, but I'm working to change that <g>)...

But before getting more Off-Topic - maybe we should continue per Mail?

It's just - there's a lot of still enthusiastic and young developers here in the Forum (to my surprise, being a late-comer to the party here).
Young guns, who have loads more "coding-power-per-day" compared to us middle-aged or "already somewhat older" devs who have to "make good with experience".

I'd like when more experienced VBClassic-devs would join the efforts to come up with a new IDE and a new Compiler
(sharing in the help-efforts of "channelizing and directing the enthusiasm of the younger devs" a bit).

So, yeah - I'd like when you could throw your weight into the idea as well - and as for "daily work" -
I'm moving slowly with all that too (as my spare-time allows) - but every year there's more groundwork done.
As said, a mail would be nice - maybe I'm able to convince you finally... :-)

Olaf