Re: Walkthrough Instruction Error

Tech-Archive recommends: Fix windows errors by optimizing your registry


"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:eF45m%2386JHA.3860@xxxxxxxxxxxxxxxxxxxxxxx

But threading should always be the last choice, to achieve
something - and it is rarely used/needed, hence the topic
comes up only from time to time - there never was real
pressure to talk about it on a daily base.

You are confusing the limitations of the tool with the actual
real need.
Really?
From what I read here from your "mouth", you have never-
ever developed a threaded application.
And it seems you're not coding since yesterday.
Nothing wrong with that, but you should not claim,
that threading is a requirement in each and every
bread-and-butter-application.

It's not common in VB6, but it is common in languages that
do support threading.
Each experienced developer (no matter what language he's
using) will always tell you the same thing - avoid threads,
if you find another solution.

And most problems are solvable without them - if that
would not be the case, then (given the fact that there are
hundreds of thousands of VB6-Applications out there)
this group would be plastered with threading-questions.

For threading with AX-Exe there are examples also in
the MSDN that comes with your VB6-CDs.

Which as has been told to you, and as the MSDN
documetnation states, is "out of process" communication.
That's also a nice thing which ActiveX-Exes allow, yes.
And aside from that, they allow also the creation of
threads *within* the same (ActiveX-Exe)process,
running standalone as a normal VB-App.

That's not "real" threading. It's not support for CreateThread.
From what I just told you above (ActiveX-Exes support
the creation of threads inside their own process) - how
do you think this is achieved, hmm?
Is there somewhere an API which allows the "injection"
and conversion of different process, to be able to
run as a thread in another "destination-process"? If yes,
please show me the appropriate MSDN-entry.


the source is even available yet, some eleven years
after VB6 has shipped.
My latest threading-helpers are relative new - they were added
to the RichClient-lib only some months ago.

Uh huh... like I said, some eleven years later and the source
is still not available.
No Bill, this is not what you said, you said:
"the source is even available yet"

Which is not the same - but now I get you finally.

What you mean is, that I should have published all my helper-
stuff from the very beginning of VB6 as publically available
source, yes?

Think I was generous enough, by posting different threading
examples into the group over the last 5 years, but I think
I already mentioned that - but no problem, I will repeat
that as often as you need it.


They work with pipes under the hood - in the same way
as some WCF-providers do,

OMG !! You are kidding right ? Here, all along you've
been trying to raise fud around the "out of process" issue,
first by claiming I said "multi processing" when in fact I
said "out of process", and all along you are using pipes,
which are intended for interprocess communication.
Again Bill, please try to understand this time (it's really
a bit difficult as it seems) - VB6 allows *InProcessThreading*.

ActiveX-Exes allow that natively over CreateObject -
and my lowlevel-threading-examples allow that over
the CreateThread-API- and my newer threading-
helpers allow that too - again: *InProcessThreading*.

What is nice with the newer approach is, that you can
create a threadpool InProcess of a normal VB-exe:
Application_A
Thread_1
Thread_2
Application A can now use these threads internally
of course.

And later on you are even able to connect from App B
to either one of the threads, running within App A.
Each Thread within Application_A can have multiple
Clients (either from within the same App, but also
clients from another process).

That was not that difficult now, was it?

No-one would use such a technique for threading purposes ...
Oh - if that would be the case, then why allow the new
WCF-classes in .NET a similar approach?

for every single example using your technique to provide
threading suport, there are tens of thousands of
samples using well tried and tested roper support for
threading in .NET etc.
That is true (regarding the relative new helper-approach
which is now also available for VB-Classic with my tools).

But you will find a large enough number of examples
for VB-Classic, which target the proper usage of
ActiveX-Exes for threading-approaches with VB6.

Now you can paint that how ever you like,
If I only knew what...

but I can tell you, based on *real* technical merit,
..whatever "*real* technical merit" means...<g>


Well it doesn't mean using pipes when you want threading.
You are not forced to the pipe-based approach in my
new helper - instead you can also use the CreateThread-
based approach using other helpers - or use ActiveX-
Exes, which use the CreateThread-API under the hood,
in case you call CreateObject within the ActiveX-Exe itself.

And careful, if you want to avoid pipes, then you should
not use the new WCF-classes for multiclient-capable
threading approaches in .NET.

stability, number of case studies and *real* *working*
implementations, the sound business decision would be
to go the path well travelled.

Yeah, sure the same old story...<g>
Short version:


http://www.zdnet.co.uk/talkback/0,1000001161,39291080-39001111c-20089386o,00.htm

Longer version:
http://www.maccreator.com/articles/monsters.html

So, finally all these "sound business decisions" will tell you
exactly *nothing* about the quality of the possible
alternatives.

Again, that's just fud.

No it is definitely not - instead your statement(s) above:
"...your yet to be finalized library... etc. etc...."

"stability, number of case studies and *real* *working*
implementations, the sound business decision would be to
go the path well travelled"

fullfill exactly the definition of FUD as stated in the wikipedia:
http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

"FUD is generally a strategic attempt to influence public
perception by disseminating negative information designed
to undermine the credibility of their beliefs"

On a purely technical basis, your hacks
Again, these are no hacks...
(instead another FUD-attempt from your side)

are not well tested,
How do you come to that conclusion?

the source isn't available,
Why should it - nonetheless I will open it anyway later on,
after setting up a SCM, adding proper LGPL-headers to
all of the classes, add more comments, put everything online...

And VB-sources, on how to use it, are availabe within
my Demo-packages already for some months now.

and they use pipes of all things jsut to simulate threading.
Again a wrong statement ... pipes are used for the
*communication* with the threads, not for the threads
themselfes. The threads are created per CreateThread-API
(what else on a Windows-OS).

Olaf


.

Quantcast