Hi
I have a ocx which works better with a native dll. But there are also other apps which work worse if this dll is set to native by default. OK, so I add a setting for the application which uses the ocx. Works. But there are many apps that use this ocx and the customer could even make his own. So it would be nice if I could have a dll override setting for just the ocx. Is this technically possible at all? Or is the app-level the only one for overrides? (I know, fixing wine would be even better, but I don't have the time nor the knowledge. )-: But I keep trying whenever I can :)
bye Fabi
Fabian Cenedese Cenedese@indel.ch writes:
I have a ocx which works better with a native dll. But there are also other apps which work worse if this dll is set to native by default. OK, so I add a setting for the application which uses the ocx. Works. But there are many apps that use this ocx and the customer could even make his own. So it would be nice if I could have a dll override setting for just the ocx. Is this technically possible at all? Or is the app-level the only one for overrides? (I know, fixing wine would be even better, but I don't have the time nor the knowledge. )-: But I keep trying whenever I can :)
Use the hole name including the suffix works.
ex. "hhctrl.ocx" = "builtin, native" or on the promt ]$ WINEDLLOVERRIDES='hhctrl.ocx=n' wine name.exe
mvh Acke
One hack you can do, If you have the Code for the OCX, is change the dll's name and compile against the new name. Now the OCX relyes on one dll and the rest of the code on another you can even run with two different dlls at the same time. Which is part of an answer to your original Q. What if One dll asks for "Native" while a second one asks for "builtin"? you see my point. (If you do not have Source Code for the OCX you will have to HEX patch the OCX's import table. Not very easy to do)
Free Life Boaz
Fabian Cenedese wrote:
Hi
I have a ocx which works better with a native dll. But there are also other apps which work worse if this dll is set to native by default. OK, so I add a setting for the application which uses the ocx. Works. But there are many apps that use this ocx and the customer could even make his own. So it would be nice if I could have a dll override setting for just the ocx. Is this technically possible at all? Or is the app-level the only one for overrides? (I know, fixing wine would be even better, but I don't have the time nor the knowledge. )-: But I keep trying whenever I can :)
bye Fabi
Fabian Cenedese wrote:
I have a ocx which works better with a native dll. But there are also other apps which work worse if this dll is set to native by default. OK, so I add a setting for the application which uses the ocx. Works. But there are many apps that use this ocx and the customer could even make his own. So it would be nice if I could have a dll override setting for just the ocx. Is this technically possible at all? Or is the app-level the only one for overrides? (I know, fixing wine would be even better, but I don't have the time nor the knowledge. )-: But I keep trying whenever I can :)
At 12:32 27.01.2004 +0200, Boaz Harrosh wrote: One hack you can do, If you have the Code for the OCX, is change the dll's name and compile against the new name. Now the OCX relyes on one dll and the rest of the code on another you can even run with two different dlls at the same time. Which is part of an answer to your original Q. What if One dll asks for "Native" while a second one asks for "builtin"? you see my point. (If you do not have Source Code for the OCX you will have to HEX patch the OCX's import table. Not very easy to do)
I do have the source code and renaming the dll is a nice idea. However I don't think that copying and renaming a Windows dll is a good thing :) I already thought that it wouldn't be possible as an embedded ocx will use the same dlls as the exe. So I will continue finding out what goes wrong with the wine dll. My next question is already coming up :)
Thanks.
bye Fabi
-
Acke Carlsson -
Boaz Harrosh -
Fabian Cenedese