On Oct 2, 7:52 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> A CWinApp in a COM-object is not good. But if it's required, it
> shouldn't cause much problems (depending on your InitInstance).
> If that's all your InitInstance is doing, then that's ok.
> And make sure that you don't have any global objects which do something
> in their constructors.
I agree using a CWinApp is odd - it's not my code ;) - and I can't see
exactly why it was done that way. I've gone through the code as best I
can and can't find any suspicious initializations
> In the settings dialog, activate the option:
> Settings->Icon overlays->Show overlays and context menu items only in
Changing this doesn't make any difference. The loader lock errors
Since TortoiseSVN is all native code, as is the DLL where the problem
occurs it's looking increasingly likely that this is either a false
positive from Visual Studio, or the problem is somewhere else
entirely. Not sure how I'm going to track it down though. So far the
presence/absence of TortoiseSVN is the only thing that seems to affect
The only other idea that I can come up with at the moment is that this
is some kind of timing issue. Whilst my app isn't multithreaded I know
the .NET runtimes have background threads (e.g for the garbage
collector). Maybe one of these is trying to run something in the
background whilst the DLL still has the loader lock. Have you made any
changes since 1.4.8 that could significantly affect the time it takes
to load/initialize the DLLs? That said the behavior is quite
consistent, which would be unusual for a timing issue.
I'm going to have to see if I can reproduce this in a simpler example.
Just out of curiosity, do the TortoiseSVN DLLs get loaded into all
processes or does the app need to do/depend on something to cause them
to be brought in?
Thanks again for your help on this.
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-10-03 19:30:53 CEST