SystemOfADown

I have an application with the beginnings of multithread capability (and please, no suggestions to avoid multithreading, I simply can't avoid it or change languages :P)

The program runs fine in the IDE (of course, without multithreading), but once it is compiled (with Thread per Object enabled) the CreateObject calls don't work after the first one. They don't fail, as far as I can tell-I don't get an error message even though all error handling is disabled (I think). Of course, if it weren't disabled, the code should execute fine afterwards (I've just put in a few random messageboxes to keep me apprised of where the program currently is) and it doesn't.

So, no error is thrown but the code basically stops. Sometimes parts of the program will still run and I can attempt it again, but that usually causes a crash, and, in fact, leaving it sitting for a few seconds will cause it to crash after the second createobject call. Again, it is created fine the first time.

The crashes sometimes happen when I just click the exit button in the program (if it isn't frozen), and usually they are something about an automation error.

So, I am confused.
Ideas?

DougT

Sorry, but this is one example of where messing around with multi-threading in VB 'fails'. Others you will experience are the IDE aborting when your program tries to unload itself, the Application aborting (probably with an error like "Couldn't read Memory Address xxxx") and other strange 'random' failures at random times. (Been there, done that, have the T-Shirt)

I'm afraid that just because you don't like an answer / advice, doesn't mean it isn't factual / good advice.

Regards
Doug

SystemOfADown

*cries*

I had seen articles that stated multithreading with ActiveX exes is actually quite stable, so I was hoping that peope were misinformed or perhaps they meant with methods such as the CreateThread API.

Unfortunately, I am past the point of no return on this project, so I cannot afford to go back and change languages.

Part of what amazes me is that it has barely started multithreading when it fails. I could understand there being bugs that show up every so often in random sections when the code starts becoming large and complex, but I would think that something as simple as a createObject call would go off without a hitch, especially when createObject is used in so many applications.

passel

Perhaps you could go back to VB5.
VB5 does multithreading better than VB6.
But even then, there were problems in VB5, so Microsoft made it more difficult to do in VB6 to avoid the problems in VB5.

If you want to read a long and detailed artical about hardships with hardcode programming between VB5 and VB6, this is a very good read.

The VB5 book is available on my copy of the MSDN library that came with VB6. It may be on yours, but as noted, it should be available on-line by permission of the author and publisher as noted in the article. In chapter 11 it has a section on multithreading with VB.

Of course, in the updates found here (search for the word "multithread"), there is a mention that Dan Appleman says the approach used is wrong.
The Dan Appleman article mentioned is found here.

Note that in that article it says "It's a great demonstration of why you should NEVER call the CreateThread API from Visual Basic (any version including VB .NET). If you are looking for background threading in Visual Basic, this article will discuss several safe and reliable approaches for doing so. The CreateThread API is not one of them."

If you insist on doing multithreading, then I would be sure I've read at least the last article.

SystemOfADown

I hope you're not mistaking my use of the CreateObject cal with the CreateThread API...

SystemOfADown

Oddly enough, if I compile the program with a limited thread pool, the createObject call will never complete for the first threads until the thread pool is empty. And new thread creation attempts afterwards end up spawning on the main thread and running fine. Quite annoying....