Printable View
It wasn't just the boolean it was any module public variable having a value set to it by one of the forms.Quote:
Originally Posted by Niya
Is there any other object other than excel that I could test this with to see if it's excel or if it's any object?
I didn't think much of this question, at first, but it turned out to be a pretty interesting exercise.
What version of Excel are you working with? I know that there have been some fairly significant internal changes to Excel over the versions. I used to be able to cause a very interesting crash at will in versions up to 2007, but then that odd feature was changed. Therefore, there is no guarantee that this very interesting behavior may have gone away in newer versions of Excel, or may not exist in older versions....or not. The only reason anybody might test it is that Late Binding would allow you to use whatever version of Excel happened to be on the computer in question, so if the behavior was different for different versions of Excel, you'd never be sure what was going to happen on any particular computer.
So, what is happening? We'll probably never know for sure. I tried to think up a way you could do the same thing by adding an object and locking on it, but that wasn't quite what you described. Even the UI thread would wait on such a lock. Clearly, the UI thread was acquiring the lock, since it blocked the progress of all the other threads for some time, but then the lock was released and all threads went forwards at once. My design would have them all take turns, which is not what you reported. It is acting kind of like a semaphore that changes its count from 1 to infinite after some action occurs. It's as if a lock is in place that allows only the UI thread in during some kind of initialization, but when that initialization is over, then ANYBODY is allowed in, and all at once.
However, if that were the case, then I would expect the lock to only exist during the Create call, which happens before the program starts, since it is a global shared variable.
One further test you might try is to leave the xl variable, but remove the call to CreateApp (or whatever it is). Instead, make that call in the Form Load event, or even in the button click just prior to starting any of the threads. The xl variable is just a four byte chunk of memory with nothing in it. The Create call creates an object and puts the address into the xl variable. Therefore, until the Create call is made, xl is nothing (or Nothing, actually). Since you have the Create call in the module, and since all members of a module are Shared, then the Create call actually happens prior to the first line of the hidden Sub Main where the program starts. This is because all shared variables have to exist before the program starts so that they are available right away. Since you use the Create call to initialize xl, then that also happens right off. If that is locking something, then moving the call out of the module, and filling xl at a later time, may impact the behavior.
Of course, it's just pure speculation at that point.
In any case, it's been an interesting thread.
It isn't ANY object, because I used a List (of String), which is also an object, and nothing happened. Of course, you could test with Word, but what would that really show if one Office product behaved the same or different from another? I can't think of a good, non-MS, alternative that would be suitable for such a test.Quote:
Originally Posted by iamcpc