views:

731

answers:

3

Hi guys, i have a legacy massive vb6 editor with plenty of 3rd party libraries and controls and recently there is a need to set it up to make it multi thread so i can run a few other forms independently from the main editor form. Basically there's minimum communication between these other forms and the main editor except for running the other forms on a click of a button from the main page.

So from a lot of googling i found a method which converts the current app into a multi threading one by setting it up as an activex exe and adding a class set to global-multi-use to allow this to happen. Now while doing editing and testing via debugging mode, i found that when i exit a lot of weird crash will happen sometimes.

'main.frm - button click call
'On the button click, create a new object
Set obj = CreateObject("MyApp.clsThread")
Call obj.NewThread

'clsThread
' Create a new form and load it to run on a new thread
Public Sub NewThread()
    Dim frm As Object
    Set frm = New frmDogbert
    Load frmDogbert
    frm.show
    Set frm = Nothing
End Sub

So what do i absolutely must know when i do this,i.e. potential problems,etc?, as i'm fearing that the app seems to be getting more unstable. Or is there a better way to do this?

Updates:

Instead of forcefully hacking my app into a pseudo multithreading app, i've taken the advice from the good people here and refactor out the component into standard exe and reverted back my app to a standard exe and call them via shell. Works beautifully :)

Thanks

+1  A: 

Can you clarify the question a bit? I don't understand why it needs to be multi-threaded? Why can't you just display the forms non-modal, then they will all be visible and responsive at the same time. Unless you have some background processing operating all the time in your main form, which sounds unlikely from your question as it would lock up the main form as well as the others.


Melaos says: Well the main editor frm is the main thing here and I need to allow the user to run additional forms to do some other stuff like uploading things to our server and convert video files to other formats. And these forms use shell to call other exes. And the running time takes quite a while.


In that case I recommend making the other forms into separate EXEs rather than use multithreading, which is difficult. You say there's little communication from the main form to the subforms - it just shows them. Therefore you don't even need to make the subforms ActiveX EXEs. Just make them standard EXEs and shell them from the main form.

MarkJ
@MarkJ Well the main editor frm is the main thing here and i need to allow the user to run additional forms to do some other stuff like uploading things to our server and convert video files to other formats. And these forms use shell to call other exes. And the running time takes quite a while.
melaos
@MarkJ, thanks as long as i can run the main editor form and these other childs form concurrently, there won't be a problem. thanks.
melaos
+1  A: 

Visual Basic 6 is not multi threading in of itself. The difference in the multi-tasking behavior between a ActiveX EXE and a ActiveX DLL is only apparent when referenced from another VB6 EXE. Objects instantiated from a Global Multi-Use Class defined in a ActiveX EXE run in their own context. Object instantiated from a ActiveX DLL are run in the context of the calling EXE.

Now multi-threading can be hacked into VB6 but it is very touchy and has a lot of don't (for example you can't use the stop button in the IDE to stop a debugging session or the program will crash).

What a ActiveX EXE is good is for spawning a separate but related instance that can run separately without halting the main program. Based on your brief description I would say your best best is to keep your EXE as is but more the forms/modules/classes to a separate EXE and have the original EXE reference the ActiveX EXE.

Note that you don't have to compile down to .EXE you can change the extension to .DLL and it is still a activeX EXE. You do this so that the user doesn't mistakely run the ActiveX EXE by itself.

RS Conley
@RS thanks for the suggestion, since i'm making a DLL is it better/stable to make it DLL from .net? thanks.
melaos
No! He doesn't mean you should make a DLL. He means you should make an EXE in the usual way, and then change the file extension to DLL. This would discourage users from running the EXE.
MarkJ
Although if you provide Start menu and Desktop shortcuts to the EXE, hopefully the users won't poke around your application directory running EXEs at random. We have a number of ActiveX EXEs in our app directories but no user has every run them yet. If they did I'd say they deserve errors!
MarkJ
We've done this with one of our legacy applications i.e. move stuff out in to separate EXEs - it works well. To prevent the users running the EXE's standalone, we pass in a known command line option from the main app, and then execute if recognised.
Miles D
@Melaos MarkJ is correct in that I was talking about just renaming the extension from EXE to DLL. However if you are careful you may be able to create and reference a .NET that handles the multitasking. I feel this would be overkill for an independent form.
RS Conley
@RS, @MarkJ, thanks guys you just help me did another paradigm shift. wish i could select both of these as answer but i'm going with this one, since the comments contains big chunk of the meat too. thanks!!
melaos
If you have a Sub Main in your ActiveX EXE, you can check to see if the user is launching the app or if your program is launching it by checking App.StartMode on the first line of Main. E.g.: If App.StartMode = vbSModeStandalone Then Exit Sub (the other constant is vbSModeAutomation).
Mike Spross
A: 

Don't do it. Multithreading is incredibly complex to do correctly, even when using tools that are intended for it.

erikkallen