Forum: Multi-Language Add-In for VB6

Deadlock on closing

Posted by elcoelettronica on Mon 20 of Feb, 2012 08:31 GMT

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

Reads: 42960
Link
Posted by elcoelettronica on Fri 24 of Feb, 2012 10:16 GMT
up!
Link
Posted by Phil on Sun 26 of Feb, 2012 13:49 GMT 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

Link
Posted by elcoelettronica on Mon 27 of Feb, 2012 07:17 GMT

> 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

Link
Posted by elcoelettronica on Tue 28 of Feb, 2012 10:59 GMT

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?

Link
Posted by Phil on Tue 28 of Feb, 2012 22:34 GMT 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

Link