Re: Issue tracker authoring and conflict of DLLs

On 15.07.2013 17:59, Fernando Najera wrote:
> Hello,
>
> I am currently developing an issue tracker plugin to be used with the different Tortoises out there. My main testing platform is TortoiseHg, and there my plugin runs ok. But when testing against TSvn, I ran into problems.
>
> After a good number of hours of debugging, and to make the story short, the issue is that the commit dialog of TSvn uses Scintilla, and my plugin too, and that creates all kind of problems. Furthermore, if I invoke the options dialog from the Tsvn Settings dialog (where Scintilla is not used), then my plugin calls Scintilla without problems.
>
> In particular, I use Scintilla.NET, which in 64-bit environments expects the dll "SciLexer64.dll", whereas the version that TSvn ships for 64-bit environments is "SciLexer.dll".
>
> When my plugin loads SciLexer64.dll, it is taken as a new library, so in the DllMain it tries to register a couple of classes with RegisterClassEx(), and the calls fail with error 1410 (class already exists). This prevents SciLexer64.dll to load, and my plugin fails there.
>
> I guess that, if I modified Scintilla.NET to load SciLexer.dll, it would then reuse the one that TSvn uses instead of the one I supply, and that *might* work. I say "might" because, even if the .dlls were named the same, the versions are (or could be) different, and then though the plugin loads and shows the component, heaven knows what kind of problems I could face then. I think this is what already happens in 32-bit environments, where some of my users said the plugin "works".
>
> My question is: is there any "good" way to create a Tortoise issue tracker plugin that uses Scintilla and that could interoperate with all the Tortoises, even if they already load some Scintilla in the process where the plugin is loaded?
>
> The only solution I can think of would be that the plugin IBugTraqProvider2 spawns a new process that shows the UI, waits for its termination and then passes the result to Tortoise. But it seems too complicated... Is there any other way that I am missing?
>
> Note: I address this question here and not in the lists of Scintilla because the problem seems to me a bit more general (any dll/component that TSvn might be using and my plugin uses too could potentially lead to this kind of conflict).

I don't think it's possible to use two different versions of Scintilla
in the same process. At least not without patching Scintilla directly.

You could change the function
bool ScintillaWin::Register(HINSTANCE hInstance_)
in the file scintilla\win32\ScintillaWin.cxx
so that when it registers the window class it uses another name:
                wndclass.lpszClassName = L"ScintillaCustom";

Other than that, you're only option would be to use the same version of
Scintilla that TSVN uses.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3060515
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].