Results 1 to 15 of 15

Thread: Multithreading in VB

  1. #1

    Thread Starter
    New Member
    Join Date
    Aug 2001
    Posts
    2

    Multithreading in VB

    Sorry if this is in the wrong forum - I'm new to this (and VB - only 3 months!).

    I am writing an app that will require connecting to a PocketPC via ActiveSync. I'm using the RemoteAPI in rapi.dll to make all of the CE calls. In particular, I need to have a separate thread to call CERapiInit which will hang if the connection cannot be made.

    There are several obstacles I face.

    1. To create a separate thread, the only safe way I have found is to make the app an ActiveX exe, and CreateObject a new instance of a class form as a new thread. The form contains a Timer control which triggers a CERapiInit call after the form is instanced . Is this the only way?

    2. Once the thread has been created and the CERapiInit call made, I have no way of knowing whether or not the call was successful since the thread is in its own memory space. The only way I can think of monitoring the sucess of the call is to try to make the CERapiInit thread change something (a label caption, etc) in the main app. How can I change the caption of a label in a separate form window that is not in the same memory space?

    Thanks for any help you guys can provide. I see that some of you have made thousands of posts - that's incredible!!

    Thanks,

    Brian

  2. #2
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    In VB 5, you could call CreateThread. This does not work in VB 6 and MS knows it.

    So, I have come to the same conclusion. In VB, the best way to multithread appears to be through an ActiveX EXE. And, it works well.

    When you create the thread in you main program, if the creation fails, you DO know. You can call CreateObject or use NEW to create the thread.

    There are several good ways to 'signal' between these threads. You could:

    Use a synchronizing object - perhaps a mutex.
    Use an EVENT, generated by the created thread.
    Use DDE (although this is kinda "old").
    Use the Implements statement in some way.
    Use Windows messages.

    As you can see, many ways. In your case, I would probably start with the EVENT as it's the easiest. Go from there.

  3. #3

    Thread Starter
    New Member
    Join Date
    Aug 2001
    Posts
    2

    Thanks Jay

    I'm glad to hear your confirmation about ActiveX exe's.

    I'll give your suggestions a whirl, although I am partial to Win32API calls as they are fast.

    Any suggestion on a good API to use - I was thinking of having the CERapiInit thread change a label caption in the main app from "Connecting" to "Connected" and just check that for success of the call.

    I have had no problems getting successful creation of the threads.

    Cheers,

  4. #4
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    If you do that, you will have to 'poll' the label with a timer to check for a change - this does not appear to be efficient.

    I am also curious about the mechanism you were going to use to change the label from the thread.

    Again, I would start with an Event.

  5. #5
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    ----------------------------
    CreateThread and ActiveX EXE
    ----------------------------

    It appears that, if coding in VB, you should NOT use CreateThread. (Besides, one way or the other, it will cause fatal program errors.)

    I think I can tell you why (how this has come to be) ...

    Microsoft has dedicated a lot on objects - even more so with its VB environment. Yes, objects are in C++, however, MS 'evolves' VB while it can only 'add' to C. If they altered C, as they tend to do with VB, it would no longer be C. C is raw. (Which can be real nice, sometimes.)

    With the proliferation of the Internet, Microsoft SEES the need to have objects dispersed. This means, basically, to have data and programmatic 'snips' available both locally and REMOTELLY - through the network cable.

    You can see this progression in (to name a few) Remote Data Objects, (CreateThread), VB.NET.

    In principle: CreateThread is a local thing; CreateObject is a local OR remote thing. Thus, CreateObject becomes more powerful. It allows you to multi-thread AND allows for Remote Objects.

    Basically, now, ActiveX EXE is the thread creation tool in VB.

    --------
    VB and C
    --------

    A little rambling . . .

    It has always been the case that assembly and C allow you to easily get 'close' to the low-level environment. Thus allowing you to do things that you basically couldn't do in Basic.

    However, be aware, even in DOS Basic days, one could use a library for Basic that allows quick, efficient low-level access. I wrote many such assembly routines - for video, for virtual memory, for serial. These routines empowered me to do anything in Basic I could do in C.

    Although I have spent a lot of time in Basic, I really do love assembly and C. On the other hand, at least for me, Basic produces programs quickly. If I was going to write a device-driver, I would use assembly or C - no question asked!

    --------------------
    thread communication
    --------------------

    Ever since multi-tasking has existed, program communication was needed, and has has existed.

    This is kinda how the low-level thoughts go ...

    Lets say two programs or threads want to simply share some information. You would think they could just share a block of memory. However, what happens if one thread is reading a block WHILE another thread is altering? The reading thread would get a corrupted 'message'.

    That's what things like the "mutex" are for. They synchronize access to something - one thread 'locks' access.

    In my previous message, I mentioned several ways of 'communicating' (in VB). I won't go into detail because which way you choose really depends on the situation. Because I discussed (remote) objects earlier, I will say that EVENTS have the capability of Remote signaling.

  6. #6
    Your Ad Here! Edneeis's Avatar
    Join Date
    Feb 2000
    Location
    Moreno Valley, CA (SoCal)
    Posts
    7,339
    You need to check out the Coffee example on the MSDN disc. I covers mulitthreading, asynch, call backs, and events. Instead of haveing it change something you pass it an object to make calls back to and then it can fire events (kinda) that let you know when you are connected.

  7. #7
    Your Ad Here! Edneeis's Avatar
    Join Date
    Feb 2000
    Location
    Moreno Valley, CA (SoCal)
    Posts
    7,339
    Here is an example I posted before. I don't think its quite what you are looking for but maybe you can get something out of it. Its all taken from the Coffee example.

  8. #8
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    Just in case you are waiting for me to say something about Edneeis's reference to the MS Coffee example ...

    Yes, do look at it. I agree with Edneeis, it is a good reference.

  9. #9
    Hyperactive Member tumblingdown's Avatar
    Join Date
    Mar 2000
    Posts
    362
    If you want to use a activeX exe to simulate a multithreaded environment in VB, then you have to use CreateObject. Using New will not work. If you call New, VB will (internaly) create the object for you. If you use CreateObject, VB will call out to the COM runtime (CoCreateinstance) which will create your object on a new thread.

    The story does not end there, however. VB progs can only run in an STA environment. This means that altho you may appear to have multiple threads, all calls to your COM object (including the one you just created) will come thru a single ORPC port. All calls will queue up and be dealt with in turn (just as well, seeing you can't do re-entrant code ;-).

    I used to be a big fan of this scenario, and it can be a fairly good approximation in some circumstances. As far as inter-thread communications go in VB, prolly the easiest to use are atoms (process scope singleton strings) used for signalling. There are various api calls around for using these.



    td.
    "One logical slip and an entire scientific edifice comes tumbling down." - Robert M. Pirsig


    tumblingdown@hotmail.com

    "but if Einstein is right and God is in the details, reality requires that we sometimes get religion." - Scott Meyers.

  10. #10
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    There is a lot to be said about multithreading in VB - including the use of New and CreateObject. Do the research for yourself 'cause general answers may not be accurate for what your trying to accomplish. Anyone interrested in multithreading should certainly search MSDN / VB Help - lots to read, many considerations.

    (For one thing, within the VB IDE, it's deceptive to test multithreaded aplications. Compile it before expecting multithreaded results.)

    There are differences in New and CreateObject. However, you CAN create threads with New. This assumes that you have an Server ActiveX EXE AND a Client Standard EXE. MS says I can, and my tests say I can. I am making no statement on the differences between New and CreateObject in this case, just enforcing that New will create threads.

    This by no means says that you should always use New - as you should NOT. Do your research - I am by no means a VB multithreading expert.

  11. #11
    Hyperactive Member tumblingdown's Avatar
    Join Date
    Mar 2000
    Posts
    362
    Originally posted by Jay Rogozinsky

    There are differences in New and CreateObject. However, you CAN create threads with New. This assumes that you have an Server ActiveX EXE AND a Client Standard EXE. MS says I can, and my tests say I can. I am making no statement on the differences between New and CreateObject in this case, just enforcing that New will create threads...
    Well, yes, obviously using New and CreateObject will both create seperate threads in a Client to ActiveX .exe Server scenario, because the Client and the Server are in different processes!!!. come-on Jay, get with it ;-)


    I mean you can create psuedo threads in a single activeX server, by using CreateObject to call out to COM, which calls back to you, to create your object.

    E.g. If Your aX Svr has a public createable object X.
    Something else (say object Y) in the aX Svr would like to use some methods on X, and have them run in a separate thread.
    If Y uses CreateObject to create X, then VB calls out to COM, which calls back to the aX Svr to create the object. In effect, VB doesn't know it's itself that is asking for the object. If it did, it would shortcut the call out, and create the object itself - which is what happens when you use New.



    td.
    "One logical slip and an entire scientific edifice comes tumbling down." - Robert M. Pirsig


    tumblingdown@hotmail.com

    "but if Einstein is right and God is in the details, reality requires that we sometimes get religion." - Scott Meyers.

  12. #12
    Addicted Member
    Join Date
    Jul 2001
    Posts
    133
    Thank you for clarifying that to everyone else, I was already aware.

    Take note that, in this case, brianj was referring to a separate process - so, 'getting with it' is something that you need to do.

    You did not make the process distinction when you posted - you simply said New will not create a separate thread.

    None the less, you definitely know more about the semantics of multithreading in VB than I do. Thanks for your input.

  13. #13
    Hyperactive Member tumblingdown's Avatar
    Join Date
    Mar 2000
    Posts
    362

    Re: Multithreading in VB

    Jay, sorry dude. You are correct.


    Originally posted by brianj
    ...

    2. Once the thread has been created and the CERapiInit call made, I have no way of knowing whether or not the call was successful since the thread is in its own memory space. The only way I can think of monitoring the sucess of the call is to try to make the CERapiInit thread change something (a label caption, etc) in the main app. How can I change the caption of a label in a separate form window that is not in the same memory space?

    ...
    Brian, if you know the handle of the label, then you can SendMessage the new label text.



    td.
    "One logical slip and an entire scientific edifice comes tumbling down." - Robert M. Pirsig


    tumblingdown@hotmail.com

    "but if Einstein is right and God is in the details, reality requires that we sometimes get religion." - Scott Meyers.

  14. #14
    New Member
    Join Date
    Aug 2001
    Location
    HKSAR
    Posts
    1

    Smile

    Do anyone know that are there some ways in Visual Basic to pass the reference of COM Object from one thread to another thread successfully or invoke the methods or property of COM Object where it is created in different thread but within the same process ?

    Thank you for your attention

  15. #15
    Member
    Join Date
    Mar 2001
    Posts
    56

    True multithread VB5 VB6 source code controls


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