how much harder is Windows C API than C#/.NET

[Michael C]

That said, you listed three APIs that do not relate to the target market
for VB6,

That is *highly* debatable. Questions about directshow, cd burning and wia
are quite common in the newsgroups. Third party solutions or free code for
any of these are also very common.

including the OP. As for "shell functions", if you mean Win32 calls VB6
can do it without issue.

No i don't mean the win32 api, I'm talking about all the shell com objects.
Take IShellFolder as an example.

I have worked with VB4-6 for nearly a decade, I have never seen a "*huge*
number of interfaces" inaccessible to VB4-6.

Just because you haven't seen them doesn't mean they don't exist. There are
literally thousands of com interfaces implemented by various windows
functionality that vb6 cannot use (DirectShow on it's own has 500 or so and
it's only 1 part of DirectX). I never realised how many there were until I
started implementing them in C#.

Rather, I am aware of a *huge* number of interfaces that are required to
be implemented in order to have properly implemented ActiveX control, as
opposed to just an IUnknown-exposed COM object, and as such I have seen
several interfaces that were inaccessible to VB4-6 but were later on
cleaned up to Microsoft ActiveX conformance standards. Much of the DirectX
API was among them.

Generally when MS do this it is a fairly cut down version. The WIA component
was pretty good but only worked on winxp sp1. The directshow component was
woeful.

I'm not sure what you're talking about. You can use polymorphic interfaces
in VB6 and advise / unadvise the interface to a callback function via COM.

Take the ISampleGrabberCB interface as an example. It works fairly simply by
calling a method in your class every time a frame is received and passes a
pointer to the bitmap data. You can't implement this callback in vb6 because
it can't implement a pure IUknown interface.

You can also use this method to create event sinks with COM objects that
implement IConnectionPoint. I think we discussed homework...?

The other thing that is *really* sucky about vb6s implementation of com is
the 'weight' of each object. You can't create too many objects because each
object takes too much memory and takes too long to create and destroy.
10,000 objects is not really usuable. That might sound like a lot but it's
only a 100x100 grid.

Michael

 

[Jon Davis]

That is definately a matter of opinion.


That's a big ask, no that is a *HUGE* ask.

Right. Kind of like the whole notion of refusing to parse sloppy
non-conformant XML is a *HUGE* ask...

I think you're spoiled by sloppiness. C, C++, Delphi, et al, are good at
enabling sloppy people to stay sloppy by implementing the bare minimums.

That's not building the solution in vb6, that's building it in C++.

No, it's C++ to fix the mistakes Microsoft made in DirectShow so that they
can go back to RAD development in Visual Basic.

Jon

 

[Jon Davis]

Michael, I think you're taking some really niche programming principles and
associating their inapplicability to the wrong programming model. The OP'er
had a simple GUI app with a dashboard and some menus and some processes. The
GUI portion does not likely need DirectShow. It does not likely need
ISampleGrabberCB. And a 100x100 grid is 1,000, which is a cakewalk for VB6.
Actually, VB6 can scale to several hundred thousand objects. But it doesn't
sound like the OP needs it.

This is a stupid debate, we're comparing apples and oranges here. COM was
*NOT* at issue here, but VB6 does support COM (to a very large extent) and
where VB6 falls short Win32 function pointers and, yes, COM-exposed
C/C++/Delphi components can fill in the gaps. But VB6 has a lot of merits.
Yes, it does trade some power for its ease of use, but that doesn't make it
a toy. It's a RAD tool, still used by many businesses and enterprises.

I think you need to grow up and quit trying to show off your ego.

Jon

 

[Ben Voigt]

You'd think so Unless a component is specifically written with vb6 in
mind there's a very good chance it won't work. Does vb6 work with plain
IUknown interfaces at all? You certainly can't use all the DirectShow
interfaces for example in vb6.

Having not done DirectShow, I still think that VB6 worked with IUnknown just
fine. I did write a bunch of COM objects in C++ for consumption in VB6.
Even IDispatch wasn't that difficult, there was a default implementation for
every function if you loaded the typelib. But IDispatch was a convenience,
not a requirement.

Problem was, the VB6 built-in class framework had a horrible inheritance
model, so programmers got used to late binding for just about everything.
Example: Form and PictureBox didn't have any common ancestor I don't think,
so the Parent property of every control had to return "Object" (=
IDispatch). IUnknown can't do late binding. Not in any language.
IDispatch is required for that. And, most programmers didn't go to the
trouble of declaring every variable with the exact type, because you could
just pass the type id as a string to CreateObject and go.... at least with
automation compatible objects (dispinterface or dual). With IUnknown
objects, you needed to import the type library, because that's the only
information the compiler had.

Also had a tendency to limit you to a particular version of the library in a
way that COM shouldn't have... but that was VB calling coclasses types and
hiding the interfaces. But you could still use the interfaces even though
they didn't show up in the Object Browser (OLEView is great). It's not
obvious how to write early-bound VB code for polymorphic COM objects... but
it is possible.

 

[Michael C]

Right. Kind of like the whole notion of refusing to parse sloppy
non-conformant XML is a *HUGE* ask...

Nothing like it.

I think you're spoiled by sloppiness. C, C++, Delphi, et al, are good at
enabling sloppy people to stay sloppy by implementing the bare minimums.

I don't think you really understand just how much work is involved in making
these components vb6 freindly.

No, it's C++ to fix the mistakes Microsoft made in DirectShow so that they
can go back to RAD development in Visual Basic.

No, it's developing in C++. This does NOT mean vb6 can access directshow,
C++ is doing it.

 

[Michael C]

Michael, I think you're taking some really niche programming principles
and associating their inapplicability to the wrong programming model.

Niche programming!?!?! You've gotta be kidding, just doing something like
drag/drop requires access to implementing all sorts of interfaces if done
properly (if you want the source to be created when you drop for example).
Accessing that thumbs.db file again requires all sorts of interfaces.

The OP'er had a simple GUI app with a dashboard and some menus and some
processes.

I'm talking more generally.

The GUI portion does not likely need DirectShow.

Likely it doesn't.

And a 100x100 grid is 1,000, which is a cakewalk for VB6.

Really? I was presuming I was talking to someone who knew how to add

Actually, VB6 can scale to several hundred thousand objects. But it
doesn't sound like the OP needs it.

It can but it will be very slow. 100,000 objects is 10meg+ before the
objects store anything (each object takes approx 100 bytes). Creating and
destroying those objects will be slow.

This is a stupid debate, we're comparing apples and oranges here. COM was
*NOT* at issue here, but VB6 does support COM (to a very large extent) and
where VB6 falls short Win32 function pointers and, yes, COM-exposed
C/C++/Delphi components can fill in the gaps.

Sure it can but that is NOT accessing these components in vb6. It doesn't
somehow mean vb6 isn't limited.

But VB6 has a lot of merits.

It sure does.

Yes, it does trade some power for its ease of use, but that doesn't make
it a toy. It's a RAD tool, still used by many businesses and enterprises.

All I said was vb6 was very limited in it's support for com. I think you
just don't realise how big a limitation this is because you haven't
progressed beyond simple database apps. Netmeeting has 21 interfaces, all
inaccessible to vb6, the shell has 120, direct show approx 500, all
inaccessible to vb6. VB6 only supports a very limited set of COM interfaces
that need to be specifically designed for it.

I think you need to grow up and quit trying to show off your ego.

It's funny *you* should say that. The fact is I am right on this issue and
no amount of pedalling on your part is going to change that. VB6 does
support a very limited set of com components. Just because you are unaware
of these components does not mean they do not exist. I'm not sure how else
to explain it to you.

Michael

 

[Jon Davis]

Drag-and-drop is natively supported in VB6. I haven't met anyone who cares
about thumbs.db.

I'm talking more generally.

No, you're spewing lame specific examples of where VB6 fell short.
*Generally* VB6 has a very broad reach for big projects such as the OP.
*Specifically*, there are indeed a few cases where VB6 will not suffice on
its own.

All I said was vb6 was very limited in it's support for com.

No, it isn't "all you said". You've whined on and on about DirectShow
support and now thumbs.db. You've paralyzed the productivity of the OP's
quest for answers by making outlandish claims about how utterly shameful one
suggestion ("consider VB6 as an alternative to your project") was.

For the record, I think most people would be foolish to implement a project
these days in VB6, but not for technical nor political reasons but only
because it is no longer supported by its vendor.

You see, instead of actually contribute and forward my own ideas, I tend
to bully, jump on others and ask silly questions, for my own amusement.
Stan and Kyle would call me Cartman, but on Usenet it is simply called
trolling.

For everyone's sake, I will plonk to bring this to an end.

Jon

 

[Michael C]

No, you're spewing lame specific examples of where VB6 fell short.

Not really sure what you wanted me to do, you claimed there was little in
the way of com objects that vb6 does support. What am I supossed to do?

*Generally* VB6 has a very broad reach for big projects such as the OP.
*Specifically*, there are indeed a few cases where VB6 will not suffice on
its own.

This is what you keep saying simply because *you* don't know how large this
area is. As far as com goes these cases are *huge*. Most of the
functionality in windows implemented in the last however many years (since
2000?) is mostly com and all inaccessible to THE supposed com language. I
was having a look at GDI plus today and was suprised it was all plain apis,
but wait! I have to pass an IStream in to to load a bitmap.

No, it isn't "all you said". You've whined on and on about DirectShow
support and now thumbs.db.

Both examples of com objects that vb6 doesn't support.

You've paralyzed the productivity of the OP's quest for answers by making
outlandish claims about how utterly shameful one suggestion ("consider VB6
as an alternative to your project") was.

You're the one who couldn't leave it at that. The suggestion was pretty
stupid and should be pointed out. Many people take the advice they read in
these groups.

For the record, I think most people would be foolish to implement a
project these days in VB6, but not for technical nor political reasons but
only because it is no longer supported by its vendor.

There's big technical reasons why VB shouldn't be used for new projects.
Mainly it's support for large projects and even small teams.

For everyone's sake, I will plonk to bring this to an end.

That's as close as you get in a newsgroup to someone admitting they were
wrong

Michael

 

[gerry]

....

Really? I was presuming I was talking to someone who knew how to add

not sure about addition but his multiplications is definitely supect.

100,000 objects is 10meg+ before the objects store anything (each object

takes approx 100 bytes).

and it seems yours isn't much better.

getting back to basics :

100x100 = 10,000
10,000x100 = 1,000,000 = 1Mb

sorry , i couldn't resist ;-)

 

[Michael C]

not sure about addition but his multiplications is definitely supect.

takes approx 100 bytes).

and it seems yours isn't much better.

getting back to basics :

100x100 = 10,000
10,000x100 = 1,000,000 = 1Mb

sorry , i couldn't resist ;-)

Actually it you who is wrong Check again.

Michael

 

[David Jones]

Actually it you who is wrong Check again.

For those who can't see how he is wrong (which was me for a while
there!), it was in the fact that Michael C never said that 100x100
is 100,000. The two numbers were not only in separate paragraphs,
but were talking about separate subjects. The 100,000 was a response
to "Actually, VB6 can scale to several hundred thousand objects",
in which case the fact that 100x100 != 100,000 is kinda irrelevant.

It helps to read before you snip.

David

 

[Rastko Soskic]

I apologize for not reading all of the replies,
but I need to ask if anyone mentioned BCB (Borland C++ Builder)
I think BCB is excellent intermediary between RAD capabilities of .NET
and fast, native Win API app. Furthermore, you shouldn't have so much
trouble (but you'll certainly do have trouble ) using existing C
libraries.

Once more, I apologize if anyone mentioned BCB already, but I couldn't
read so many replies