I ran into a new problem with the DLL.
Using it from 2 different instances of a WIN-Standard-exe gives no problem.
Both sessions have their own memory-workspace and work side by side.
Now I get a different situation. I call newLISP.dll from an ActiveX component embedded in an HTML-file running in iexplorer. Now I run a second instance of iexplorer with the same HTML-file. Now I get errors complaining about protected symbols in my initialisation files. So it seems to use the same DLL/memory workspace. I see 2 instances of iexlorer in the process list but it maybe that the ActiveX-function share the same DLL.
The only solution which came to my mind, is to make unique newLISP.dll's for each instance on the fly to avoid this conflict.
Other idea's ?
>> make unique newLISP.dll's
Yes, that is what comes to my mind too, you could just copy to a different name. I think the reason is that the Active-X controls are all childs of the IE browser, so any new Active-X control will take the exisiting instance of newlisp.dll.
I wonder if this could work to your advantgage by sharing variables etc., or it may be dangerous and simply crash at some point, when two Active-X controls fiddle with the same memory in newLISP.
I also wonder if there is any option when importing DLLs in Active-X to force a new instance?
Lutz
Quote from: "Lutz"
But there are 2 instance of the IE browser in the process list. So the controls are a child of different main-processes.
Quote from: "Lutz"
I wonder if this could work to your advantgage by sharing variables etc., or it may be dangerous and simply crash at some point, when two Active-X controls fiddle with the same memory in newLISP.
Cannot think of a possible use.
I will make some further tests to get it to work.
It seems to be a general problem with the ActiveX running twice.
The ActiveX itself has problem and shares variables between 2 IE session.
Have to further rersearch.