I posted this to the VS General forum, but I think perhaps this may be a VB
specific isuue, so I am also posting it here:

I am attempting to follow the "Walkthrough: Creating a Windows Service
Application in the Component Designer" in the Help file for VS 2008 in
Visual Basic in order to learn about creating Windows sevices.  I have
encountered a problem with the steps of the lesson.  I did all the steps up
to building the "MyNewService" solution, everything went OK.  Now I am at
this point in those instructions:

"To build your service project
  1.. In Solution Explorer, right-click your project and then click
Properties. The project's Property Designer appears.

  2.. on the Application page, from the Startup object list, click
MyNewService.

  3.. Press CTRL+SHIFT+B to build the project.

Now that the project is built, it can be deployed. A setup project will
install the compiled project files and run the installers that are required
to run the Windows service. To create a complete setup project you will have
to add the project output, MyNewService.exe, to the setup project and then
add a custom action to have MyNewService.exe installed. For more information
about setup projects, see Setup Projects. For more information about custom
actions, see Walkthrough: Creating a Custom Action.

To create a setup project for your service
  1.. In Solution Explorer, right-click to select your solution, point to
Add, and then click New Project.

  2.. In the Project Types pane, select the Setup and Deployment Projects
folder.

  3.. In the Templates pane, select Setup Project. Name the project
MyServiceSetup. Click OK.

  A setup project is added to the solution. "

The problem is with the first step in the "Create a Setup Project for your
service" section.  When I right-click my project, MyNewService, in Solution
Explorer, and point to Add, the submenu that is displayed does not have the
"New Project" item listed.  There are items to add New Item or Existing
Item, as well as other things like adding modules, and items to add
References etc. but there is no New Project choice.  Am I supposed to open a
new project using the main menu File/New item, add it to the Solution
Explorer, then go through the steps to make it a Setup Project, or what?

Help!!  :=)

This group is for VB 6 and earlier; what MS is calling "VB" these days is
VB.Net and the groups for that have "dotnet" or "vsnet" in the name.  The
two are significantly different so the discussions are best kept isolated as
much as possible.

It is certainly /not/ specific to the real VB, the last and final version of
which was VB6 and which is what this newsgroup is for, although it may be
specific to the imposter (VB.Net aka VB 2008 or whatever they are calling it
these days). If, as it seems, you are using the imposter then perhaps you
might like to post your question to the imposter's own newsgroup, the main
one of which is:

    microsoft.public.dotnet.languages.vb

Mike

Hi Pete,

Yes, use File New to add the setup deployment project to the solution.  For
any further questions specific to VB 2008, please use the dotnet forums,
such as :
microsoft.public.dotnet.languages.vb

Or the web based forums :
http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/threads

Note on the web based forums the "Visual Basic General" discussion group is
for VB7 (2002) and later questions, so you are welcome to post VB 2008
questions to there.  Unfortunately the web based and nntp based newsgroup
names are not the same.





Show quoteHide quote

Thanks Bill.  Actually, I found that answer myself by searching (with
bad-boy Google!) where I found this MSDN article, which corrects the Help
File content:

http://msdn.microsoft.com/en-us/library/aa984464(VS.71).aspx


As I said, I opriginally posted in the VS general forum, but I am always
rather "surprised" by the antagonism between the "purists" like those here,
who insist VB 6 was tha last "real" Visual Basic, and the "elitists" who
insist that the entire universe is now VB.Net and that's it, period, end of
discussion, because after all VB Net is supposedly "platform-independent"
and all blah blah and VB 6 is so old-school.

Personally, the way I look at it, VB 6 requires a "runtime" layer, VB Net
requires a VB Net layer, big deal, its six of one half a dozen of the other.
VB Net is a whole way much easier and simpler to write apps in most cases,
but....  it is kind of like buying a kit to build a house rather than having
it built from scratch to your own custom designs, you know?  VB 6 is more
fun!

As for myself, I am a VB 6 junkie too.  I spent two decades making a living
programming data and business apps with VB, MS Office, and VBA front ends to
c/s network backends and such. I confess also to being at times a VC 6 fan
too, so there I am a mere mortal after all.  I am merely exploring the "new"
VS 2008 Pro to see what is "under the hood".

So OK, lets say I do want to do a Windows service with VB 6 rather than VS
2008.  So, is it possible?  And where can I find a sort of "class lesson",
example-by-doing, or template info for the whole package?  I learn best by
examining how a real-world program was done, then finding ways to adapt or
modify the general idea to my own purposes.  IOW I love links to real source
code... :=)

So how would I build (and deploy) a real Windows service, say for my Win XP
SP3 Pro system, using purely VB 6?

And on another topic:  what the heck is "<TPASoft.com Are Identity Thieves>
" all about anyway?  :=)


Show quoteHide quote

Hi Pete,

Cool :)


Really I think there's more of people trying to paint people who use .NET
as "the enemy" in here is really sad.  Many/most of use who like VB .NET use
to use, and occassionally still do use VB6.


The biggest "complaint" against VB, all VB both prior to and including .NET,
is that it is glue the bits together. .NEt is no different from VB6 in that
regard, although there are a greater choice of parts, and you can easily
modify the parts (eg inheritance), but the basic concept of component driven
development lays at the heart of both of them.
Persoanlly I think the difference is mroe in the tools.  Vb6 is a bit like
having a 14 oz hammer, whereas VB .Net is like having that hammer and the
choice of using a framing gun or a finishing gun etc, etc


There's a lot, and if you are cming from a VB6/BA background, there is a
learning curve.


I honestly don't know.  If it can be done, it isn't mainstream, and I
wouldn't suggest going down that route. For example, have a look over in the
multithreading thread. You'll see Schmidt pushing a solution that is reliant
on his library and trying to wrangle threading into VB6. Sure it can be
done, but it is "out of process", and is expensive compared to native
threading like you get in VB .NET.   And the real question is what about
code maintenance and extensibility from that later ?  I see others are
reporting Dr Watson exceptions caused by his approach. If you went to
upgrade that to .NET, I don't think anyone would realistically expect that
to be upgraded properly, and nor would you want it compared to the much
cleaner approach in .NET.  For yourself, I 'd recommend sticking with VB
2008 for this, or even looking at C++ instead.  It's important to not only
realize but also accept this isn't the kind of thing VB6 was designed for.


LOL.  I had forgotten I had my email alias as that.  Some months back, a
"Kevin Provance", aka "Casey Provance", started trying to harass me.  I'd
add him to my blocked senders list, so being the troll he is, he kept
changing his email address.  He then started posting using my email alias,
and in his ignorant arrogance said there was nothing I could do to block him
now.  So I changed my email posting alias to what it is today, and he hasn't
tried to steal that one (yet).  TPASoft .com is Keven Provance.



Show quoteHide quote

Hmm, would that imply, that "new things" (which are by their
nature not yet "mainstream") are always "considered evil"?

Now, if the above is true, why did you take the decision
to use .NET already some years ago?

What's wrong with libraries?

There was no "wrangling" - VB does support STAs,
.....officially!.

Wrong again, and as already told in the other thread you
just mentioned, please stop this misleading non-sense.

One can create STA-threads (natively supported by
VB6, without any helper-libs) directly *within* a
running ActiveX-Exe-Process with plain VB-code
(including an adjustable threadpool).

And with the use of an helper-lib one can create such
STAs also within a normal VB6-Exe-process.

No "out of process" there - all threads running within
the creator-process, parallel to the main-thread.
A look into your taskmanager can help you, to
discover just that.

Only the thread-*creation* is "expensive" (but we are talking
about miliseconds here).
The usage of these threaded apartments is not expensive,
once they are fired up and alive.

As I already statet some time ago, my libs will be opened
to the VB-classic-community at the end of this year (or in
early 2010) under LGPL.

Please read the last entries in that thread too - the culprit was
apparently a somewhat "overtuned" String-Class, which had
nothing to do with my threading-classes.

What do you mean - is there anything that can be "upgraded
properly" from VB6 at all (in case it is a bit more complex
than "Hello-World")?

VB6 was designed, to be able to make use of the System-
Libs, an OS is based and running on, so what.

The VB-syntax (the plain language) only a vehicle, to formulate
and encapsulate calls and functionality, to work either against
System-Libs (the Windows-API) or against classbased libraries
encapsulated in COM-components (Dlls and OCX) - or the
vbRuntimeLib itself.

You probably have never looked at code-snippets in all these
C(++)-implementations, which provide you all the nice High-
Level and "ready to use" things in libraries you work against
on a daily base.

For implemented C-Code-based primitives, this is called
"genius voodoo" - but if someone comes up with basically the
same "low-level" stuff, coded in VB-Classic, working against
the very same system-libs, then this is often called "a hack".
Often without any good reason.


Olaf

Show quote Hide quote Are you serious ?  The difference I was pointed out was between "mainstream"
and "supported" versus "hacks" or "edge" cases.  Let's take for example your
"hacks" at providing threading to VB.  How many people do you think use them
?  How many examples are there ?  the source is even available yet, some
eleven years after VB6 has shipped.  Some eleven years after VB6 shipped you
are still trying to fix problems with your code. Blaming some string
functions you call for the Dr Watson exceptions doesn't address the fact
it's your library that is calling them.  Now compare that to threading in
..NET.  There's no doubt thousands, tens of thousands or more examples for
every one implementation using your yet to be finalized library.
Now you can paint that how ever you like, but I can tell you, based on
*real* technical merit, stability, number of case studies and *real*
*working* implementations, the sound business decision would be to go the
path well travelled.

Those who needed threading with VB6 always found
their way IMO.

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.

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

I've posted other (mostly lower-level) threading-examples over
the last 5 years (from time to time) into the group - for those who
wanted to use threading without AX-Exes - but also easier
examples, which were involving AX-Exes.

My latest threading-helpers are relative new - they were added
to the RichClient-lib only some months ago.
They work with pipes under the hood - in the same way
as some WCF-providers do, allowing multi-connects of
different "consumers" if you want. They can work inprocess,
but also crossprocess.

As said, the new threading-enhancements were the latest part,
which was added to my toolset. And they were designed
with regards to scenarios which can be implemented more
"client/server"-based, which is relative new, compared with
the normal (lower-level) threading which is builtin and stable
for years now already in DirectCOM.dll, which is also part
of my toolset.

It was not my code which was calling these functions -
it was the code of the OP, which was using - and relying
on - faster, alternative string-functions, which he downloaded
as source from the nice speed-comparison-page of Donald
Lessau. This apparently was causing the teardown-crashes,
and not my library.

I only pointed out in addition, that some of the speed-boost-
APIs these functions make use of, are indeed not safe
anymore to use in combination with VBs original String-
Functions - and that my library does not even contain these
functions anymore (removed ca. one year ago).


Why should I - thought we already had this topic -
threading is not a .NET-exclusive thing.

Aside from that, I know what I have with my tools -
I know what I (and others) have with ActiveX-Exes,
which is the official way for VB6-threading, even supported
and addressed with MSDN-examples.
And I know, how to implement threads also in different
languages should I need lightweight-threading-support.



Sorry, I don't understand this sentence (I really tried)

If I only knew what...

...whatever "*real* technical merit" means...<g>

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.

Olaf

Hey, guys, c'mon.  I did not mean to start an argument here  :=).  Relax, I
am just doing this stuff as sort of a learning hobby to occupy my retirement
time, although I do have a sideline business too but nothing where I would
need such a program.  I am just trying to keep up with the technology, you
know?  I never had enough spare time before to explore this stuff like I do
now.

I will look at all this info for sure, thanks for the links.  BTW I knew
that there were libraries available to enable doing this stuff in VB 6, no
surprise there.  There is, in fact, a very popular VB-third-party components
company I used to know years ago (when I was working and could afford that
stuff) that produced such libraries for VB and it was **very** high quality
stuff and **very** expensive stuff too, but damned if I can remeber their
name.....  They had a library that specifically handled such things as
writing VB Windows services, of course it required using their runtime lib
in the product ergo the high cost.  Wish I could recall; what their name
was, I would nuy it now just for the learning tool it would provide.

To tell the truth, from what I have seen so far, doing it in VS 2008 is
about the same as using a VB third-party library, I still don't know what is
***really** involved under the hood so to speak.  I may have to
actually..... <gasp> it hurts to say it  :=) ....  break out one of my
seldom-used VC++ books on Windows programming and actually read up on the
dirt on programming these things in VC++ and then see if I can translate
soem of that into VB.

Anyway, thanks to you both for the advice.

Show quoteHide quote

No problem - you're not the reason for what you see here.

The cause for that "argument" has some history, which
you can find out, by simply searching for Bills usual
responses here in that group.

Aside from that, if you really want to get a service to
work within VB-Classic, then try out the code and
web-link I already gave in my direct reply to you.

If your aim is, to implement the same stuff using VS2008,
then you are simply in the wrong group - advise for that
was also already given by Bob and Michael.

I have no clue, why Bill now also moved our recent
threading-topic into this thread too, but I'm sure he will
answer that with one of his wellknown "no answers",
which nonetheless will always end up in a recommendation
to use .NET, because it is "that much better"...<g>


Yep - for example the NTSvc.ocx is such a small library
(in case we talk about services).

Yep, .NET is based on a large class-library, and the usage
within your code is about the same, as if someone is using
a classbased (COM-) library in VB-Classic.
The functionality shows up, after typing a "dot"...

In VB-Classic you can (have to) assure your own set of
libraries (in a more granular way) over time - mostly growing
with the kind of different functionality your Apps will require -
applications, that don't need any of your familiar libs, don't
have to be shipped with them.

In .NET you already get a huge set of functionality, encapsulated
in the framework-libraries. Not that much effort/need, to find
and choose well-suiting 3rd-party vendors - nonetheless about
the same effort, to get familiar with the functionality of a
certain subset of classes which covers "a topic".
The difference is, that this large runtime-lib is required in the
correct version on your target-systems, even for smaller (share-
ware-like) Apps - and that your compiled code is in an intermediate
format, which needs a second "compilation-step" to be able to
be executed finally within a VM.

That's it very roughly - but as said, please ask (only) VB-
Classic specific questions in this group - .NET-specific
questions belong into the groups with ..dotnet  in their name.

Olaf

It amazes me how many times you resort to ad hominems rather than focus on
technical discussions.  You started out  with your ".netters" attitude, make
up figures,  and the nonsense as above.


Ah, well sometimes some folks have trouble accepting the truth, and prefer
Show quoteHide quote

Bill, believe me, you deserve it.

I tried the whole time to discuss the problem technically,
but you are not able to get even the basic things - I'm
wasting my time with you here.

Come on, don't be that picky - call us "VBers" - I have not
the slightest problem with that. ;-)

What "truth", that .NET is not the right tool for many jobs,
or many developers?

Aside from that, it is apparently not the right tool for the
users who frequent this discussion-group - please advertise
elsewhere.

Olaf

Show quote Hide quote Schmidt, this is a technical forum.  there is no excuse for your ad
hominems. There has been none made towards you, despite your repeated
attempts at trying to take the conversation there.

EOC.

Show quote Hide quote Yep, Carthy - it is -

dedicated to users of VB-Classic, just to remember you again.

Come on Billy - what you call an "ad hominem" is the
simple mentioning of the term "no answers".

And so far you have not delivered answers - at least
not in the recent discussion with me, so I really don't
know, what's wrong with that term.

Olaf

Hi Pete,

The msdn library documents much about services (at least from a C++ view) :
http://msdn.microsoft.com/en-us/library/ms685141(VS.85).aspx

Do consider seriously about using the right tool for the job.  Quoting from
the example Schmidt recommends, the opening passage reads:

"It is known, that Visual Basic isn't most appropriate tool for developing
of Windows NT/2000/XP services. The problem is, for service development is
necessary to use API function CreateThread, which is not supported nether in
VB5, nor in VB6. VB allows creation of multi-thread programs, but not using
CreateThread function. "

Given your versatility with VC++ and having VB 2008, I think the advice
abotu the road well travelled makes a lot of sense here :)




Show quoteHide quote

The last sentence in the above paragraph is just wrong
(or at least not complete).

VB5 as well as VB6 allow the usage of the CreateThread-
API (otherwise his Service-Code would not work at all),
if you follow some rules regarding ThreadLocalStorage (TLS)
initialization whilst entering the ThreadFunction.

As said Bill, get your facts right - try to understand the COM-
behaviour of VB-Classic - and then come back and let's
have a technical discussion.

Olaf

Show quote Hide quote I suggest you get your facts right Schmidt.  That part I quoted was the
opening sentences from he link you posted, quoted verbatim.

I'm (was) aware of that Billy - and I was referring to
the quote from the site in question, saying that the
author was not right with his last sentence.

It's like talking with a child here, which is not able to
read properly (yeah, another "ad-hominem" as you
will call it), but it is really frustrating in an argumentation,
when the counterpart is not able, to bring even the
simplest communication-requirements in line.

Olaf

I agree, Bill.  And since a service is so easy to write in VB.NET, I think I
will probably just stick to that.

What prompted my question mostly was that, when I was working in VB 6, I had
a library that could be used to imlement services, as I stated.  I finally
remebered the product, it was the Desaware COM library:

http://www.desaware.com/products/universalcom/ntservicetoolkit/index.aspx

which was expensive back then ('90s) and is almost absurd now  (all the
Desaware products are way cool though and come with source code for
everything).  But as you see, it enabled one to write a service quite
easily.

I still have the product itself around here somewhere, it was given to me
from where I worked (nobody else even knew what it was) but I just never
installed it on my home PC after I retired.  But it was something like using
VB.NET to write a service, you just called a Desaware lib to do the job
instead of calling VB.NET.

Anyway, thanks for all the help, your points are well taken.  I'd rather not
revert to VC++, its been so long I would probably have to go take a
refresher course, anyway  :=).  And I always liked VB 6 way better:  I can
actually "think" in VB, you know, whereas in VC I always had to translate
what I was thinking into C to use it.  But that's just me, perhaps....

Show quoteHide quote

Pete B wrote:
Definitely *not* just you!  Don't let the evangelists fool ya.  :-)

Hi Pete,

Yeh, beats using a hammer to drive screws ;)

Show quoteHide quoteIt does seem pricey, but Desaware, which was founded by Dan Appleman, are
reputable and do (as far as I know) stand behind what they sell.
Seems a lot of companies selling VB6 stuff are jsut falling off the face of
the planet, so having source code is pretty much a must have for stuff like
this, IMO.


Haven't used it.  I noticed on the web it keeps say "interactive service". I
wonder if that is alluding to the same limitation of not beign able ot make
non interactive services.


<g>  Whenever I'm working in C, I find I'm constantly pausing to check if
that's the pointer address being passed or the value at that address.



Show quoteHide quote

Hi Schmidt,


You are confusing the limitations of the tool with the actual real need.
It's not common in VB6, but it is common in languages that do support
threading.



Which as has been told to you, and as the MSDN documetnation states, is "out
of process" communication.  That's not "real" threading. It's not support
for CreateThread.


Uh huh... like I said, some eleven years later and the source is still not
available.


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.  No-one
would use such a technique for threading purposes in a language that
supports native threading.  That you somehow think they are appropriate in
VB6, is about the limitations of VB6, not about using the appropriate
techniques.


No problem. Waht I was referring to is 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.




Well it doesn't mean using pipes when you want threading.


Show quoteHide quoteAgain, that's just fud.  On a purely technical basis, your hacks are not
well tested, the source isn't available, and they use pipes of all things
jsut to simulate threading.

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.

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.

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.

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.


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.


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?

Oh - if that would be the case, then why allow the new
WCF-classes in .NET a similar approach?

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.

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.

http://www.zdnet.co.uk/talkback/0,1000001161,39291080-39001111c-20089386o,00.htm
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"

Again, these are no hacks...
(instead another FUD-attempt from your side)

How do you come to that conclusion?

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.

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

Show quote Hide quote Again with the ad hominens and now blatant lies.
I definetly have created *many* threaded applications.


No kidding.

Show quote Hide quote Where do you see an ad-hominem in the above?

Again, from what I have to *read* here from your side -
this is not very probable, sorry - do you have some examples
online which are able to convince me?


Olaf

Show quote Hide quote What part of "ad hominem" don't you get ?

For the record I have posted many threading posts and applications.  I even
recall one being used as a scheduler for TechEd some many years ago that was
publically available.    But this is all besides the point. What you are
doing is making things up, "ad hominems", in a pathetic attempt to discredit
technical arguments.  And after reading your other posts you just posted
where you try to "flame" it up with silly name calling, I think I'll just
leave it at that.

your childish "ad hominem " struggling aside...

Would love to see a link to some of your selfwritten
threading-stuff, really.

Olaf

On Sat, 13 Jun 2009 18:17:20 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

It's a pity that you now prefer to play the offended guy, because you
both were at an interesting point right now: Olaf says that VB6 AX apps
allow in-process-threading, you say they don't.

I'm with Olaf, last but not least because I just made I tiny, working
example (in VB5, BTW, without any hacks).

Wanna see it? Download http://www.enzinger.net/archives/MTAX.zip.
Compile. Start MTAX.exe. Start your Taskmanager. Click the button.
Watch.

Since "out-of-process" is impossible without a second process, please
tell me where this second process is.

Wolfgang Enzinger wrote:
Wolfgang, I get a CRC error and broken files on extraction. I think it's
corrupted.

On Sun, 14 Jun 2009 13:31:29 +1000, Jason Keats wrote:

Sorry ...

Try here: http://www.enzinger.net/archives/MTAX2.zip

Yep, working here - (not only the downloaded zip ;-))

Olaf

Hi Wolgang,

Show quoteHide quoteHuh ?  there's no threading in that, rather you are queueing windows timer
events.

What does GetCurrentThreadId tell you ??

[repost, didn't come thru obviously ...]

On Fri, 19 Jun 2009 12:49:48 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Nope. Look again.

4012, 2516 and 2640. You may see different values. *g*

I made it a little more noticeable for you, since you obviously have
problems using your Taskmanager:
http://www.enzinger.net/archives/MTAX3.zip

HTH

Wolfgang Enzinger wrote:
Gotta agree.  Really disappointing to see one party walk away in a huff, just when
the rubber was meeting the road.

Hi Wolfgang,


It's not a question of "playing the offended guy", it's a question of a
constructive discussion versus one where there's just childish name calling.
The name calling is the most apparent manifestation, but behind it there's
lots of twisting what was said, making things up etc. And it stems from
wantingto bash .NET, rather than any rational, proper business or technology
based discussion.  So it's prety much a waste of time.


Actually that's what Olaf was saying I said, and it's that kind of twisting
that leads us away fro the real issues.  What I said was a VB6 app can do
threading using activex.exe but that is out of process.  I believe that is
in fact a fact.  Do you dispute it ?

What Olaf implied was that his external library written in some other
language (probably C++ but he *won't* release the source for it until next
year ???) isn't out of process, yet what he did say was his threading was
not light weight and that his library uses pipes.

So putting the name calling aside, let's look at what is really being said
here:

An out of process approach has some benefits in that the external process
won't tear down the calling process should it crash; conversely there can be
issues with lifetime of the external process.  But the *significant* issue
when it comes to threading is that marshalling must occur between the
processes.

What's Olaf's libraries do *Exactly* is hard to tell because he won't put
the source code out there, but we do know there is also marshalling
occurring. He referred to is as "heavy", or in other words has overhead.

Pipes, are a windows technology designed for communication between
processes. If you look them up in the SDK you will find them under
"Interprocess Communication".  Olaf tried to muddy that by saying that's
what WCF uses, when in fact it's one of the transport mechanisms you can
choose to use in WCF, but the important thing to remember is WCF is designed
for service based transactions, which means not only inter process, but also
across machine boundaries.  SQL also has the option to use pipes: again this
is interprocess communication: data is marshaled.

If you look elsewhere you will see various documentation on how VB6 does not
support  true threading.  For example, today I saw Olaf admit that VB6 uses
Thread Local Storage, and said you can't call any VB6 methods or use any
variables from your app in a thread callback, instead you have to wait till
it synchronizes with your app's single thread, via PostMessage.

So compare the options:

VB6 native: use activex: marshalling overhead

VB6 using an external library: marshalling overhead regardless of whether
you use Olaf's library or a .NET library.

VB.NET native solution: rich set of threading, locks, synchronization
capabilities.  Marshalling not required.  Parallel link libraries as well.


Zip doesn't work here.


See above. I think you are missing the big picture.

Of course - activex.exes can do InProcess-Threading -
that's what Wolfgangs example demonstrates.

No, the RichClient-lib is a normal VB6-compiled AX-Dll -
and DirectCOM.dll (also used in that threading-contexts) is
a small PowerBasic-compile.

Yes - I told you the reasons already - and the threading-
support is only a small part of its functionality (or code-
volume) - only making up about 5% or so.

Yep - the communication over the pipes is not "light-weight" -
but it is comparable with the performance of OLE-marshaling -
and that's enough (threading works best, if you don't stress the
communication-channel - let your threads work as autarkic
as possible).
But that's the high-level helper in my toolset, which was built,
to be able to replace ActiveX-Exes (In- and OutOfProcess-
threading-capabilities), and to support (client-) / service oriented
implementations/scenarios better.
With DirectCOM.dll there's another threading-helper in
the toolset, that supports lightweight-threading, usable without
any marshaling - but that needs a bit more efforts (to implement
locking, and synchronizing yourself per Mutexes/CriticalSections).


That is true for the one part of the game (CrossProcess-
talking between different threads) - and to remember you
again - InProcess-Threading is also possible - either with
normal VB6-ActiveX-Exes and also with my (or others)
helper-libs.

No - that's again a wrong statement - marshaling *can*
be used for communication between threads - and in
case of ActiveX-Exes, the OLE-Marshaling is the native
(and easiest) way to communicate - but there's Shared-
Memory, Pipes, TCP/IP, UDP, WinMessaging too - each
one able, to bypass OLE-Marshaling if one needs that.

The threads are spanned per CreateThread - TLS and the
STA-environment is then created on such Threads automatically,
as soon as the first Worker-COM-Instance is created on that
thread in the correct way. This worker-class-instance is then
waiting for requests *on* that thread.
And since I wanted a multi-client-capable, serverlike Thread
I've choosen Pipes for the communication-channel - the
server-end of that pipe running in the new created thread.

You can reach about 10000 Method-Calls per second into
such threads - and that's about the same value you can reach
with OLE-Marshaling too. But threads are there to do something
"on their own" - they scale best, if they work as isolated as
possible - if you need to communicate with a thread more than
1000times per second, then you're doing something wrong in
your thread-implementation I'd say.
So, that overhead is in most scenarios a "no-issue" (if you need
to talk below 1msec with your threads, then usually hardware or
drivers are involved - and for that stuff you should use the LowLevel-
threading then - either per best suiting language (probably C,
if it comes to hardware-stuff and drivers) - but also VB6
would allow LowLevel-Threading - but with more efforts than
by using better suiting languages.

And that proves what?
TCP/IP you will find even in communication-scenario across
*countries* (now imagine that ...<g>) - nonetheless I'm able
to use TCP/IP for communication between threads inside
a single process.

Yep - and it's one of the recommended channels for
InterProcess-communication on the same machine.

And for such services usually sockets are the recommended
channel - and my toolset supports that too - in a very similar
way to how the pipe-based thread-helper works *within* a
host, you can talk across different hosts with the builtin
RPC-Server and RPCClient-Classes.

As already said - the term "interprocess-communication" does
not automatically involve "marshalling".
Marshalling is a term that is normally used in conjunction with
(parameter- or object-)serializing - usable in a generic way
for a whole set of different parameter-types, which often are
defined in an interface - also often involving Proxy-Objects.
And I would say - what an SQL-Server does, putting its
"Raw-Data" on a pipe or a socket is one level below that.


Define "true threading"...

Yes - you cannot use them as long as you don't have
initiated the TLS and the STA-environment - but it
is possible, to initialize both requirements relative easy,
in case you create a simple (VB-)COM-object on such
a thread (per TypeLib-Call to CoCreateInstance for
example).

PostMessage is an asynchronous call, which is in no
way able to synchronize anything - in the context we
talked about there in the other thread it is in fact one of
the few allowed calls in the MultiMedia-TimerCallback -
and so we just make use of this call (per TypeLib).

In case you want to use that comfortable communication-
channel - yes - but one marshaled call only needing
about 0.1msec - enough to pass a thread a set of
parameters and let it work for some 10-100msec or
longer after that (again, threads make only sense, if
they can do their work relative isolated on their own -
they scale best, if you don't interrupt them with too
many communication-requirements or locking-barriers).

Again - you can choose other communication-channels
to talk with your threads,  in case you need something
faster (but as stated above, with the "cost" to loose
some comfort).

The same holds true also for VB6-Threads (if you want
to go there). Nobody holds you back, to define a shared-
memory-area, visible to different threads - mapping that
memory area for more comfortable access to (typed)
VB-Arrays, and to handle the locking in the same way
as in .NET over the usual sync-mechanisms (Mutexes,
Semaphores, CriticalSections).

Don't get that part - regarding the threading-topic here.

Ah - "the big picture" ... - from what I had to read here
again - I can only repeat, that you apparently have no
experience with threading, sorry.


Olaf

No it does not.  Wolfgang's example demonstrates using a timer on a form to
trigger events.  The code is terrible in that it changes object references
and hence looses events. fails to close properly, and fails to open again
becuase it sets a windows property on the desktop window.  It certainly does
NOT demonstrate threading. **ALL** the code in his sample is called on the
UI thread.  That is, it is single thread.

PowerBasic, C++, it's still nto VB6.



So why don't you seperate the threading support and make that an open source
project ?


Exactly.

IOW: you are saying it is comparable to inter process marshalling.  Thank
you for finally admitting that.


Yet to be deomnstrated.

Marshalling *must* occur for communication.



That would depend on the degree of marshalling. The issue of course is not
how often it can be called, it is the marshallign of data.  So it depends on
how much data is marshalled.


Again, all you are saying here is your approach is no better than inter
process marshalling.


And proves the basic claim of inter process marshalling (or the equivalent
or worse costs)


Exactly, *inter process* being the key here.



"Raw data" is in fact marshalling, just like bytes are over TCP/IP.  The
data has to be reconstructed on the receiving end and is separate from the
in memory data from the sending end.



Oh come of it.  You have already admitted there is marshalling and the need
to call PostMessage tc, etc.


Not with pure VB6.



PsotMessage is synchronous with the UI thread.  The point being in *your*
**VB6** code, your code is running on the UI thread.  the PostMessage won't
be processed until your app yeilds to the windows message pump.


Marshalling overhead.  If you didn't think it significnat then why even
bother using your libraries?
Why not just use an Activex.exe ??

Again, the fact remains, marshalling overhead.


That'd be very limited, and wouldn't even let you work with strings really.
You might be able to fudge things there, but really it would be a mess.

Mutexes and semaphores are incredibly heavy weight for threading
synchronization when all you want is an interlocked read or write.


I suggest you look up the Parallel LINQ and Concurrency libraries then.


<sigh>  And for a moment then I thought you had grown up and stopped the
silly name calling.  If you think Wolfgang's code somehow shows free
threading in VB6, then I think it is you who has no real idea on threading.

On Fri, 19 Jun 2009 18:31:37 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Nope. Look again. The events are triggered by threads.

Huh? Please explain.

Huh? Please explain.

It does indeed set that property, yes, but please explain what has to be
done in order to make it failing to open again. Are you talking about a
second app instance while the first instance is still running? No
problem to allow this.

Yes it does. Look again.

Duh ... are you really that incompetent? Every child can see you are
wrong.

On Fri, 19 Jun 2009 18:31:37 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

OK, I see that you failed to read what I wrote: "Compile. Start
MTAX.exe. Start your Taskmanager. Click the button. Watch."

You were running it in the IDE only, right?

I added a few more lines in order to make it foolproof and to allow
multiple instances: http://www.enzinger.net/archives/MTAX4.zip

Again: Compile. Start MTAX.exe. Start your Taskmanager. Click the
button. Watch.

McCarthy is a liar and he will do anything to perpetuate his lies. He is
also a thief and he is not to be trusted. He is here purely to cause trouble
and the best thing to do is to ignore him and he will eventually go away.

Mike

Hi Wolfgang,

Show quoteHide quoteYes I was .  Seems a rather significant limitation.  So what you are saying
is you can't debug the code and can't even run it from the IDE and have it
behave the same as if run from outside of the IDE ???
Wow !!  Admittedly it's been so many years since I tried to get threads
working in VB6, I really wasn't expecting it to be that very very bad.  I
would have expected perhaps not being able to break on any of the other
threads, but to have the entire program fail to work, well that' sucks.
Compared to VB.NET where I can not only run the application from the IDE I
can also break into the threads, and even use edit and continue to change
the code in different threads.

As to the issue of marshalling, please refer back to the other posts by both
myself and Olaf (in part in other threads) where the thread local storage
was discussed.

That much is obvious, McCarthy. The word "tried" in your statement tells it
all, well almost it all, it would have been more honest to say "tried and
failed"! Just admit that you're not good enough McCarthy and that you simply
don't understand what is going on. Earlier in this thread you said that
Wolfgang's code, which you actually had a copy of, was merely using a Timer
to trigger events and that it wasn't threading at all, clearly demonstrating
your complete lack of understanding on the matter. It is obvious that you
can only perform threading yourself McCarthy by using somebody else's
solution after they have written the required "black boxes" for you, as is
the case in VB.Net. Why don't you just come clean McCarthy and admit that
you are out of your depth.

Mike

On Sun, 21 Jun 2009 11:51:35 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Calm down, Mr. McCarthy. I never said it's perfect in the IDE. Keep in
mind it's ten year old. In fact I wrote the code in VB5 which is twelve
years old.

However it's clear why you're trying to change the subject here all of a
sudden. We were discussing whether VB6 AX executables can do in-process
threading; Olaf said yes, whereas you said they can't and that everybody
who thinks you're wrong is missing the big picture. IOW, you failed
miserably as has been demonstrated here:
http://www.enzinger.net/archives/MTAX5.zip

Of course you don't want to talk about that now, hence the topic change,
but everybody can see that you were even unable to properly read what my
code actually does.

OK, and this is what you are actually in here for. Bill, since you hate
VB6 so much and obviously don't have too much knowledge about it, why
don't you just leave us alone? Do you really wish that some folks again
move to the .NET groups in order to rant about .NET there? Just asking
because that's exactly what you're doing here. You should probably ask
folks in .NET groups first what they think about this idea.

I never participated in that discussion because I probably don't know
enough about the topic. See, I admitted this and I'm still alive. It
works, try it.

However, from my experience with you regarding in-process threading, I'd
be surprised if you were right and Olaf was wrong. Perhaps you'd better
go away before you ruin the rest of your reputation. Your choice, of
course.

Anyway, as long as you prefer to spread false information about VB6, I
will correct you whenever possible. Afterall, most people here are
interested in a serious technical discussion.

Hi wolfgang,

Show quoteHide quote"Perfect" ??  You seemed to actually hide the very important fact that it
doesn't run properly at all from the IDE.   That's a very serious oversight
on your behalf.


Yeh well it certainly is hard to maintain given you can't run/debug it from
the IDeEproperly, so I could imagine any changes would take some work ;)


Again, as I said to you earlier, using an activex.exe for threading for VB6
is out of process.  And I stand by that, and the docuemtnation also agrees
with me.  what you have done is show some smoek and mirrors parlour trick of
the activex.exe calling upon itself.  It's cute, but hardly practical given
you can't run it from the IDE, can't debug it etc, etc.



If you want to delude yourself into thinking that, knock yourself out ;)


Actually I suggest you go back and read what I wrote to yu previously, abotu
how there is marshalling occuring.  And don't forget the bigger picture,
which means real world development.  If you read the other thread, the one
which started the discussion on threading, the original poster talked highly
abotu the need to debug and have edit and continue.


No it's not what I am here for, but whilst I am here, when folks post
misleading information about VB.NET, I am quite happy to correct that :)


Wolfgng, I've been in these forums for many mroe years than I see


Oh, the ad hominems.  I'm sorry for you you find it so hard to admit that
VB.NET is the correct solution to use for threading and for windows services
(as per this thread), but no need to resort to personal attacks.



Oh you mean like Mike Williams, Mayanana and Kevin Provance are ??  Those
guys don't even use .NET so why are they posting there ?


"Just asking" or threatening to start some silly flame war ?


yawn.




Uh huh. IOW: you are ignoring the pertinent issues that were said to you
earlier in this thread.  Seems the one trying to side track this
conversation is you, not I.  And I suggest you read earlier where I talked
about the road well travelled.  you can't seriously be recommending people
develop solutions in VB6 that require them to forego the ability to debug ?




Well I suggest you go and read it, because you'll find that Olaf said that
marshalling was occuring becuase the threads as using TLS.
I mentioned this to you before, when I originally said to you the focus on
"out of process" was missing the point.



LOL.



Uh huh.  In reading your above post I found very little of that, just a
serious of ad hominems.  funny that.

On Sun, 21 Jun 2009 20:58:19 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

When I recommended to study MTAX2.zip, I wrote: "Compile. Start
MTAX.exe. Start your Taskmanager. Click the button. Watch.". Silly me, I
assumed your were able to follow these simple instructions. Since you
are not, obviously, I made the code more foolproof; these small changes
are contained in MTAX3.zip and later versions. It does run properly in
the IDE with these small modifications, just single-threaded. That's how
it has always been in the VB6 IDE, be an AX EXE in-process or
out-of-process.

Will you do me a favour, please?

Download http://www.enzinger.net/archives/MTAX5.zip. Compile. Start
MTAX.exe. Start your Taskmanager. Click the button. Watch.

Just in case this is impossible on your side for whatever reason, this
is what I see:

* When starting MTAX.exe, it shows up as one process in Taskmanager,
with 3 threads. Don't know why there are 3, I'm only dealing with one,
the main thread. Whatever.

* When I hit the button, which, in my humble opinion, launches 3 more
threads, I see the treadcount in Taskmanger go up to 6 for MTAX.exe. 10
secs. later, when these worker threads are done, it's back at 3 again.

If I'm not mistaken, for out-of-process a second process would be
required. Can you tell me where it is and what its name is? Why are the
additional threads added to the MTAX.exe process if they are
out-of-process?

Nice.

No it does not. At least in the German version that I have it is clearly
stated:

* if in an AX EXE an object is instanciated by "New", the object will be
in the same thread as the caller

* if in an AX EXE an object is instanciated by "CreateObject", the
object will be in a new thread resp. in the next thread of the pool.

In the English version, the chapter may be called "internal and external
object creation", if you want to lookup.

You said that my code "changes object references and hence looses
events" just because you saw ObjPtr(); what does that have to do with
marshalling?

Yeah, terrible. Poor guy.

Show quote Hide quote Well what you didn't say was that your code couldn't be run from the IDE.
It was only *after* I reported back here the issues with your code when run
from the DIE you admitted it couldn't be run from the IDE.


LOL.  By "properly" you mean a message box saying it can't be run in the
IDE.
That's just disingenuous to claim "properly"  who are you trying to mislead
?



There's definite limitations of the VB6 IDE, that's for sure, that's why I
said VB.NET was a good choice for VB and threading.  Liek as been said, it
even supports edit and continue on multiple threads.

But I'm not sure the limitation in your code is absolute in VB6. I seem to
recall debugigng ActiveX.exe's called from normal exes.  In fact that is the
usual and the **recommended** way to use ActiceX.Exe's in VB6 for
asynchronous



Yes, and as I said earlier, this is not the standard use of ActiveX.exe. You
are NOT calling on the activex.exe, you are actually running that as the
application.   The big problem with that of course is you forego the ability
to run it form the IDE **properly**.   The issues of in process or
marshalling pale in significance.


Show quoteHide quoteI suggest you read the documentation on Asynchronous programming in VB6,
where your VB6 applciation uses CreateObject for objects that are in an
activex.exe.




Show quoteHide quoteTry reading the post prior to that. the above was in reference to running
your second zip from the IDE, as I know you are well aware.




yawn.

On Sun, 21 Jun 2009 23:03:22 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Now that is funny ... you didn't do with it what you were told, and then
you "reported back there were issues" so that I had to "admit" ...

Listen: I also failed to mention that you have to unzip *all* files
before you load them ... so if you had unzipped only one file and
reported back that it doesn't compile, then I would have had to "admit"
that this is another limitation of my project, right?

This is plain ridiculous. Are you sure you really are a developer?

You know that's not true. It's not saying it can't be run in the IDE, it
says: "in IDE, single threaded; compile for multithreading experience".
This MessageBox was integrated for those who are unable to understand
what I told them before - so far I only see one with this problem.
Anyway, the code can be run, debugged and edited at runtime in the IDE.

Look at the code again. The significant change I made was that I
disabled the discoupling while the code runs in the IDE cause it makes
no sense in a single-threaded scenario.

I suggest you answer my questions:

* Can you tell me where the second process is and what its name is?

* Why do the additional threads show up with the MTAX.exe process entry
in TaskManager if they are out-of-process?

Can you answer these?

Show quote Hide quote LOL.  The *facts* are you never said **anything** at all about not being
able to run it in the IDE. There were no comments or anything in the code to
suggest you couldn't.  It was only since I pointed out the issues if you
did, you then admitted to that **MAJOR** limitation.  In the actually real
**meaning** of the discussion, that limitation is very significant.


Huh ?  first, I think most developers woudl open the code and expect to run
it.  what kind of developer are you that doesn't docuemnt such limitations ?
Is that how you share work with your team ?  Have you never heard of
docuemtning the code ??  You seemed to put a lot of useless comments in the
code, but nothign in there ot suggest nto to run it form the IDE.  It's as
if you were trying to hide that lmitation.



Oh this is just nonsense.  The Multi threading cannot be run in the IDE.  In
fact in your first code, if you ran it from the IDE the reference count in
the collection was never decremented, so there were always pending jobs
reported even though those jobs couldn't run.  And if that wasn't bad
enough, becuase you coudln't properly exit out you have to force the
debugger to stop, and then it won't run agian because you were setting
properties on the Desktop window.



Utter nonsense.  It cannot, and you know it.  The threads do not run.  This
is really disingenuous of you to claim otherwise.


I really don't care which of the issues you now say you have addressed. The
facts remain you cannot debug the *real* code *properly* with your approach.

I am really amazed anyone would use such an approach, little less distribute
the code like you originally posted.  Let me guess, you use ot tell people
oh sorry you can't restart the app, you have to restart windows ??


You know, you still haven't listened to a thing that has been said to you,
have you ?  Instead of reading the documentation or going back and reading
the things I said to you that you obviously skipped, you still think the
significant part of this discussion is about whether or not it is in or out
of process.  I answered that before you even posted a link to a working zip.
But just to be nice, I'll repeat the main points again for you. Whether or
not it is in process or out of process is in itself insignificant, what is
important is the overhead of marshalling and synchronization.  The only
advantage out of process has is it doesn't necessarily pull the app down if
it crashes. So what exactly do you think the **REAL** issue about out of
process is ?  It is of course about the overhead.

So I asked you about what marshalling you think is occurring in your app.
to which you replied you don't know.  so you have an app that's compiled as
an activex.ex, can't debug it, and based on your code you say you'd been
using since VB5, if your app crashed the user would have to restart windows,
and you can't tell me if there is or isn't any overhead difference ??    Do
you really think there's no synchronization, no marshalling, no queuing ?
What about thread deadlocks ? Race conditions ?  Is that being handled for
you or not ?

So moving aware from silly parlor games....   Something tells me you will
continue on this silly track of yours even though I first told you it wasn't
an issue of in process or out of process (yes **do** actually go back and
read what I first wrote to you)  In the scope of the real discussion, where
I was , before you and Olaf interrupted, talking about the road well
travelled, I think all that out have shown actually re-enforces what I was
saying.  The best you have been able to throw up is an app you can't debug,
and you can't even tell us why you would do that rather than call on a
activex.exe as per the usual documented way.  At least then you could run
the activex.exe in one instance of VB6 and your app in another.

What you've done is not even focus on a tree, but instead on a blade of
grass, and in doing so ignored the entire forest. You can't even tell us if
marshalling is occurring in your app. I think the only possible reason you'd
use your hack is to keep the app a single file, but even then it has to be
registered, so you need to distribute it with a setup program.  Considering
how much you loose, and considering how bad your original sample was, the
one you said you've been using since VB5, I'd expect such usage to have some
good reasons: yet you haven't mentioned a one. Fro ma business perspective
the issues are performance, robustness, code maintenance and development
costs. You've failed on 3/out of 4 of those *badly*, and on the performance
or overhead issue you said you don't know.  Road well travelled versus
parlor tricks.

On Mon, 22 Jun 2009 01:37:16 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Obviously not.


********
Date: Fri, 19 Jun 2009 12:40:36 +1000
Message-ID: <#8xdadI8JHA.3***@TK2MSFTNGP04.phx.gbl>

Yes. I gave you code that demonstrates you are wrong. There is no second
process.

See below:

Show quoteHide quoteUh huh.  So tell Wolfgan, when your app uses an activex control do you take
that to mean your app is compiled as an activex control ?  I think not.  Not
are you only deliberately trying to twist what was said, you still have not
addressed the REAL issues about performance, marshalling, robustness,
development costs and maintenance.

On Mon, 22 Jun 2009 03:04:24 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Bill, we can talk about ActiveX controls, performance, marshalling,
robustness, development costs and maintenance later if you want.

But first let's clarify these two questions:

1) where is the second process?

2) why does the thread count of MTAX.exe increase?

Can you answer these?

Hi Wolfgang,


Show quoteHide quoteReally ?  You told me before you didn't know about the marshalling


Can you ?  You told me you didn't know if there was any marshalling going
on. ?In fact you still haven't said why you would use such code given all
the other issues with it.  Like was previously said it failed miserably in 3
of the 4 criteria.

Hi Wolfgang,

Show quoteHide quoteI looked at this again, and there seems to be some dogmatic focus form you
on whether or not the activex.exe launched as standalone exe is out of
process or not.  Somehow I think for you to "move on" you need to hear me
say htat it isn't out of process. It isn't, but as I said earlier the issue
is about marshalling and overhead, not "out of process" or not.  And I also
want to make it clear that I stand by what I said that using an acitvex.exe
from an app is out of process.  If your goal is to twist that "using" into
compiled as" go ahead knock yourself out.

So the big issues, the real issues. The issues of debugging, the issues
about performance, about marshalling, about whether or not there are thread
deadlocks or a queued synchronization, these issues, the issues relevant to
*real* development you have constantly avoided. So perhaps now you will
answer them as per your promise above ?

On Mon, 22 Jun 2009 12:31:11 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

Great idea, McCarthy.

Finally! Congratulations, McCarthy!

I will help you to finally answer these questions:

1) where is the second process? -> There isn't any.

2) why does the thread count of MTAX.exe increase? -> Because the
threads are in-process.


********
Date: Fri, 19 Jun 2009 12:40:36 +1000
Message-ID: <#8xdadI8JHA.3***@TK2MSFTNGP04.phx.gbl>

It took you quite a while and some help to find out now that you were
wrong, but better late that never.


Yeah, yeah. Get a life, McCarthy. Bye-bye.

Wow Wolfgang, I am disappointed you didn't keep your word.  It's not
unexpected based on your "posts", but none the less disappointing you
chicken out when it comes to talking the real issues.    In any case, just
to re-cap, so far the following alternatives have been mentioned:

(1) Using a Activex.exe from an VB6 application  (nb: not to be confused
with (3) compiling the app as an acitveX.exe)
    - out of process, hence cross process marshalling
   - can be debugged by using multiple instances of VB6 IDE
   - well documented
  -  no real control on locks
  -  typically requires circular references (care need to ensure tear down
of these under all circumstances)
  - common pattern is to use a timer to launch different thread

(2) Use an external library
  - ability to debug depends on source code availability and having the
appropriate IDE for the library
  - details scan be sketchy dependant on the level of documentation
- typically marshalling still occurs
  - degree of control over synchronization and locks/deadlocks depends on
what the library exposes
- options include libraries built in C++, .NET (C# or VB.NET), and others.


(3) Compiling the app as an Activex.exe
   - can NOT be debugged properly (see Wolfgang's first code sample for type
of issues)
   - little if any documentation
  -  no real control on locks
  -  typically requires circular references (care need to ensure tear down
of these under all circumstances)
- developer notes: app is compiled as a standalone exe,; code is needed to
ensure UI is not launched on each class instance creation; Use
App.TaskVisible (nb this appears that App is a different object.)  SxS may
work: untested.


(4) Using VB .NET
  - full support for debugging
- full support for Edit and Continue on 32 bit platforms
- full control over threading locks and synchronization
- full support for free threading
- well documented
- no circular reference issues
- no need for marshalling across apartments or domains.


So if we look at these, and focus on the four criteria I mentioned earlier :
performance, robustness, code maintenance and development
costs. Option (3) fails miserably on maintenance and poor on robustness
(even worse if you consider the difficulty in development). There maybe some
advantage of (3) over (1) in terms of performance: local marshalling versus
cross process marshalling, but that would only be of significance where
there was in fact a lot of data being marshaled. Given the limitations, out
of (1) and (3), (1) from a business perspective would generally be the
better option.  Only when there are large amounts of data being marshaled
and there was a significant performance difference between (3) and (1) would
(3) be preferred to(1), but in those cases, given the other issues with (3),
options (2) and (4) make more sense. And between (2) and (4), (4) makes more
sense, and is preferable as long as the developers are skilled in .NET.

Show quote Hide quote As already said, Wolfgang posted an example, just to prove
one thing: VB supports *InProcess-Threading* - something
you finally admitted after your usual "no it does not"-replies,
which came up over the last days.

And my goodness - his first "thrown together" example
had some flaws in it - but already that demo proved, that
you were posting again misleading statements into this group.

Same thing basically as sometime ago with the wellknown
"DoEvents-Thread" (constant denying, shifting topics -
etc.).


You know Bill, it is somewhat disgusting, to discuss things
with someone, who only wants to make trouble - who
does not look in a constructive way at an example, which
was written to demonstrate and prove only simple thing.

So I can only repeat - it'd be your turn now, to deliver some
..NET-code which proves your misleading claims - about
VB, being unable to do proper, performant threading.

Come up with something, then let's see, how the VB6-
solution would look like (it would look different of course) -
and how it finally performs.
And I already made some comments about blaming
others code - so now it would be you, who should think
twice, how to write things up and how not - after your
ranting, we expect a perfectly coded example now of course
(best practise) - not only a topic-oriented, small demo,
which proves something.

The same documentation applies also to InProcess-Threading
with an Activex.exe - the only difference is the CreateObject-
Call instead of 'New' (called within the App itself).

Wrong - OLE ensures the locks already - it's the safe thing
we have here in VB-Classic - .NET lacks that automatic
locking-feature - you are on your own with all your lock-
handling. Raising Events into your GUI-Controls, requires
explicite Control.Invoke in .NET - where VB6-Events,
raised from a Thread are by their nature already synced,
that is, what the OLE(marshalling)-environment ensures
under the hood too.

No - Wolfgang was using that presumably, to not being
"flamed" by you, that he was using API-Declares ("OMG-
an API-Call - but that's not VB-Code anymore...")... There
are other ways, to ensure an async-decoupling with a few
lines of code - you will not need a VB-Timer on a Form
to ensure that "in plain VB".

That's BTW the small drawback, being on the safe side
regarding the automatic syncing, which OLE ensures in the
communication between VB-Threads - in the same way as
you have more efforts with your selfwritten sync-code in
..NET, you have to put some lines of code into the Thread,
to ensure the async-behaviour.

In .NET, the asyn calling comes "for free" - and you have to
be careful with shared resources and with Events, raised back
into your GUI-thread.

In VB5/6 you have synced Events and synced MethodCalls
(against shared resources) for free, no extra-GUI-syncing
is needed - but you will have to write some lines for the async
triggering.

Why would the *user* of a threadhelper-lib feel the
need, to debug the threadhelper-lib?
That's as if you would say - .NET would not allow
Thread-Debugging, because the helper-lib (kernel32)
does not offer me the sourcecode for the CreateThread-
Call-implementation. You simply rely on, that this call
works as it should.

That's what Demos are written for - especially for the threading-
topic, where IMO everybody was starting with something
like a "base-example" as Demo-Source.

As said, marhsalling is only *one* way to talk with VB-Threads -
it's the easiest way, the native way of VB - usually implying,
to be able to use automatically synced calls.
You can work with anything that is able to crosstalk between
threads or processes if you want to go there - you are not
limited to the OLE-synced marshalling (or to pipe-based
marshalling as in my helper-demos).

The syncing-APIs are available in Kernel32.dll.
And they are dead-easy to note - as e.g.:
EnterCriticalSection CS
    'place your to be synchronized VB6-CodePart here
LeaveCriticalSection CS

Usually .NET-dependent languages are *not* used for
well-build VB5/6 Threadhelper-libs, no - there's no
need to introduce such a huge dependency, just to
have a class-wrapper around the kernel32-locking-calls.

Can be debugged properly, see Wolfgangs following
examples.

You can even debug a VB5/6 Activex.dll (hosting your
ThreadClass), properly in a second Thread, if you
start a separate VB-Project for your COM-dll for
debugging and press the Play-Button.

That would be Cross-Process debugging - but
since OLE-Marshalling (or Pipe-Based marshalling)
works in the same transparent way as InProcess (passing
ThreadBoundaries in that case, not process-boundaries),
you can test your scenario against truly decoupled Threads
then.

As already told above - the same documentation applies
as with "ActiveX.exe out-of-process-threading", the
only difference is with the CreateObject-Call instead
of New.

OLE ensures *complete* and correct Auto-syncing.
In case you want to have locking *on top* of that automatism,
you can go there any time (Critical Sections are only
two wrapping lines of code that have to be typed/inserted).

You already stated that misleading information above.

Yeah - one line of code.


Losing the parallelism-context in either way, as soon
as you put breakpoints into your thread-code -
no larger difference to OutOfProcess-Debugging
within two separate IDE-Instances in VB-Classic.

Same with VB-Classic, if you use two separate IDE-
instances for debugging.

Same with VB6, only that you work with kernel32.dll
directly - the usual API-calls are "cheap" to declare
and use, usually with the same "one-line-of-code" you
will use them in .NET too.

Yep - since VB5/6 has a different threading-*concept* (a
bullet-prove "VBish" one), which is safer to use out of the Box
(e.g. synchronizing is handled automatically), such free threading
is not allowed directly.
VB wants to see a Class-Instance *on* a thread - not only
a (lightweight) Thread-Function, entered over CreateThread -
that's the main-difference.
You will have to ensure a COM-Object whilst entering your
ThradCallback as the very same action within that Function.

After that, you are free to use any communication-channel you
want - also shared memory access for Array-Variables is
possible - also all the usual locking-calls from kernel32
are possible, to prevent such shared Mem-Resources from
concurrent (over-)writing - or to synchronize your Thread-
Actions yourselfes, in case you don't want the "safe-mode"
per (OLE-)marshalling.


Same holds true for the offical ActiveX.exe based way of
threading. And for your selfwritten low-level-threads you
can read the WinAPI-documentation on how to lock,
allocate and create shared memory, etc.

We don't have such things in VB-Threading - cycle-refs
(if there are any) are caused by the programmer, they
are not inherent in VB-Classic threading-solutions.

Also not for VB6 - but in the most implementations, you
*should* use that mechanism - it is a nice and comfortable
way to talk with a thread (you talk with an Object - in
the very same way as you talk with an Object which does
not run on a thread - and that fully auto-synchronized - no
extra lines of (sync-)code needed, as for example .NET
requires you, when raising Thread-Events back into
your GUI-thread.

VB5/6 threading-solutions perform in a similar way to
a .NET-implementation ... after all they are compiled
with a native C-compiler. And now don't come up
with your "marshalling-performance" again - as already
said, a thread works best, if he's left alone for some time,
without constant and high-frequent stressing on the
communication-channel.

VB5/6 is better here IMO, since the marshalled Auto-
Synchronizing is a feature that is useful (not only for starters).

As said, all possible in the same way per two separate
Debugging-instances of the VB-IDE.

In what way?

Yeah, sure - then look at that here for example:
http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework/topic20488.aspx

To wire up a base-model for a concrete thread-scenario (and
I don't mean a simple, threaded Ping), you probably need about
the same lines of code maybe 10 lines more in VB-Classic,
since your Thread-Implementation needs to be hosted in a
separate Class.

If you later on Fill and Debug that class with your concrete
implementation, then these differences become even more
negligible.

Threading (meaning, *concrete implementations*) is never as
easy as cake - whatever the languages will be - it needs
experience in whatever world you develop such solutions -
threading often is a beast - one should try to avoid it.

These two perform roughly the same.

Exactly - now you got it.

And passing large amounts of (copies of shared-) data over
method-parameters can be avoided, if you just pass the pointers
to reserved (buffer-)memory - and work with dedicated,
separate syncing-calls against these areas, in the same way as
with each other language, by using the calls from kernel32.
Nothing holds you back in VB-Classic, to do so (on top
of these "safe-marshalled calls" VB-Classic has to offer).

Olaf

Show quote Hide quote Wolfgang said he woudl talk about the performance, robustness, developer
costs and other issues.  He has run away on those issues. He has ignored the
very real issues abotu the lack of true debuggign.


Again, as I said when Wolfgang first posted that, that's your twist on what
I said.  My post to which you are replying clearly lays out different
approaches.


"some" ??   That's an understatement.



Was it ?  why then has he denied the issues about debugging ?  I thnk
Wolfgang's entire approach was one of let's twist what Bill says and see if
we can trip him up.  And this is highlighted by his unwillingness to discuss
the *REAL* issues.  He said he would, then ran away.  Why is that ?




No, you will find farious sampels and documents on using and debuggin out of
process. The same documentation does NOT apply to in process.


Hello ???  A I said, no real contorl.  You don't have control over it.
But hey, let me guess you are goign to twist that for some twenty posts ??


you need to keep the object alive and it needs to be able to notify the
original code.  That's a circular reference.



What part of "common pattern" don't you get ?




Show quoteHide quoteOMG.  you can't still be claiming it can be debugged.  Seriously, I'm ending
this conversation with you now as I can see you really aren't going to
discuss this honestly. Wolfgagn's exampels actually show it can't be
debugged. HTH's.

Maybe he was busy at the weekend - so I took over -
where's the problem - you want a technical discussion -
then just reply appropriately.

....and as I wrote in my last post - there are no issues with
debugging - again a wrong statement from your side in that
group.

In that post you finally repeated all my corrections, posted
to you over the last week... LOL.
No - I'm referring to your wrong statements over about 7
posts or so before, where you denied, that InProcess-Threading
is possible at all in VB-Classic - here come some extracts,
just to remind you:

1. "VB classic does not provide true multi threading...

2. "Firing up multiple processes  running on their own single
     threads is not the same as multi threading..."

3. "You can stomp your feet when you say that, but it still
     doens't make your claim true.  VB6 does not provide
     true multi threading..."

4. "Funny how your code is reliant on extenral libraries to
    do the threading..."

5. "Sure it can be done, but it is "out of process", ...

6. "Which as has been told to you, and as the MSDN
     documetnation states, is "out of process" communication.
     That's not "real" threading

7. "first by claiming I said "multi processing" when in fact I
    said "out of process"

8. "What I said was a VB6 app can do threading using
     activex.exe but that is out of process.  I believe that is
     in fact a fact.  Do you dispute it ?


Think, that should be enough as a reminder.


Again, where's your problem?
Wolgang took his time, to just show up an example, that
lists different ThreadIDs in one single, standalone Application-
process.

And that worked already in his first version - should have
been proof enough for you.


Of course it was - how often do you want to hear that - it
demonstrated InProcess-Threading already in its first incarnation,
then you were focussing on blaming others code, just starting
your usual topic-switching tactics.

There are no debugging issues - how often do I have
to tell you that.
You can debug a standalone Activex.exe-project in the
same *.vbp, but that will use the threadclass then in the
same IDE-Debugging-Thread as the Main-App.

Or you can test your ThreadClass under concurrency-
conditions, when you run it either in a Activex.dll-project -
or in a separate Activex.exe-project.


LOL - from the 8 quoted statements above, you should
at least admit, that there was no twisting - you're talking
bullsh*t here and Wolfgang just addressed that with a small
Demo.

Sorry to say, but you behaved like an a***hole with him,
no wonder he has no further interest in discussion with you.

Because you are just an ignorant troublemaker perhaps?

Show quoteHide quoteOf course it does - the only difference is (and I already told
you that) - that you will have to use CreateObject instead
of New - the rest is the same. And you were also already
told, that InProcess-Activex.exe-debugging in the same
IDE is only there for Class-Validation - if you want to debug
in a parallel-context, you can start just another, second IDE
and debug your ThreadClass in parallel.

Of course you have control over it - if you want lowered
control than the auto-synced behaviour, then just use another
communication-channel - if you want additional locks on top
of OLE-marshalling - then just add additional locks.

No Bill - I will just fix all your mess you spit into that group
until you post things that are not wrong and misleading.


No, an Object that wants to stay alive, only needs a variable
where it is stored, not a cycle-reference.

Again you demonstrate your enormous COM-skills here.


Only because you declare something as "common", it does
not have to be common in reality Bill - what part don't
*you* get? You know nothing about VB-Classic-Threads,
why should you know for sure, what is common and what
not?


Because it can Bill - please don't post such wrong statements
over and over again.

Huh - running away now...?
Thought you want a technical discussion - and I can
only repeat, that Debugging is possible.

Yet trying to blame version Nr.1 of his Demo Bill?


Olaf

Correct when referring to VB6.

Correct.


Correct.


Again also true.


Well you've *deliberately snipped that sentence in half.  Looks like oyu are
hiding/twisting somehting.  If we are talking abotu using an activex.exe
from a main app, that statement is also true.


Again correct when referring to using an activex.exe.  Did you see anywhere
where I said that an application compiled as a stand alone activex.exe is
out of process ?? Huh ?? Anywhere ??  Nope.


Correct.


Again that statement is absolutely true.  Look at the Coffee Pot examples
etc in msdn.


The applciation was shocking. Why do you feel the need to rehash over it ?
First it use properties on the desktop window, an absoltue terrible hack.
Next, when run from the IDE it attempted to spawn threads which never called
back, so the collection was never emptied.... lost object references, and
given his query unload code, the applciation couldn't close, had to be
forced to be closed.  And then it couldn't be run again due ot the setting
of the desktop window property.



Nope. He didn't even take the time to say it can't be run from the IDE.
Later he admitted that, you know are trying to argue that you can debug it.
Unbelievable really.


Proof of what ?  That it can't be debugged properly ?  Sure it was, I even
said so.


What absolute dishonesty.


Gee whiz, that last case would be out of process, and as for activex.dll you
ain't goign to get threading there.  And these of coruse require completely
different project initialization.  So the only real debugging is as per my
lsit as a seperate ActiveX.exe  called fro mthe main exe (aka out of
process)  I already spelt that out in my summary sayign you coudl debug
that, but that is nto a standalone activex.exe as you well know I'm sure.

Bill McCarthy wrote:
Incorrect, as the posted documentation quote attested, and as other samples have
shown.

And let's not bother getting into the definition of True, shall we?  That's where we
parted ways initially, as you likely recall.  If you feel the absolute need to call
CreateThread, go, do it.  Somewhere else.  That's an Off-Topic discussion for this
group.

WTF, man?  You're just flat-out wrong on this point, and spinning circles is only
digging the hole deeper.  What a sad little spectacle you're making here...

On Tue, 23 Jun 2009 12:36:19 +0200, Schmidt wrote:

Ummm ... well, yes, but there's nothing special with that. It's actually
quite normal for him, maybe this time it was just a bit more obvious
than usual ... anyway, don't worry about me, there's a certain reason
why it looks like I hardly defended (and defend) myself.

I was well aware of Mr. McCarthy's agenda before, and I was well
prepared for what was to be expected.

The fact that it took him days to finally notice - accurately hidden in
lots of palaver - that contrary to his claim VB6 AX executables *can* do
in-process threading once again demonstrated that he has no interest at
all in technical discussions, all he's in here for is indoctrination and
manipulation.

He's pretty good at that, very professional. Just like most politicians
or lobbyists in TV talkshows, for instance. Moderators usually have a
damn hard time to make them answer a specific question cause they are
perfectly trained for telling you a lot of stories that sound convincing
but their only purpose is to obfuscate that they can't or don't want to
answer the question asked. This kind of propaganda comprehends a lot of
dirty tricks regarding how to deal with those who disagree with them, 
like mocking, switching topics, intentional misunderstandings, avoiding
concessions at all cost, exploiting any concession of the opponent,
dumbfounding the opponent by audacity, provocations, intimidation and so
on.

It's pretty hard to deal with these persons, they sound really
convincing on superficial inspection, but on closer inspection you
quickly notice that they aren't interested in truth at all but only in
propaganda effects. Your only chance is to concentrate on one point and
ask the same question over and over again. You got to be prepared that
they'll become really nasty at this point, they will use all their
tricks to sidetrack from the fact that they are in a precarious
position. They'll make you look silly in order to provoke your emotional
reactions which will make it only easier for them to ridicule you. One
reliable way to accomplish this is outrageous behaviour while they
accuse *you* of exactly that - it's almost guaranteed you'll explode
sooner or later, and dang, they'll have you in the position desired. The
slightest mistake you ever made will be cited over and over again no
matter that it's been corrected long ago (I'm not saying I built in the
well-known flaw in my example on purpose but accidentially it fitted
perfectly into the picture). They'll "misunderstand" all and everything
you said in order to keep you busy with throwing light on the
"misunderstandings". They'll constantly try to switch to topics they
believe they are better prepared for - as soon as they fail there also
they'll switch again. They'll exaggerate all and everything you said in
order to mock you. Your slightest concession will be reinterpreted as
your admission of complete failure.

In short: they'll constantly try to keep you busy with anything else but
the delicate point.

It's hard, but your only chance: don't let yourself distract, whatever
they try. And they try almost everything.

It's all documented in his recent posts. For future reference, for
everyone to see. It's out there and cannot be removed.

Bill is indeed very professional. Not regarding technical issues,
obviously, but regarding indoctrination and manipulation. Just like,
say, Colin Powell, former US Secretary of State, who also was very
professional in that sense when he presented "proof" for Iraq's weapons
of mass destruction in the UN plenum. He knew it was a lie, the whole
world knew that, but nevertheless he was "professional". Today he is man
enough to confess that this was the biggest mistake in his life. Others
need more time for something like that, and for some of them their
life's time isn't enough. We'll have to keep dealing with them.

Show quote Hide quote Seems you just forgot one major reason for him to post. Getting MVP-points
for posting in NG's. I guess he really needs those...

/Henning

Hi Wolfgang,


Show quoteHide quoteI think that says it all really. You entered into the discussion expecting
not to discuss things technically.  And despite your promise of doing so,
you high tailed out of the conversation with a "bye" rather than discuss the
real issues. I listed a summary of the different approaches to threading and
some of the issues with them, and all you've added is this lengthy ad
hominem.    QED.






Show quoteHide quote

LMAO!!!  When Bill starts misspelling every other word (cause hes trying to
type wityh his fists), you know you've got her.

Show quoteHide quote

On Tue, 23 Jun 2009 12:30:06 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

[my reply doesn't seem to get trough as-is, so apply ROT13 for the
following to read ...}

Qb lbh ernyyl guvax V'z vagrerfgrq va fbzrguvat yvxr gung jura - nf unf
orra qrzbafgengrq - vg gnxrf *qnlf* gb chyy gur fvzcyr snpg bhg bs lbhe
abfr gung gurer vf ab frpbaq cebprff? N snpg gung rirelbar jub sverf hc
uvf Gnfxznantre pna frr *jvguva frpbaqf*? Pyrneyl abg. Gung fher nva'g
fbzrguvat gb cebsvg sebz, gung'f n jnfgr bs gvzr. Sbe vafgnapr, V fnvq
gung V "cebonoyl qba'g xabj rabhtu" nobhg znefunyyvat (juvpu, bs pbhefr,
vafgnagyl gevttrerq lbhe fgngrzrag "Lbh gbyq zr orsber lbh qvqa'g xabj
nobhg gur znefunyyvat"); frr, jvgu n frevbhf qvfphffvba cnegare, V jbhyq
frr n punapr gb yrnea zber nobhg vg, ohg lbh - abg sbe gur svefg gvzr,
ohg rira zber pyrneyl guna hfhny - qrzbafgengrq gung lbh cersre gb
zvfyrnq crbcyr ng nyy pbfg. Qb lbh ernyyl guvax gung'f jung V'z ybbxvat
sbe: orvat zvfyrq? Qb lbh ernyyl guvax V jbhyq pbafvqre lbh n eryvnoyr
fbhepr bs vasbezngvba?

Ab, Ovyy, gunaxf. Gur bayl cebsvg V znqr sebz guvf "qvfphffvba" jvgu lbh
jnf gung vg pyrneyl pbasvezrq zl rneyvre bofreingvbaf - urer jvgu lbh,
va cbyvgvpf, va rpbabzvpf naq - lrnu, pnyy zr n pbafcvengvba gurbevfg,
ohg vg'f gehr - ba gur Trezna IO Pynffvp arjftebhc. Lbh ner abg gur
bayl bar, gung'f sbe fher.

V frr lbh ner n "Zvpebfbsg Zbfg Inyhnoyr Cebsrffvbany". Pbafvqrerq
fnepnfgvpnyyl, gung'f na npphengr qrfpevcgvba sbe lbhe npgvat, gubhtu vg
nznmrf zr jung n qvssrerag zrnavat guvf gvgyr unq va rneyvre lrnef.

Vs lbh guvax lbh qb ZFSG n snibhe, naq ZFSG guvaxf fb, pneel ba ...

LOL, ok seems you get it now (after a few days finally).
Wolfgangs example was built, to only show exactly that -
nothing more.

No - it is not - and in the same way as the above InProcess-
threading, which VB is capable of ... the marshalling-topic
now seems another one, you have not the slightest clue about.

I already tried to point that out to you in two of my replies,
but you failed to answer my last one.

Again - in most threading-scenarios there is no measurable
overhead - the kind of long-running jobs as in Wolfgangs
example, have an Overhead-relation of 0.1msec, compared
to worker-jobs which run in the 1000msec to 10000msec-
range.

Even if you have to trigger only a job of 100msec, the overhead
would be in the pro-mille-range.

No, you said, that VB cannot do InProcess-Threading, which
is utterly wrong. "From an app" is also unprecise ... if it is the
same app, then the created worker-threads run *InProcess*.


So, you are delivering your solution not as compiled Binary to
your customer? Oh I forgot, .NET-solutions always are delivered
as Source-Code, right?

The only big issue I see here, is that you don't even get the simplest
things in line, twisting topics as soon as you lose ground.

You can debug your Thread-*Class* inside the IDE and ensure,
that it works right.
If it works right, then the Class-Code will also work right inside
the Binary (in real threaded mode).
As soon as you set a breakpoint in a thread, you gain nothing
regarding discovering potential concurrency- or parallelism-
issues, since you loose the "parallel context" (the "parallel state")
of your thread-model in that case immediately, also in .NET.

There is no performance-issue, as I already told you over and
over again. Please come up with an example, that clearly
demonstrates a scenario, where VB will have a "performance-
issue" with threading-stuff.

....which you know nothing about - just read my replies to
you again.

That's the whole purpose of the OLE-interthread-marshaling -
deadlocks are just not possible - in .NET you are on your
own, to ensure that this does not happen - Did you notice,
how Wolfgang is able, to just Raise Events from the Worker-
Threads into the GUI, to refresh a List-Control?
In .NET you will have to synchronize to the GUI-Main-
Thread first explicitely, to be able  to access your Winforms-
GUI in a safe way.

Where is the problem with "queued synchronization"?
the OLE-marshalling model can ensure that too already.

If you think it does not, then write a .NET example for
queued synchronization too - I will show you the VB6-
counterpart then.

As I see it, you are the only one who sees "issues" where
no such things exists.
I can only encourage you, to write a small .NET-Threading-
example, which demonstrates all these "issues", VB-Classic
in your opinion has (regarding threads). Should be no problem
for someone with that huge threading-experience - I mean you
The above statements don't require an answer - the way
VBs OLE-marshalling works, ensures that nothing of the
above will "hit you", in case you use the VB-threading-
support in the intended way.

Come on Bill - now it's your turn - Wolgang already wrote
a small example, to show you, that InProcess-Threading-
is available and working in VB-Classic.
Now it's your turn, to come up with code, to prove "your real
issues" ... but be careful - please use only the very best coding-
practises in your demo, because I will blame .NETs threading
capabilities if *you* only make the slightest mistake (so, check
your TabWidth too - I prefer 2 spaces indentation - everything
else would be considered as bad threading capabilities in .NET).

Get a life...

Olaf

Bill McCarthy wrote:
Wow, so just to be clear, you're accustomed to running and debugging compiled code
in the IDE?  For a guy who says he doesn't have time to waste, your actions are
certainly demonstrating otherwise.

All the time I'm wondering how you'll try to get out of this desaster,
and on second read, I have to say I missed this part before ...

Where? When?

This last sentence is a true one, finally. But since when is a
standalone AX EXE not a standard use? Can you show me any reference for
this?

Both forms - standalone as well as external AX EXE projects - run
properly in the IDE, they are only single-threaded then. There's nothing
new, and there's no difference.


Oh, and since we're at it:

Show quoteHide quoteI *am* well aware of that. But that does not change any bit of the fact
that your - ahem - problem analysis ("changed object references") was a
big desaster.

Show quote Hide quote The greatest evidence of this is your own code.  Your code set a property on
the desktop window to decide whether or not to show the main form.  that
*hack* of yours resutls in people having to restart their computer should
your app crash or be terminated.  This is the same code you've said you've
been using since VB5.  Prety hard to beleive you would distribute such a
thing.

The standard use, as is **documented** with VB6 is to have your application
use an activex.exe, not be compiled as one.  I doubt very much your hack to
stop the form being shown as each object is created is anywhere in the
documentation.  And, I think you'll find msot businesses/developers want to
actually be able to debug their code.




Huh ?  your code does NOT run properly in the IDE.  Don't pretend otherwise.

As you may already have noticed, I will no longer respond to your word
twisting before you answered two simple questions: where is the second
process, and why does the thread count of MTAX.exe increase.

Just one thing:

Presumably this "misunderstanding" is intentional, but just in case it
is not: I never said I used this code since VB5. I said I wrote it in
VB5, one week ago:

********
From: Wolfgang Enzinger <usenet200***@temporaryforwarding.com>
Date: Sat, 13 Jun 2009 22:23:30 +0200
Message-ID: <f918351ip10mq925tkv2s331ncioam2***@4ax.com>

I'm with Olaf, last but not least because I just made I tiny, working
example (in VB5, BTW, without any hacks).
********

You know the meaning of the word "just", don't you?

Show quote Hide quote I was referring to where you said :

Calm down, Mr. McCarthy. I never said it's perfect in the IDE. Keep in
mind it's ten year old. In fact I wrote the code in VB5 which is twelve
years old.
-----------------------


So seems you are now telling yet another un-truth.  Which is it ?  "Just" as
you now claim, or "ten years" ago as you previously claimed ?

Any *intentional* mis-understanding is yet again your doing.

On Mon, 22 Jun 2009 03:00:49 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

I see I was unclear there, should've written

Yeah, yet another un-truth. Get a life, McCarthy.

Your audacity is admirable, I have to admit.

Hi Wolfgang,

Show quoteHide quoteWell you should have also said to yourself to calm down.  That post, the one
in issue was when you fired off three posts in reply to my single post.
From your actions, it seemed you needed to calm down before sending, then
projected that at me, saying that I needed to.  I actually got a laugh from
it, but in reality it's the kind of rhetoric that isn't needed.  IF you had
of taken pause, we wouldn't be wasting bandwidth on your then later
accusation, and then later retraction.



Yeh sorry about that.  I responded to your accusations of "twisting" and how
you said it was an "intentional misunderstanding" on my part. You above
admission has cleared that.  I shouldn't have let myself get lowered into
the ad hominems just because you keep baiting with them. My bad.



Wow.  Given it was the fault with what you wrote, given it was in fact you
who said "intentional misunderstanding", shouldn't you just be apologizing
for what was your fault ?

I cannot believe you guys are all still firing cannons at each other
here.....  :=)

I have not even got around to finishing my .NET example service, yet, due to
other business.  After all this stuff, I really don't know who to believe
AFA doing a service in VB6.

I used to write VBA-based Access front-ends for c/s apps on various backend
data sources (mainly BTrieve and Oracle), and I got in many forum wars over
various issues just like this one.....  I miss the fun....  :=)

Chill out, guys.....  may the Force be with you.....

Show quoteHide quote

Pete B wrote:
Probably wise to keep one statement in mind...

Kinda says it all, especially given the tenacity of the assertions being thrown
around.  On the one hand, you have regulars here who use the product day-in and
day-out.  On the other, you have folks who haven't used in "many years" who hang out
here mainly to...

Pete B wrote:
"Not that there's anything wrong with that."  As long as innocent bystanders
understand who's just here to have fun causing trouble.

Hi Pete,

the "conversation" has drifted far away from services in VB6.  Instead the
focus seems to be on attack the .NET guy <g> Wolfgang's code showing an
application compiled as an activex.exe (as opposed to using one from a
separate exe), actually highlights the issues I raised about the road well
travelled, or in this case not.  Not only can't it be debugged properly, but
his first sample would require you to restart windows if it crashed. For a
windows Service, that would be shocking behavior... "sorry everyone we have
to shut the entire server down so as we can restart this one service".   In
terms of windows services, I think when Microsoft says don't do it, then you
really do risk indemnity/professional negligence issues.
http://support.microsoft.com/kb/q175948

<quote href="http://support.microsoft.com/kb/q175948">
Microsoft does not currently recommend, and does not support, running Visual
Basic applications as Microsoft Windows NT, Windows 2000 and Windows XP
Services because the applications may exhibit unstable behavior when
installed and run as Microsoft Windows Services.
</quote>

I think it doesn't get much clearer than that.





Show quoteHide quote

No Bill, the focus is, to cleanup all the mess and wrong
statements, the .NET-guy is posting intentionally, just to
spread FUD within this group - think I already posted
a link to the definition of FUD - and what ".NET-guy"
is doing here is exactly that - blaming capabilites of the
yet widely used concurrent product, to marketeer the
new one - and that mess is going on for months now,
forcing constant cleanup after his misleading statements
from the regulars here.


Of course that is another wrong statement...

Yeah - his first example ... LOL - his first example already
proved InProcess-Threading, now you are apparently on
the Debugging-trip - and make wrong claims also there.

Ah - here again the famous "McCarthy topic-twister" ... just
stunning, isn't it?

Billy, the InProcess-threading-capabilities of an Activex.exe
have nothing to do with a VB-Classic-Service implementation,
do they? I'd suggest, to study the examples with the NTSvc.ocx
or on Sergey Merzlikins site ... I've already posted a link.

And when "Microsoft says" something, they are always right, yes?
As said, Sergej Merzlikins code-modules work fine here
in combination with my RPC-services,  implemented
completely within VB-Classic - and that apparently works
stable on all the different OS-versions I've already posted -
and the RPC-services do concrete stuff in their workerthreads -
this is no small service-demo anymore as Sergeys initial code.

Offering also the options, to register and deregister the service
directly from within the Service-Controller-App - no
Setup needed, everything is running regfree.


nonetheless a whole lot of developers are not interested.

Well, if MS had no support-intentions, then why on earth were
they developing and providing the NTSvc.ocx for VB-Classic?


Olaf

Yes thanks for pointing that out.  The above article was in reference to
VB4,5 & 6 not VB.NET. The article actually says that, but for those that
didn't read it, I'm glad you pointed that out.  Thanks :)

For someone who professes to dislike VB6 so much you seem to spend an awful
lot of time on the VB6 newsgroup, McCarthy. In contrast you spend virtually
no time at all on the VB.Net group, the product you profess to like so much,
and you hardly ever make any posts there. In fact as far as the VB.Net group
is concerned you are about as useful as a chocolate tea pot! Are your
Microsoft MVP puppet handlers still banning you from posting to the VB.Net
group? Are you as hated there as you are here?

You really are a disgusting little troglodyte McCarthy and your continued
deliberate harassment of the members of the Classic VB newsgroup is not the
kind of behaviour that one would expect from a Microsoft MVP. You are a
disgrace to Microsoft, McCarthy, and a disgrace to yourself. If Microsoft
had any sense they would sack you immediately and revoke your MVP status for
ever.

Mike

Oh no, changing your posting name and email address.  BTW: Oz.com is an
actual domain, so you know you are breaking the law by claiming you have an
email there.  That's fraud laddy.

I don't dislike VB6, in fact I love it, always have always will.  Just like
I have fondness for old Volkswagens.  But I'm not blind to it's faults, and
I also recognize that VB.NET is technically superior.  HTH's :)

.. . . so is TPASoft.com

No, that's not breaking the law.

No it is NOT fraud, dick brain! You know SFA about the law! But you ARE
breaking the law by spreading wilfully damaging and and thoroughly nasty
lies about TPASoft.

You are an idiot, McCarthy, and a very nasty idiot at that. Microsoft should
revoke your MVP status immediately. You are a disgrace to the Microsoft MVP
program and a disgrace to yourself. The fact that the Microsoft MVP people
appear to condone what you do on one of their own news servers says a lot
about them! You deserve each other!

Mike

Always wondered the same thing about his MVP status, but I suppose the fact
that he's still here is because his real job is to evangelize .NET.  Too bad
his posts have the opposite effect though :(

Yeah Bill, assuming someone elses trademark is against the law as well.  But
you already know this.  Or soon will.

Show quoteHide quote

Bill McCarthy wrote:
When Storage and Curland did it for VBPJ, they called it "Black Belt" -- HTH!

On Fri, 19 Jun 2009 18:31:37 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

[Olaf]
It's even easier than *I* thought, no more need to touch any desktop
window properties (thanks Olaf) that you apparently are so afraid of ...

http://www.enzinger.net/archives/MTAX5.zip

The remaining two API declares are only needed for demonstration
purposes and have nothing to do with threading. BTW, the use of ObjPtr()
is also for demonstration purposes only, I wonder why you thought that
my code "changes object references and hence looses events" ... *lol*

Expecting your comments ... or not.

Again my reply was not going through the NG-Filter...

but it's only the usual cleanup after misleading statements.

www.datenhaus.de/Downloads/Re-Walkthrough_Instruction_Error.txt

Olaf

Bill McCarthy wrote:
I guess it's always easier to cry that someone's calling you names than to address
specific technical points?  Over here, we call that "having a hissy fit" -- what do
they call it there?

fit" -- what do
They call it OZ's version of McCarthyism.

I'm using successfully the code of Sergey Merzlikin in my
Server-apps.
http://www.smsoft.ru/en/ntservice.htm

Needs a bit, to fully understand what he's doing there, but
it works flawlessly in W2K3, Win2008-server, and on
the desktop-systems W2K, XP, Vista.

On the site above.
He also mentions the NTSvc.ocx, which is also available for
VB6 - but there are other sites, which explain the usage of that
OCX better (should you be interested in that somewhat more
"comfortable" approach, which adds a dependency though).

The link above provides you with just that - the comments
in the code are Ok too - you should be able, to find your
way through all that.

Olaf

vb memory layout
Re: Multithreading
Multithreading
Vista SP2 Being "offered"
dhRichClient3 Thread Classes Issues
VB6 on Vista Home Premium problem
Excel Execution from VB Fails on 2nd Attempt
Use an Addin to automatically add date/time stamp to each edited line of VB6 code?
Moving .exe somtimes works
In High Density Mode - Looking for previous control counting post