This was amazing. I was thinking of an alternative way of doing some sort of multithreading by simply creating many instances of the Office application controlled by a main instance that would monitor the progress made by those instances. Obviously there would be no variables/arrays that could be shared, so the buffer would have to be different files. This means that it would only be useful for really computationally intensive task, but that would still be a possibility and perhaps more stable than real multithreading.
Shared variables are a major source of error or contention. So, that is a minor issue. However, staring a new process is a very slow and resource intensive operation. IMO this approach would only be sensible if you got multiple very long running tasks to process.
I haven't tried the code on x64. It might generally not work on that platform. As said in the video: Don't use this for a productive application. It is just a theoretical proof of concept.
Appears to be using the MZ-Tools addin, never used it myself thou aware of it. It's a paid VBA tool can use for productivity see www.mztools.com/ I use the Rubberduck addin at rubberduckvba.com/ which is a free VBA productivity tool which has many great productivity features. The features I like the most are the folder annotations to help manage and organize large projects and the unit testing. The code explorer is also valuable for consistent coding standards with various warnings.
Great video. Still in the process of watching it and will probably require to rewatch a couple of times to fully understand. After watching a couple of times extremely interesting. Curious to why it failed to work on Access 2016, did you attempt to find a solution to the issue on StackOverflow? Regarding CoInitializeEx() www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa might shed some light. I'm still attempting to fully understand the article. Possible reasons why crashing stackoverflow.com/questions/2653797/why-does-couninitialize-cause-an-error-on-exit and devblogs.microsoft.com/oldnewthing/?p=39243 might help. Or possibly incorrect API declarations when translating to 64Bit. docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread is the handle returned a longPtr? Also for Dim encodedBuffer As String For threadIndex = 0 To THREAD_COUNT - 1 encodedBuffer = encodedBuffer & outputbuffer(threadIndex) Next threadIndex Off the top my head I'm fairly sure could use a Join function on the string array to a string that will have improved performance.
Thanks a lot for all those links. I will go through them once I find the time. However, I don't think they will change my overall recommendation not to use this in any real-world application. The implications and threats to application stability are to serious.
Regarding RubberduckVba: I tried it multiple times but it keeps hanging and crashing on me. I reported some of the issues on their bugtracker, but I don't think they are fixed yet. I love their ideas though and evaluate it again in the future.
Thank you. I will provide 64bit compatible code for future videos. I will not update the code of this example because I think it is of little practical value.
Yes. It is not recommended to distribute it to your client's end user. But it is very very helpfull for the everydays IT backoffice jobs.
This was amazing. I was thinking of an alternative way of doing some sort of multithreading by simply creating many instances of the Office application controlled by a main instance that would monitor the progress made by those instances. Obviously there would be no variables/arrays that could be shared, so the buffer would have to be different files. This means that it would only be useful for really computationally intensive task, but that would still be a possibility and perhaps more stable than real multithreading.
Shared variables are a major source of error or contention. So, that is a minor issue. However, staring a new process is a very slow and resource intensive operation. IMO this approach would only be sensible if you got multiple very long running tasks to process.
This was a very informative watch. Thank you.
is the reason of crash that you are using waitforsingleobject? It will block the main thread until the process is finished?
Very interesting and impressive!
Excellent! Please, tell me, where can I download the library so that I can use and test your example?
Thank you. The download link is in the video description.
Is there a way to port it to x64 platform? I did not succeed in this by simply replacing pointers with longPtr.
I haven't tried the code on x64. It might generally not work on that platform. As said in the video: Don't use this for a productive application. It is just a theoretical proof of concept.
I am quit too fare a way of such high level programming. but I understand it as big step in speed up processes.
Kindly.. What is the add-on do you use to make the VBA more interactive
Sorry, I don't understand. What do you mean by "more interactive"?
Appears to be using the MZ-Tools addin, never used it myself thou aware of it. It's a paid VBA tool can use for productivity see www.mztools.com/
I use the Rubberduck addin at rubberduckvba.com/ which is a free VBA productivity tool which has many great productivity features. The features I like the most are the folder annotations to help manage and organize large projects and the unit testing. The code explorer is also valuable for consistent coding standards with various warnings.
Nicely explained!!!
Great job
bgm is very nice
Great video. Still in the process of watching it and will probably require to rewatch a couple of times to fully understand.
After watching a couple of times extremely interesting. Curious to why it failed to work on Access 2016, did you attempt to find a solution to the issue on StackOverflow?
Regarding CoInitializeEx() www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa might shed some light. I'm still attempting to fully understand the article.
Possible reasons why crashing stackoverflow.com/questions/2653797/why-does-couninitialize-cause-an-error-on-exit and devblogs.microsoft.com/oldnewthing/?p=39243 might help.
Or possibly incorrect API declarations when translating to 64Bit. docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread is the handle returned a longPtr?
Also for
Dim encodedBuffer As String
For threadIndex = 0 To THREAD_COUNT - 1
encodedBuffer = encodedBuffer & outputbuffer(threadIndex)
Next threadIndex
Off the top my head I'm fairly sure could use a Join function on the string array to a string that will have improved performance.
Thanks a lot for all those links.
I will go through them once I find the time.
However, I don't think they will change my overall recommendation not to use this in any real-world application. The implications and threats to application stability are to serious.
Regarding RubberduckVba: I tried it multiple times but it keeps hanging and crashing on me. I reported some of the issues on their bugtracker, but I don't think they are fixed yet.
I love their ideas though and evaluate it again in the future.
Great video! But can you update your code for 64 bit?
Thank you. I will provide 64bit compatible code for future videos. I will not update the code of this example because I think it is of little practical value.
Good video
nice video