Results 1 to 30 of 30

Thread: VB6 (ActiveX-Exes and selfhosted Threading)

  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    VB6 (ActiveX-Exes and selfhosted Threading)

    Here's an example for a simple AX-Exe-Threaded-Selfhosting-approach (calculating a Mandelbrot-Set on two worker-threads -
    reflecting the results "row-by-row" in the GUI-MainThread then per normal cross-thread-COM-events).

    The Zip-File here in this link:
    http://vbRichClient.com/Downloads/MBSetAxThreadedV2.zip
    contains version 2 of the demo, whilst the Zip-File at the bottom of this posting (below the ScreenShot) contains the original version.
    (version 2 contains a different Async-Decoupling-approach and a performance-test for Event-based vs. Interface-based Thread-Callbacks)

    Would really like to see a .NET-version which does the same thing in the same performance (just try in the compiled Executable, and not in the IDE for "full-threaded-speed").
    (the VB6-code is a bit rusty, it's already a few years old - but still working as it seems - just put it here as a reference).



    Olaf
    Attached Images Attached Images  
    Attached Files Attached Files
    Last edited by Schmidt; Sep 18th, 2013 at 09:41 AM. Reason: Version 2 added

  2. #2
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Interesting. Though there's something weird I noticed. It doesn't seem to be multi-threaded when ran in the IDE. This can make debugging multi-threaded apps a pain in the ass.
    Last edited by Niya; Sep 3rd, 2013 at 11:08 AM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Niya View Post
    Interesting. Though there's something weird I noticed. It doesn't seem to be multi-threaded when ran in the IDE. This can make debugging multi-threaded apps a pain in the ass.
    Yep - in the IDE the dedicated ThreadClass-instances are created on the Main-Thread instead (when this selfhosted InProcess-approach is used).

    MS deactivates the Threading in the IDE, because the Edit&Continue-Debugger is apparently not thread-safe.

    But this is not really a show-stopper - mainly due to the nice "auto-synchronizing" of COM-Method- and -Event-calls which
    work transparently in this cross-thread-marshalling.

    In VB6 (as long as this COM-Threading approach is used "by the book", as this Demo does) we will never have to explicitely
    code something like .NETs .Invoke ... or use Mutexes, CriticalSections or other Synchronization-primitives due to the automatisms
    and mechanisms which work inherently in the COM-marshalling (well and to be fair, whilst we spare some lines of code with
    regards to thread-synchronizing-efforts, we lose this coding-advantage due to more efforts to *decouple* those by default
    synchronously behaving cross-thread method-calls in an *asynchronous* fashion).

    But over all, the (class-based) COM-Threading (which works with isolated memory-allocators too) is pretty "fool-proof" in its
    usage - and so a thorough testing of the Methods of the ThreadClass (in non-threaded IDE-Mode) is usually enough
    to achieve a stable threading.

    If threading-scenarios get more complex, then it is mainly synchronizing-issues which cause "headaches or a pain in the ass" -
    since the Thread-Worker-Methods can be validated "in themselves" (or in their hosting thread-classes) pretty decently always
    beforehand, no matter what language.

    But as said - the VB6-ActiveX-Exe-threading (and the COM-STAs with their isolated memory) enforce a certain kind
    of "bullet-proofness" mostly due to the built-in auto-synchronizing (at the cost of additional efforts for async-decoupling).

    In case you want to write a .NET-version at some time in the future, I assume that you will end up with roughly the
    same amount of code (especially when you want to achieve the same OverAll-performance also in the GUI-rendering -
    and ensure the same "thoughness" with regards to:
    - stopping the current WorkerThread Mandel-calculation when a new Zoom-Rectangle is drawn (taking over the new Params and Task immediately)
    - not crashing the App, when a WorkerThread-calculation/rendering is in progress and the App is closed (in-between) immediately

    Olaf
    Last edited by Schmidt; Sep 3rd, 2013 at 02:25 PM.

  4. #4
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    You know, with your knowledge you can work miracles in a language like C# or VB.Net.

    I would attempt a VB.Net version out of curiosity, after I wrap my head around Mandelbrot sets.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  5. #5

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Niya View Post
    You know, with your knowledge you can work miracles in a language like C# or VB.Net.
    Much of this knowledge was accumulated due to the fact, that I always tried to avoid "language-hopping" -
    it really helps ones "learning-curve-climbing" along, when you stick with something for a while (more than a decade that is).

    I also doubt, that I would achieve anything "more miraculous" in a different language compared to what I currently can accomplish in VB6.
    I compare the VB6-implementations I encapsulate e.g. in the RichClient-lib with e.g. C/C++ libraries - and so far
    this worked out (mostly) in favour of the VB6-implementation.


    Quote Originally Posted by Niya View Post
    I would attempt a VB.Net version out of curiosity, after I wrap my head around Mandelbrot sets.
    Just steal whatever you want from the Thread-Class - e.g. the InitializeLUT as well as the MBColor-function
    should be portable well enough (just replace all the short-typing-suffix-chars with appropriate .NET Types).

    Olaf

  6. #6
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    Just steal whatever you want from the Thread-Class - e.g. the InitializeLUT as well as the MBColor-function
    should be portable well enough (just replace all the short-typing-suffix-chars with appropriate .NET Types).

    Olaf
    Yea, I thought about that but I've never actually ripped code from a project without having some kind of understanding of it. Its seems simple enough though, nothing I can't come to know after a couple hours twiddling around with it.

    Quote Originally Posted by Schmidt View Post
    I also doubt, that I would achieve anything "more miraculous" in a different language compared to what I currently can accomplish in VB6.
    I don't get sometimes how people cannot come to grasp just how much more powerful .Net is. But you raise a fair point. C++ in combo with VB6 is quite powerful as well. I've said that before here.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,956

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    One of the snags in this is getting your client's (caller's) request "off" the calling thread and "worked" on the object's thread.

    There are a couple of ways to do it. One is as used in the demo above, via SendMessageCallback. The other is more common and easier to follow, via a hidden Form's Timer. However they don't seem to differ in performance as far as I have seen.

    I wouldn't use a magic number for WM_USER but that's just an issue of style and a quick demo. Even ignoring that though I'd avoid WM_USER and use WM_APP instead since WM_USER isn't necessarily safe beginning in Win32 systems... it isn't really the start of the User message range anymore. Still, it works fine here.

    Another issue is the use of an event for feedback. Since these are late-bound there is a performance hit, and a COM callback is theoretically vTable bound and quicker. I've used that here but I don't see any performance difference in this test case.

    I also ripped out the PropertyBag since I didn't feel it provided any advantage. But this is another issue of style and quick demos and personal preference.

    Effectively the architecture of my demo is identical to the original above. All I really did was use some slightly different plumbing to accomplish the same thing.


    I have included a pair of WSH scripts to simplify unregistering and re-registering the ActiveX EXE. I hate the clutter that results from experimenting with registered libraries, so I tend to get a little obsessive about cleaning up. You only need to re-register rarely, as when you have unregistered the EXE and you want to run it again.

    So... there isn't really anything new here, just a different stylistic approach more than anything important.

    I'm not sure what accounts for it, but mine compiles to 26KB while the original compiles to 36KB (I am using LINK.EXE 8.0 and you'll get bigger EXEs if you're still using 6.0 that installs with VB6). Maybe a lot of it relates to the code messing with the PropertyBag?
    Attached Files Attached Files
    Last edited by dilettante; Sep 5th, 2013 at 03:12 PM. Reason: reposted attachment, had an unneeded Event and a misleading comment

  8. #8

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by dilettante View Post
    One of the snags in this is getting your client's (caller's) request "off" the calling thread and "worked" on the object's thread.
    Yep, that is the main-thing what makes COM-marshalled STA-threading different from "normal" threading-approaches.
    (the per default synchronous behavior when methods are called, which belong to "Class-Instances on other threads").

    Quote Originally Posted by dilettante View Post
    There are a couple of ways to do it. One is as used in the demo above, via SendMessageCallback. The other is more common and easier to follow, via a hidden Form's Timer. However they don't seem to differ in performance as far as I have seen.
    Not in this example - but there are scenarios (e.g. with 16 Threads in a Pool, and when e.g. 16 parallel ThreadWorker-Jobs are triggered, which each then run for about 10msec only),
    where you want a faster decoupling-response, so that the threads start working nearly immediately, without a timeout of 12-15msec (which is the minimum-interval of a system-timer - you will not get a timer-event earlier than that).

    The SendMessageCallback-API decouples faster than that (below 1msec callback-response).
    An equally fast decoupling-response could be achieved via a PostMessage-call against the Form you now create within the cThread-ClassInstance anyways.

    Quote Originally Posted by dilettante View Post
    Another issue is the use of an event for feedback. Since these are late-bound there is a performance hit, and a COM callback is theoretically vTable bound and quicker. I've used that here but I don't see any performance difference in this test case.
    You don't see a performance difference, because your concerns about LateBound vs EarlyBound hold true only for COMmunication within the *same* STA-thread.

    But as soon as we have communication among Classes which were created on their own (differing) Threads (their own Single-Threaded-Apartments),
    all COM-calls against Public Methods on those classes are marshalled (with appropriate Parameter-Serializing and the already mentioned synchronous
    cross-thread-calling-mechanism between Proxy-Classes and their pendant - "the real Class-Instances on their own STAs").

    And because of this time-consuming serializing/marshalling which takes place, no matter if you use "real Events per IConnectionPointContainer" or the more direct Interface-Communication -
    the differences (which are definitely there in normal, single-threaded Apps) become negligible.

    And related to this marshalling is the following, e.g. when you write (within the Public cThread-Method CalcMBPart):
    Code:
    Public Sub CalcMBPart(ByVal ToCallBack As Object, ...
        'This code runs on the calling thread.
    This is not really the case, because the *whole Class* is created on its own STA - and so any Class-Method-code (Private and Public) "runs" on this STA-thread -
    and not on the Main-Thread (the "calling thread").

    You can check this by comparing the ThreadID with that in the Main-(GUI-)thread - just place a:
    MsgBox "Inside CalcMBPart ... App.ThreadID=" & App.ThreadID
    within the CalcMBPart-Method to see that for yourself (in the compiled executable you'll see a differing ThreadID).

    The marshalling (the clientside creation of a Proxy-instance, which performs only a "hollowed out" CalcMBPart-Method-Call
    then within the calling thread - which only is responsible for parameter-serializing and the synchronous request using this
    serialized Param-stream against the "real Class-instance, sitting within a different STA") - is the reason, why we need
    a decoupling. The marshaller always waits (at the clientside, within the calling thread) until the Remote-Call against
    (or within) the foreign STA returns ("runs over End Sub", so to say).


    Quote Originally Posted by dilettante View Post
    I'm not sure what accounts for it, but mine compiles to 26KB while the original compiles to 36KB (I am using LINK.EXE 8.0 and you'll get bigger EXEs if you're still using 6.0 that installs with VB6). Maybe a lot of it relates to the code messing with the PropertyBag?
    That's interesting - just updated my VB6-folder with link.exe version 9.0 (from VC++2008, including the necessary Dlls) and this works too.
    And you're right - this reduces the size from 36 to about 26kB (also in my property-bag based version).

    Just compiled RC5 with that - but not that much gain as I hoped for (size-reduction was about 110kB - which amounts to ~3% less - but well, it's a reduction nonetheless so I'm not really complaining ).

    Olaf

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,956

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    And related to this marshalling is the following, e.g. when you write (within the Public cThread-Method CalcMBPart):
    Code:
    Public Sub CalcMBPart(ByVal ToCallBack As Object, ...
        'This code runs on the calling thread.
    This is not really the case, because the *whole Class* is created on its own STA - and so any Class-Method-code (Private and Public) "runs" on this STA-thread -
    and not on the Main-Thread (the "calling thread").
    Yes I saw what I'd written and changed it. I felt this was a serious enough issue to re-post the attachment.

  10. #10
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,956

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    You don't see a performance difference, because your concerns about LateBound vs EarlyBound hold true only for COMmunication within the *same* STA-thread.
    Well if true then the advice given at MSDN (echoed in the VB6 docs on threading with ActiveX EXEs) is incorrect. Since I didn't find anything detectable even using high resolution timers I'll just assume the advice was incorrect or taken out of context.

    An advantage of staying with an Event over a COM Callback is that it would help keep a programmer from stumbling over the circular object reference issue. So without proof of any performance advantage (and while a callback offers several other advantages over an Event you usually won't care about them) I acknowledge that the Event technique is a better choice most of the time.


    The Hidden-Form-Plus-Timer technique certainly lacks elegance. It also imposes a slight delay in theory (I am not convinced sending/posting messages results in anything faster), though it is just in workload-kickoff and so not as bad as it might otherwise be. However it is the documented technique for doing this, works fine, and is less likely to discourage VB6 programmers than subtle use of API calls.

    Of course API calls actually attract a certain class of VB newbie too, like babies to candy.

    It's just sad there was never a direct "VB" way to do this added to the language, some kind of "return and continue" statement or an async form of method call.

  11. #11
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by dilettante View Post
    It's just sad there was never a direct "VB" way to do this added to the language, some kind of "return and continue" statement or an async form of method call.
    Funny you should mention this. Its almost prophetic. The added exactly that to the VB compiler in VS2012. I was trying to explain them to Shaggy in another thread. I think you were there too. The compiler does some kind of trick that breaks a method on an await call and unwinds the stack and continues executing. The await call is actually a call to an asynchronous method that is executed at the same time. When that method returns, it goes back and continues after the await. I think that's about how it works. I haven't figured out all the details as I've only toyed around with them thus far. I'm still using VS2010.
    Last edited by Niya; Sep 5th, 2013 at 03:50 PM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  12. #12
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,956

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    The technique used in the original demo above is perfectly fine and might be considered an improved alternative to the "standard" technique using a Form & Timer. I don't see anything wrong with it aside from it being perhaps a little more complicated for someone else to follow if they are new at this.

  13. #13
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,956

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Niya View Post
    Funny you should mention this. Its almost prophetic...
    Well, concern over this dates back to shortly after VB6 was released in 1998. It was one of the many things on the list of improvements that was gathered for future releases.

    I suspect that C# (and thus VB.Net) were more hung up on the state of the art in Java, which most of .Net was a direct ripoff of. Back in those days Java was still limited to the old Unix/C model of multithreading.

    If you ever find the desire to look at WinRT development you'll see lots of async method use there, whether writing in a .Net language, C++, or JavaScript.

  14. #14
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by dilettante View Post
    Well, concern over this dates back to shortly after VB6 was released in 1998...
    1998...wow. 14 years. That's a little tardy. I think the biggest mistake they made with VB6 was basing it on COM. I'm guessing it may have tied the language itself to closely to it and probably gave them limited flexibility in what they could have implemented in the language. I suspect that is why VB.Net was so different from it. COM just has too many quirks that I find either unacceptable or unnecessarily complicated. They may have had similar concerns.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  15. #15

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by dilettante View Post
    Well if true then the advice given at MSDN (echoed in the VB6 docs on threading with ActiveX EXEs) is incorrect. Since I didn't find anything detectable even using high resolution timers I'll just assume the advice was incorrect or taken out of context.

    An advantage of staying with an Event over a COM Callback is that it would help keep a programmer from stumbling over the circular object reference issue.
    Yep - Events are nice in this regard - and the "official Cycle-Breaker-Pattern" for VBClassic is thus also an Event-based approach.

    Quote Originally Posted by dilettante View Post
    So without proof of any performance advantage (and while a callback offers several other advantages over an Event you usually won't care about them) I acknowledge that the Event technique is a better choice most of the time.
    As for "proof of performance" ...
    If you download from the first link in my Opener-Post: http://vbRichClient.com/Downloads/MBSetAxThreaded.zip
    again, there is now some changes with regards to a perhaps "easier to follow compromise", which does use PostMessage-based async decoupling now...
    But I've also included two buttons for a performance-comparison, which basically shows the differences between Event- and Interface-callbacks.

    Here on my machine I got...

    Cross-Threaded-Performance (only measureable in the compiled Executable):
    ~ 40000 Events per sec
    ~ 64000 Interface-Callbacks per sec
    So the performance-level in marshalled (cross-thread) mode is generally low,
    though with a slight advantage of about factor 1.6 for the interface-based callbacks.

    Non-Threaded (and thus non-marshalled ... one can test this easily when running non-threaded in the IDE):
    ~ 1Mio Events per sec
    ~ 11Mio Interface-Callbacks per sec
    So the performance in non-threaded (non-marshalled) mode is significantly higher in both cases -
    but the interface-based approach performs now even factor 11 higher than the Event-based approach -
    and this factor 11 is, what is causing the usual "Events are routed LateBound under the covers -
    and are thus much slower than direct Interface-callbacks".

    The above is true - but a throughput of 1Mio Events per second is still quite high compared
    with marshalled remote-method-calls (so in threaded scenarios one should think a bit,
    how often and in what frequency callback-infos need to be passed around across thread-boundaries.

    In this Mandelbrot-Demo I trigger one Event-Callback per Row - and if we have about 1000Rows in
    our current Image-Size, then these are 1000 Events to raise - and if the Mandel-Calculation is
    fast, then those 1000Rows are completed in 333msec - this is an Event-rate of about 3000 Events per sec -
    and thus still factor 13 below the throughput-limit of roughly 40000Evts/sec, which is enough in this case.

    In case we would raise such a cross-thread-event on a per-pixel-base - that would bring the
    Event-throughput to its limits of course - but that would be Overkill - one just has to keep in
    mind, that cross-thread (and of course also cross-process) communication per COM has its limits
    (as any Office-Automation-guy very well knows, when e.g. a Sheet was attempted to be filled in a
    Loop over each and every Cells per Ole-Marshalled OutOfProcess-communication). Here the same things apply -
    some thoughts how to accomplish things with an reduced amount of cross-thread-calls are necessary.


    Quote Originally Posted by dilettante View Post
    The Hidden-Form-Plus-Timer technique certainly lacks elegance. It also imposes a slight delay in theory (I am not convinced sending/posting messages results in anything faster), ...
    Of course API calls actually attract a certain class of VB newbie too, like babies to candy.
    As already mentioned above, I've now included a PostMessage- (but also Helper-FormClass-based) decoupling now, which performs
    equally fast as the formerly used SendMessageCallback-API, but is perhaps easier to follow or comprehend.

    As for your "slight delay in theory" - we talk about roughly 12msec delay (in case of a Timer-decoupling) vs. 0.1msec in case of a Message-based decoupling.
    That's about factor 120 "delay-wise" (till the thread starts working).
    Here's a separate (non-threaded) Performance-comparison for that: http://vbRichClient.com/Downloads/As...ngPerfTest.zip

    Quote Originally Posted by dilettante View Post
    It's just sad there was never a direct "VB" way to do this added to the language, some kind of "return and continue" statement or an async form of method call.
    It's a feature which is apparently "nice to have" in a language nowadays - but there's not many things in "daily practice" (IMO)
    where this wish really comes up "in force" (these ActiveX-Exe-routines pretty much the only thing where this would be handy).

    But I don't use ActiveX-Exe-Threading here personally (have my own Threading-helpers, which allow Async- as well as Synchronous calls against ThreadClasses).
    Also included in the RC5-lib is a cOneShotTimer-class, which allows smaller intervals than the usual 12-15msec of the System-Timers (down to 1msec).

    And then there's a whole lot of APIs which are already designed with Async-capabilities - and Fibers are interesting too (if one wants a "non-threaded-fork"
    from the current callstack, to achieve something like CoRoutines... http://en.wikipedia.org/wiki/Coroutine).

    But as said, the necessities to use stuff like that are pretty low in "normal Desktop-programming" - and workarounds exist in plenty.


    Olaf
    Last edited by Schmidt; Sep 6th, 2013 at 01:43 AM.

  16. #16

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Niya View Post
    1998...wow. 14 years. That's a little tardy.
    Not sure what you mean there ...

    Quote Originally Posted by Niya View Post
    I think the biggest mistake they made with VB6 was basing it on COM.
    No, COM-components and COM-principles are the main-reason for the success of this language (6Mio Developers at peak-time).
    COM is the reason for the success of Microsoft as a company - without COM/OLE no Office-Automation, no cross-process-
    communication, no Remote-Machine-communicaiton (all based on COM) would be possible. We had no unified and
    dead-easy to use COMponent-concept for a whole lot of languages and the (COM-tools) 3rd-party market would not have been
    as flowering as it was (and still is).

    Quote Originally Posted by Niya View Post
    I'm guessing it may have tied the language itself to closely to it and probably gave them limited flexibility in what they could have implemented in the language.
    No, not at all - C++ can make use of COM and has appropriate Helper-libs and -headers built-in - and is in no way limited, it can do things "alongside COM" or entirely without COM.
    And an async/yield-support would in no way be hindered by COM - that's normal CallStack-handling-stuff, which belongs into the runtime (and could be implemented
    using Fibers for example).

    Quote Originally Posted by Niya View Post
    I suspect that is why VB.Net was so different from it. COM just has too many quirks that I find either unacceptable or unnecessarily complicated.
    Quirks?

    All the "Windows power- and key-technologies" are based on COM:
    - DirectX is based on COM
    - DirectShow is based on COM
    - COM+ Services are (obviously) based on COM (.NET never had a decent "distributed COMponent-Service-Tech., no "Transaction-Monitor" as powerful as that)
    - Office-Automation is based on COM
    - Finally the latest and greatest "tech-hype" which evolves around WinRT nowadays - all based on COM too.

    You seem to have no idea, what you're talking about.

    Olaf

  17. #17
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    Not sure what you mean there ...
    Dilettante said async methods were wanted since 1998, they were added to VB in 2012. 2012 - 1998 = 14 years.

    Quote Originally Posted by Schmidt View Post
    Quirks?
    Lack of inheritance.

    The general complexity behind its use and even the creation of COM components.

    Its funky threading models. STA, MTA and all that mess. It makes it easy for a programmer not to shoot himself in the foot at the expense of a more complicated under-the-hood design which limits your flexibility as a programmer. I don't really appreciate that. I don't mind doing my own synchronization and debugging race conditions for myself. I don't need to be coddled. I like threading my classes as I see fit.

    Quote Originally Posted by Schmidt View Post
    No, COM-components and COM-principles are the main-reason for the success of this language
    You've got to be ******** me. COM was meant to be a language agnostic way of authoring components whose key feature would be a strong contract based design. Something that improves upon the mess of older C style method exporting from DLLs. It largely succeeded but its a terrible idea to tie an entire programming language to it. You do know that class modules in VB6 are COM objects right ? This kind of design means seriously limits the ability to add language improvements to VB6. For example, if they wanted to add inheritance to VB6, it would have to be implemented in COM. That would be a breaking change and with the ubiquitous use of COM throughout Windows it would be a massive effort to debug. Not really worth it if your only reason is to improve a single COM based language. Now an object based system that is native only to the compiler frees you from that. C++ and VB.Net are all the better for it. Both languages allow you to produce COM components if you desire but the native object formats of both languages are tied to the languages, Frameworks and compilers of the languages and not an entire Windows subsystem.

    You're the one that doesn't know what he is talking about.
    Last edited by brad jones; Sep 9th, 2013 at 07:55 AM. Reason: profanity removed.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  18. #18

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    <COM>

    Quote Originally Posted by Niya View Post
    Lack of inheritance.
    Lack of inheritance is not "COMs fault" - it is foremost a feature of the compiler and the runtime to enable that
    (and in the real, COM-based VB7 which was announced and talked about at BASTA-conference in germany roughly around year 2000,
    the new inheritance-feature was definitely mentioned - so they had it ready - at least in a beta-version)...

    And as already mentioned somewhere in the recent threads - VB5/6 (and apparently also the VB7-Beta)
    were always tightly bound to their appropriate VC++ versions - and since C++ does support COM and inheritance, then why shouldn't this be possible.

    Quote Originally Posted by Niya View Post
    The general complexity behind its use and even the creation of COM components.
    Maybe in C++ that holds true, but not in VB6... VBClassic is "COM made easy".

    Quote Originally Posted by Niya View Post
    Its funky threading models. STA, MTA and all that mess.
    There's a lot of thoughts behind those models - many related to the stability- and isolation- and transaction-features in conjunction with the "pluggable nature" of "Remote-COMponents"
    when they run in the context of a (transaction-supporting/monitoring) RPC-Server (DCOM and nowadays COM+).

    Quote Originally Posted by Niya View Post
    It makes it easy for a programmer not to shoot himself in the foot at the expense of a more complicated under-the-hood design which limits your flexibility as a programmer.
    And that's what is entirely sufficient for many real-world-scenarios (threaded Mandelbrot-Demos included ).
    VBClassic always followed this approach - "make 95% of your daily tasks easy in a relatively bulletproof manner".

    For the rest there's either specialized COMponents - or the programmer is experienced enough, to write some of this stuff himself in a different,
    more suiting language (which also can be a Basic as e.g. FreeBasic or PowerBasic,which both offer Free-Threading with all the "flexibility" -
    but also all the potential pitfalls which come with that freedom).

    Quote Originally Posted by Niya View Post
    I don't really appreciate that. I don't mind doing my own synchronization and debugging race conditions for myself. I don't need to be coddled. I like threading my classes as I see fit.
    Whatever it is, you appreciate ... just go ahead and implement your threads "like real men do" ...
    I'm not here to tell you, how to write your stuff in *your* preferred language...

    And in case you didn't notice - I'm also not "over there" in the .NET-forum, to convince other devs on said board
    (with a lot of half-knowledge) why I consider .NET as "far below the language I'm most comfortable with".

    Quote Originally Posted by Niya View Post
    You've got to be shitting me. COM was meant to be a language agnostic way of authoring components whose key feature would be a strong contract based design. Something that improves upon the mess of older C style method exporting from DLLs. It largely succeeded ...
    It not only "largely succeeded" - the whole MS-story would be an entirely different one, when this easy to use COMponent-technology wouldn't have been in place -
    accompanied with appropriate tools, which enabled "glueing" those self-describing Class-Containers together in a highly RADish manner -
    MS-success started with VBA - in conjunction with the different Office-Apps, all able to communicate and interact with each other (per OLE-embedding and COM/OLE-automation).

    Quote Originally Posted by Niya View Post
    but its a terrible idea to tie an entire programming language to it.
    Says .NET-evangelist Niya in a VBClassic-forum... - where people hang around, who made (and make) a living from COM, VBA and VBClassic for nearly 20 years now... tss

    Quote Originally Posted by Niya View Post
    You do know that class modules in VB6 are COM objects right ?
    Oh my...

    Quote Originally Posted by Niya View Post
    This kind of design means seriously limits the ability to add language improvements to VB6.
    No.

    Quote Originally Posted by Niya View Post
    For example, if they wanted to add inheritance to VB6, it would have to be implemented in COM.
    No-
    Aside from that, the whole sentence doesn't make any sense, since implementations happen in a language and COM is not a language Niya.

    Quote Originally Posted by Niya View Post
    That would be a breaking change and with the ubiquitous use of COM throughout Windows it would be a massive effort to debug.
    No, it's only (or "all about") Interfaces and VTables - even in good old VB6 I can change and manipulate, aggregate, re-arrange, hook or override the VTable-entries in all possible ways -
    just read the appropriate passages in the Curland-book, to see what's possible at Runtime even.

    Then consider what a compiler could do at compile-time in that regard...

    Quote Originally Posted by Niya View Post
    You're the one that doesn't know what he is talking about.
    Yeah sure... Niya - see, I'm not the one with the "Blinking Avatar" here and the best I can do is not "Blinking-Label-Control" or "Centered-ComboBox-Items".

    Sorry - but your deliberate "non-understanding" your "playing dumb" (just for the sake of promoting a tool which is off-topic here in this forum) does get tiring in the meantime.


    Olaf
    Last edited by Schmidt; Sep 6th, 2013 at 06:29 AM.

  19. #19
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    Yeah sure... Niya - see, I'm not the one with the "Blinking Avatar" here and the best I can do is not "Blinking-Label-Control" or "Centered-ComboBox-Items".Sorry - but your deliberate "non-understanding" your "playing dumb" (just for the sake of promoting a tool which is off-topic here in this forum) does get tiring in the meantime.
    <Removed By Moderator> How in God's name does insulting contributions here which I took my valuable time to make add to this discussion ?

    Quote Originally Posted by Schmidt View Post
    Lack of inheritance is not "COMs fault" - it is foremost a feature of the compiler and the runtime to enable that (and in the real, COM-based VB7 which was announced and talked about at BASTA-conference in germany roughly about year 2000,the new inheritance-feature was definitely mentioned - so they had it ready - at least in a beta-version)As already mentioned somewhere in the recent threads - VB5/6 (and apparently also the VB7-Beta) were always tightly bound to their appropriate VC++ versions - and since C++ does support COM and inheritance, then why shouldn't this be possible.
    But it never happened. We got the .Net Framework instead. What does that tell you. It probably only looked good on paper.

    Quote Originally Posted by Schmidt View Post
    Maybe in C++ that holds true, but not in VB6... VBClassic is "COM made easy".
    Well duh genius. VB6 is a COM language as I've said many times before on these forums. Funny thing though, its just about as easy in .Net to author a COM server and client and yet more flexible despite .Net not being inherently a COM based technology.

    Quote Originally Posted by Schmidt View Post
    I'm also not "over there" in the .NET-forum, to convince other devs on said board (with a lot of half-knowledge) why I consider .NET as "far below the language I'm most comfortable with".
    Far below ? LOL LOL LOL. Minus any fanatical VB6 fanboyism, anyone with half a brain could see that VB.Net is far superior to VB6.

    Quote Originally Posted by Schmidt View Post
    said board (with a lot of half-knowledge)
    You shouldn't be insulting other people's knowledge when you're too stupid to realize that your precious VB6 is antiquated.

    Quote Originally Posted by Schmidt View Post
    Says .NET-evangelist Niya in a VBClassic-forum... - where people hang around, who made (and make) a living from COM, VBA and VBClassic for nearly 20 years now... tss
    I'm sure that there are alot of people out there still making money for building catapults and ballistas. What's your point ?

    Quote Originally Posted by Schmidt View Post
    No, aside from that, the whole sentence doesn't make any sense, since implementations happen in a language and COM is not a language Niya.
    VB6 compiles its classes as COM servers so the COM subsystem would have to be changed in order to add inheritance you moron. Perhaps they could get some progress by using compiler tricks but that would only be a hack at best.

    Quote Originally Posted by Schmidt View Post
    VBClassic always followed this approach - "make 95% of your daily tasks easy in a relatively bulletproof manner"
    More abstractions mean less flexibility which means when you need that flexibility you're going to have to hack your way around the limits of whatever abstractions are blocking you which ironically makes certain tasks harder than they need to be. You can spawn a worker thread at will in C++ or VB.Net. Just like that, snap of the finger but you need all these merry-go-round antics to do it in VB6 ?

    That is not to say that abstractions are a bad thing. They are essential for RAD tools like VB but for some things they could provide lower level abstractions for those who need some extra power. In the case of threading in VB6, they didn't.

    Quote Originally Posted by Schmidt View Post
    No, it's only (or "all about") Interfaces and VTables - even in good old VB6 I can change and manipulate, aggregate, re-arrange, hook or override the VTable-entries in all possible ways -
    You're over simplifying things here. There is whole lot more to COM than just VTables and interfaces. They might be key things but stop trying to fool people by suggesting that you can add something like inheritance by only mucking about with VTables. If they tried to add such a huge change to COM, it will break something somewhere. I have no doubt that it can be done but don't undersell the difficulty of this.
    Last edited by Siddharth Rout; Sep 9th, 2013 at 04:56 AM. Reason: Removed Swearing words
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  20. #20

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Niya, please try to get OnTopic again -
    I appreciated your willingness, to come up with something similar (even when written in .NET) to the demonstrated VB6-Threading-approach -
    but if that proves too difficult for you, then by all means - just let it be - you have no obligation to fulfill in that regard...

    Just stop your immature .NET-advertising now, please... it has nothing to do with the original Thread-Topic anymore.

    Thank you very much...

    Olaf
    Last edited by Schmidt; Sep 6th, 2013 at 07:28 AM.

  21. #21
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    You're that one that started acting like a little <REMOVED BY MODERATOR> when all I did was give my opinion on VB6 being based in COM. You invited my so-called .NET advertising. Now you're trying to play the innocent act like a little <REMOVED BY MODERATOR> ? You were the one that attacked not me. Immature behavior is all you kid.
    Last edited by Siddharth Rout; Sep 9th, 2013 at 05:15 AM. Reason: Removed swearing words
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  22. #22
    Frenzied Member
    Join Date
    Mar 2008
    Posts
    1,189

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Gentlemen, please ....

  23. #23

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Hi Ink,

    no need to worry - all perfectly fine and normal here - it's just the side-effects of an unmoderated forum you see.
    Unmoderated at least with regards to .NET-fanboys who are allowed to disrupt VB6-discussions as they please,
    even when they continue their advertising after the thread-starter expressed his disgust with their off-topicness explicitely.

    Well, do you have more questions with regards to the COM-based threading of VB-Classic?
    I'm prepared and willing to answer them - it's what this thread is thought for after all...

    Olaf

  24. #24

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,683

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    So far you contributed naught to this discussion Niya (other than .NET-ads and some misleading things about COM, which I had to correct for the archives).

    Dilettante posted already *VB6-Code*, which helped to deepen the understanding of this topic for other members of the VB6-community.

    As the thread-opener here in the code-bank I have posted *VB6-Code* with regards to that topic too of course - and had a nice and fruitful discussion
    with Dilettante, which led both of us to correct and change things in our original code-contributions to this thread - and myself to post an additional
    zipped example for a side-topic of COM-threading (different Async-Decoupling approaches and their Performance).

    Members of the VB6-community already marked that thread as "technically interesting" - and I'd like it really much, when you could
    refrain from your practice of trying to provoce me into something here - see, all your latest postings here only clutter a technically
    very nice thread with a lot of whiny and partly aggressive drivel - and so I will ask you for a third time, to stop this immature
    behaviour now and start (for the first time in this thread) with a contribution to VB6-threading, which is OnTopic here?


    Thank you

    Olaf

  25. #25
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    <REMOVED BY MODERATOR> I was talking about async methods and my opinion on COM with dilettante and you went <REMOVED BY MODERATOR> and started this aggressive confrontation. I never provoked these arguments with you. You're the one that always starts them. Apparently you cannot control your infatuation with me. At this point, it seems to me that you're just an attention <REMOVED BY MODERATOR>. That's all you're doing here, <REMOVED BY MODERATOR> yourself out for attention.
    Last edited by Siddharth Rout; Sep 9th, 2013 at 05:01 AM. Reason: removed swearing words
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  26. #26
    Super Moderator Siddharth Rout's Avatar
    Join Date
    Feb 2005
    Location
    Mumbai, India
    Posts
    11,998

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Ladies and Gents. Please get back on to the topic.

    @All: I have edited few posts. While we encourage healthy discussions, please do not swear in the posts or put down any other member. I have edited few posts. The next person who swears or puts down other member is in for a nasty surprise You may take it as a request or First and Final Warning
    A good exercise for the Heart is to bend down and help another up...
    Please Mark your Thread "Resolved", if the query is solved

    Microsoft MVP: 2011 - 2015 IMP Links : Acceptable Use Policy, FAQ
    MyGear:
    OMEN by HP - 15-ce073tx with Win10+Office 2013. || Mac Book Pro (10.6.8) with Office 2011

  27. #27
    Super Moderator Siddharth Rout's Avatar
    Join Date
    Feb 2005
    Location
    Mumbai, India
    Posts
    11,998

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Niya: If you have to say anything about a member you may PM a moderator but from now on you will not comment like you did in your last post. I have deleted your last comment.
    A good exercise for the Heart is to bend down and help another up...
    Please Mark your Thread "Resolved", if the query is solved

    Microsoft MVP: 2011 - 2015 IMP Links : Acceptable Use Policy, FAQ
    MyGear:
    OMEN by HP - 15-ce073tx with Win10+Office 2013. || Mac Book Pro (10.6.8) with Office 2011

  28. #28
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    6,661

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by koolsid View Post
    Niya: If you have to say anything about a member you may PM a moderator...
    I assure you I will if he provokes me again in the future.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  29. #29
    ex-Administrator brad jones's Avatar
    Join Date
    Nov 2002
    Location
    Indianapolis
    Posts
    6,596

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Please - no more discussion about people. No more profanity. No more insults.

    All further posts in this thread need to be about "VB6 (ActiveX-Exes and selfhosted Threading)". This is not a .NET thread, so I agree that no more discussion of .NET should be included unless the original poster asks for it.

    Do not respond to this post. Only respond if you are staying on the topic of "VB6 (ActiveX-Exes and selfhosted Threading)".
    Have you given out your reputation points today? Select the Rate This Post link to give points for good posts!
    -------------------------------------------------------------
    Brad! Jones
    Lots of Software, LLC
    (My recent articles) (I wrote: Web 2.0 Heroes!) (Dad Jokes Book) (Follow me on Twitter)

    --------------------------------------------------------------

  30. #30
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB6 (ActiveX-Exes and selfhosted Threading)

    Quote Originally Posted by Schmidt View Post
    Here's an example for a simple AX-Exe-Threaded-Selfhosting-approach (calculating a Mandelbrot-Set on two worker-threads -
    reflecting the results "row-by-row" in the GUI-MainThread then per normal cross-thread-COM-events).

    The Zip-File here in this link:
    http://vbRichClient.com/Downloads/MBSetAxThreadedV2.zip
    contains version 2 of the demo, whilst the Zip-File at the bottom of this posting (below the ScreenShot) contains the original version.
    (version 2 contains a different Async-Decoupling-approach and a performance-test for Event-based vs. Interface-based Thread-Callbacks)

    Would really like to see a .NET-version which does the same thing in the same performance (just try in the compiled Executable, and not in the IDE for "full-threaded-speed").
    (the VB6-code is a bit rusty, it's already a few years old - but still working as it seems - just put it here as a reference).



    Olaf


    Very nice code Olaf !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width