Forum: Multi-Language Add-In for VB6

Deadlock on closing

Hi,
when i close my application, the process eats all my cpu.
I try to explain it better.
The bug happens in VB6 IDE and in the final compiled application both.

In VB6, debugging, i noticied that the problem happens after "set
ml_runtimesupport = nothing" inside a class when i tried to close my
application.

I'm using version 6.03.0016

Roberto

up!
Germany

I'm sorry, I do not know this problem.

I can't see why the line "set ml_runtimesupport = nothing" would cause a problem, since it is only freeing an object.

Does it make a difference if you comment this line out?

Phil

> I'm sorry, I do not know this problem.
>
> I can't see why the line "set ml_runtimesupport = nothing" would cause a problem, since it is only freeing an object.
>
> Does it make a difference if you comment this line out?
>
> Phil

If i comment this line out the deadlock still happens.
Could be a memory issue on runtime that cause hangup when freeing memory?
Could i quickly try without your dll?
Let me know if i can provide to you any other useful information.
Bye
Roberto

I solve the problem!

In a class without messages, there was a creation of ml_RuntimeSupport (useless in this class, autogenerated by your plugin).

This class is used a lot (6000+ istances).

Probably, i guess, there was a ram corruption.

I solved the issue deleting the ml_runtimesupport from that class.

have you ever seen a stuff like this?

Germany

Well done! It is good to hear that you have solved the problem.

If you completely remove the lines which the Add-In added, then the Add-In will probably add them back. However, if you comment them out, I think the Add-In be fooled, and will not add them again.

There is no question, that the Add-In adds this code to classes where it is not really required.

Run-time-language switching requires an event in every form and usercontrol, to call the method ml_UpdateControls().

In a class, all the event does, is to save the new language ID, so that it is used for subsequent calls to ml_string(). However, since the language ID is stored in a common variable in the MlString module, it is unnecessary to do in every class. It might be unnecessary to do it in any of them.

The trouble is, that the Add-In can't figure this out for itself. In a Dll project, there might be only a single object, which would then have to handle the language changed event. It therefore adds an event handler to all places where it just might be required.

This might have been a bad design decision, I'm not sure. However, I am not going to make any significant changes to the VB6 Add-In now.

Phil