Re: MultiThreading advice
VB6 mdoes not support multithreading - best you can do is simulating it via ActiveX exe. Woka has very nice working sample project so have a good look at it.
1 Attachment(s)
Re: MultiThreading advice
I'm not a fan of Woka's approach. I assume he has his reasons but reading that thread it all sounds like gibberish. Maybe I ought to look again and see if some clarity was added later.
VB6 does indeed support support multithreading natively. I'm not sure where anyone gets the idea it has to be simulated.
The atttached demo shows how you can do this. If you run Task Manager you will see that there is just one process running the usual "overhead threads" (about 4) and then additional "application threads" as you click a button to create them.
The API calls used are minimal and those few calls do things you could manage another way without API calls.
Re: MultiThreading advice
Since there is no native class in VB6 that supports multhithreading all we can do is use external help which in a sense can be called "simulation".
But if you have better name for it I'd be glad to use it in the future. :)
Re: MultiThreading advice
What is this external help you refer to? Clearly you haven't looked at the working example I provided, or you will see that it is based on the suggestions in the VB6 manual for mutithreading. Works fine and there is no "external help" or any sort of simulation.
I've actually even cut it down to just one API call (FindWindow).
Re: MultiThreading advice
No, I haven't looked at your sample - ActiveX exe is what I refer to as an external help.
I appears to be the right way of doing it.
Re: MultiThreading advice
Ahh, but it doesn't need to be external at all. As you'll see my example has just one EXE, and when run there is just one instance of it.
Re: MultiThreading advice
Re: MultiThreading advice
@RhinoBull , based on this link it seems doable the multi thread in vb6 , no ? If you check the attached code you will get an idea about my needs.
@dilettante, thanks a lot for the attached code, I have to sleep now and tomorrow i will check it, but could you check the code i attached to understand more my need ? My Idea was to open a new thread in the WNPROC FUNCTION each time i receive a file to make the treatments on this file...
By the way, as i mentioned above, i have a form working in the background (hidden) , it's the form that is receiving the file and another form which is appearing and this form is the one in which the user type inside a textbox information during the time that the files are received....These forms are in the same instance of my program (the first launched instance), also my idea is to open the form that is showing in another thread so that the user can work on it without interrupting or beeing bothered by the work that is done in the background by the main hidden form
Hope that you got me clearly now
Thank you both it's very nice from your side trying to help
Re: MultiThreading advice
Quote:
Originally Posted by
dilettante
I'm not a fan of Woka's approach. I assume he has his reasons but reading that thread it all sounds like gibberish. Maybe I ought to look again and see if some clarity was added later.
VB6 does indeed support support multithreading natively. I'm not sure where anyone gets the idea it has to be simulated.
The atttached demo shows how you can do this. If you run Task Manager you will see that there is just one process running the usual "overhead threads" (about 4) and then additional "application threads" as you click a button to create them.
The API calls used are minimal and those few calls do things you could manage another way without API calls.
Please make practical demo to show multithreading advantage. e.g. load big amount data from database; File searching ...
Re: MultiThreading advice
The most common practical example might be anything that requires a long-running processing loop. The sort of thing where people fumble around by adding DoEvents, Sleep, etc. to the loop so their program doesn't get locked up and marked Not Responsive by Windows.
Another example might be logic that uses some kind of synchronous blocking operation. These usually involve interacting with a remote source like a Web server handling Web Service calls when you use a synchronous client component instead of one that can raise progress and completion events. This one is also about preventing program lockup.
One more example might be programs that do really heavy crunching that you hope to spread out over multiple hyperthreads, cores, or processors.
There might be others but I can't think of any right now. Real examples that need it are rare though, and often you can use VB's async model of processing based on events instead.
Re: MultiThreading advice
Quote:
Originally Posted by
justgreat
@
RhinoBull , based on
this link it seems doable the multi thread in vb6 , no ?
Look at the date on that article.
It is the classic Appleman "don't screw around trying to multithread in VB6" article.
People kept misinterpreting what he was saying, so he even added two "Sequel" statements at the end over the years following it. The funny part is that even with two attempts to make his point clear people still think the original article is saying CreateThread approaches make sense!
Quote:
April 2000...
It seems that telling people not to use CreateThread wasn't a satisfactory answer after all. I continued to receive requests for information on how to create threads both for background operations and to use NT synchronization objects from VB DLL's. As you probably know, when enough people ask for something that isn't easy or possible to do with Visual Basic, sooner or later it shows up as a new feature in SpyWorks. With version 6.2, we've included a component called dwBackThread that allows you to create objects from your VB DLL in their own thread and then trigger background operations. The component handles all of the necessary marshaling and cleanup for you so that it's as safe as one can be when doing multithreading. Most important - it follows all of the COM threading rules, so you don't have to worry about pieces of VB or components you use suddenly failing to work. See our product pages on SpyWorks for further details.
You can still find SpyWorks at http://desaware.com/products/univers...rks/index.aspx
You can find alternatives too: http://www.newobjects.com/pages/ndl/AdvancedCOM/ids.htm
Re: MultiThreading advice
dilettante , In the article he says that he doesn't suggest to do multithreading etc..but at the end he is doing it as it seems...that's why am reading his article to see how he did it, and it seems it's by using the CreateObject
In my case (based on the code above), how do you suggest me to do it ?
I would like to do the multi thread in 2 cases :
1-once I receive a file in the WNDPROC
2-On form load (it's not shown in the above code, but i can show you more code), I hide the main form and i launch another form (visible) that the user see; so i would like to launch the new visible form into a new thread so it won't be bothered by the treatments made in the background by the main hidden form
I got an additionnal 2 questions, as it seems multi thread works only in ActiveX.exe project and not standardExe...My actual project is a standard Exe, to convert it to ActiveX.exe,
1-all i have to do is to create a new project and add my forms and modules etc....or should i do a specific modification on my code ?
2-Switching from StandardExe to ActiveExe, means the user must have specific Dll on his computer ? or vbruntime are enough ?
Thanks in advance
Re: MultiThreading advice
His article is basically going through the gyrations one might try (and fail on). As he says in the quote above, don't bother.
As far as I know there is no problem having the UI Form running on a secondary thread but it will probably be much easier if you don't.
You can probably make a new ActiveX EXE project, then copy your existing Forms and statis (BAS) modules to the new project folder, then use Add file... to add them to the new project.
I don't know why you would expect to need some other DLL for ActiveX EXEs to run. There is nothing special required except to register the program as an ActiveX EXE which can be done by running it elevated the first time, or by running it elevated with the /regserver command line switch first.
Re: MultiThreading advice
dilettante, thanks again
1-So if I don't want to use the way mentioned by RhinoBull and the article that I was reading, can you provide me some code to implement in my WnProc to accomplish the creation of a new thread for each received file ?
2-To run the second form in another thread what do you suggest to use ? CreateObject ?
3- So to accomplish multithread i have to do an ActiveX exe and not a standard exe ? if yes Can you give me more information about running ActiveX exe as elevated ? do you mean right click and run as administrator ? and plz how to register it with the regserver? When the user wanna use it, it's the same for him as launching a normal exe ? I use vb6 since 99, but never got the need to use an activex exe that's why I don't know about
Thanks a lot
Re: MultiThreading advice
1. The easiest way is to create a non-Form Class that in turn loads/shows the Form. But you do not want one thread for each file (whatever "received" file means)!!! Threads are not cheap, and most of the time more than a single worker thread doesn't make sense and will actually slow everything down.
2. Yes, you have to use CreateObject() for this.
3. Yes, VB6 multithreading is based on COM multithreading so your program must be a COM server, which for an EXE means an ActiveX EXE. Yes, "right click, run as admin" will run it elevated.
A VB6 ActiveX EXE can self-register on its first run. It can also self-register and terminate by passing it the command line switch /regserver. To be properly registered requires this be done with elevated privileges, such as during installation. Even a PDW setup package will handle this for you.
After that it can be run normally.
But...
So far I don't see anything indicating you will benefit from all of this. Threads are not some kind of magic. Your idea of creating a thread for each of hundreds or thousands of workloads is frightening, to say the least. Most likely you'll lock up or even crash your PC, or at best have things run very slowly.
Re: MultiThreading advice
Here is an example with Multithreading using ActiveX Exe:
VB6 - A very precise timer using Multithreading (Also see post #9)
Re: MultiThreading advice
Quote:
Originally Posted by
CVMichael
Thanks a lot, I will check this and come back for you in case i need more questions about
Re: MultiThreading advice
Quote:
Originally Posted by
dilettante
1. The easiest way is to create a non-Form Class that in turn loads/shows the Form. But you do not want one thread for each file (whatever "received" file means)!!! Threads are not cheap, and most of the time more than a single worker thread doesn't make sense and will actually slow everything down.
Inside the WNPROC (if you checked my code above) , i will get the file name that was selected from windows context menu and it's at this moment that i called it file received, i mean i received the file name that was selected by the user inisde my WNPROC....In other word, i refere to the select cases code that is inside my WNPROC
Quote:
A VB6 ActiveX EXE can self-register on its first run.
That's exactly what I want, can you give me an example on how to do that ? and how to use the "/regserver" commad ?
Because I want to make a standalone exe so it will be very usefull that it register itself
Quote:
So far I don't see anything indicating you will benefit from all of this. Threads are not some kind of magic. Your idea of creating a thread for each of hundreds or thousands of workloads is frightening, to say the least. Most likely you'll lock up or even crash your PC, or at best have things run very slowly.
Me neither, but I have to check and see if in reality it will change or not .. By the way, i won't really make a thread for each file, only for files that I suspect that they will take long time to be treated, for expl, folders that include subfolders and in each lots of files :)
Re: MultiThreading advice
I don't know what your feelings about are about using third-party DLLs, but I've had some success using Olaf Schmidt's dhRichClient3 DLL cThreadHandler class.
Essentially, you can declare a module level instance of the cThreadHandler class (WithEvents), and then you can start a thread from any multiuse VB6 DLL class.
You can call methods asynchronously to work in the background, and if any methods of those methods raise events, they will be interceptable in the ThreadEvent event of the cThreadHandler class.
There are demos in the samples available at the link above, but I could provide more if you are interested.
Re: MultiThreading advice
Quote:
Originally Posted by
justgreat
That's exactly what I want, can you give me an example on how to do that ? and how to use the "/regserver" commad ?
Because I want to make a standalone exe so it will be very usefull that it register itself
You always need an installer. For an ActiveX EXE it takes care of registration either by running the EXE with /regserver or by importing registry settings bundled into the installer package.
See How To Register and Unregister an Out-of-Process COM Component (ActiveX EXE) for help in using the self-reg code VB6 compiles into the program.
In any case it must happen elevated (i.e. with full admin/installer rights). Out of process registration can't be done per-user and must be global.
Quote:
Originally Posted by
justgreat
Me neither, but I have to check and see if in reality it will change or not .. By the way, i won't really make a thread for each file, only for files that I suspect that they will take long time to be treated, for expl, folders that include subfolders and in each lots of files :)
It doesn't really matter. For what you are trying to do you only want one worker thread that processes requests from your UI thread in sequence. Extra worker threads are very unlikely to buy you much, and beyond about 2 of them there isn't much point.
Re: MultiThreading advice
Quote:
Originally Posted by
dilettante
It doesn't really matter. For what you are trying to do you only want one worker thread that processes requests from your UI thread in sequence. Extra worker threads are very unlikely to buy you much, and beyond about 2 of them there isn't much point.
Based on this, I understand that you suggest me not to do multiThreading, so I will explain to you the main problem and maybe you give me a better idea than multi threadin :
As shown in the attached code above :
-When a user right click on files, and hit the corresponding windows context menu, my application is receiving these files...
As you know these files will be sent as a sequencial calls to my .exe ...
So if the user selected 100 files, my exe will be called 100 times, so I have to make sure not to show except one instance of my program, the other
instances will have just to send the current file name to the main instance and close themselves.
The main instance is receiving the files in the WNPROC and making treatement on them ...
First instance (which represence the first file selected) once launched is hiding the main form, showing a temp form in which user can type things inside textbox...
So When the user right click on 1000 files, he will see the Temp Form, can type in it what he wants, during this time, the Main form is hidden receiving from windows the files names that he selected and making the treatement on them
Problem : I noticed that when I am selecting lots of files, if the user try to type inside the textbox of the temp form, or move the form, etc... he won't be able to, or somethimes another Temp form will appear (which is not normal), weird behaviors.... But if you launch the program, and during this time the user doesn't touch the Temp Form, all is fine !!!
That's why I thought about making the Temp Form into another thread and also I felt that treatement is slow so I said it's maybe better to make the treatement of each file in a new thread
Re: MultiThreading advice
You would still only need one worker thread to do your "file treatments" though.
I'm confused why you think you want the users to choose files through this strange arrangement of events. It would be far easier to use a CommonDialog or a custom dialog based on a ListView or the old Drive, Folder, and File controls.
As it is what you're doing won't work except where the user logs on as an admin, or in modern Windows versions runs the program elevated. You are doing far too much registry hacking in a sensitive area as well. Applications that thrash on system state like this just aren't a good thing. I'll bet you are trying to write this on XP or something, always logged on as a full admin, right?
Can't you use a less hazardous approach for a "file picker" than this?
Re: MultiThreading advice
Quote:
Originally Posted by
dilettante
VB6 does indeed support support multithreading natively...
I just read it again and realized you said "does" instead of expected [by me at least] "does not".
When programming language supports some functionality natively it typically offers class or control that does it.
Everything else is just a trick that more or less advanced programmer can do.
In fact lots of things we did in VB6 were tricks based. Examples of such tricks could be "extended combo" with larger dropdown; controling form's border at runtime; etc, etc, etc...
You may argue, call it however you wish but those are NOT native functions - this also applies to multithreading.
All we do (or did for that matter) was extending language capabilities and by no mean we were using any of its native functions.
Re: MultiThreading advice
Quote:
Originally Posted by
dilettante
You would still only need one worker thread to do your "file treatments" though.
I'm confused why you think you want the users to choose files through this strange arrangement of events. It would be far easier to use a CommonDialog or a custom dialog based on a ListView or the old Drive, Folder, and File controls.
As it is what you're doing won't work except where the user logs on as an admin, or in modern Windows versions runs the program elevated. You are doing far too much registry hacking in a sensitive area as well. Applications that thrash on system state like this just aren't a good thing. I'll bet you are trying to write this on XP or something, always logged on as a full admin, right?
Can't you use a less hazardous approach for a "file picker" than this?
Why you call what I am doing is weird ? Don't you right click on a file and call the Winzip that way ? can't you right click a file and say open with notepad++ ? why you don't find these programs weird ?
If you checked the above code you will see nothing is weird in what I am doing !
By the way it's not the only way that my program works, it has a button browse to select files ( based on opendialog) and you can also Drag and Drop the files , but my idea was to add additional function that allow user to right click on any file like notepad++ or winzip or others work and it will send this file to my application (additionnal way to add files and not the only one), so I can't understand why you call this weird !
As for registry hack ! if you call adding a key to the registry is registry hack than yes I am adding a key to the registry, but all program does, so what is wrong in that too ?
Yes am working it on XP, but any other program that need installation in win7 will need the admin rights so why it's only my application that you and find it weird ? Can you install any other application that needs to register dll or installation without admin rights ?
Talking about Win7 why it force me to have admin rights ? I need run as administrator to be able to add something to the registry ? my exe won't run at all or only the option of adding it to the registry needs admin rights ?
By the way, to add my application to right click it's just an option so the user can check it and if he is not admin, this option can't be activated !
I am disappointed from this reply ! Why considering what I am doing is wrong instead of providing a helpfull answer or simply telling I can't provide you help for that ?
Anyway, thanks for your help
Re: MultiThreading advice
Quote:
Originally Posted by
RhinoBull
I just read it again and realized you said "does" instead of expected [by me at least] "does not".
When programming language supports some functionality natively it typically offers class or control that does it.
Everything else is just a trick that more or less advanced programmer can do.
In fact lots of things we did in VB6 were tricks based. Examples of such tricks could be "extended combo" with larger dropdown; controling form's border at runtime; etc, etc, etc...
You may argue, call it however you wish but those are NOT native functions - this also applies to multithreading.
All we do (or did for that matter) was extending language capabilities and by no mean we were using any of its native functions.
Yeah. Right. Whatever. :rolleyes:
This right in the manual: Creating a Multithreaded Test Application
