Project menu bug

[corelon]

Hello,

When I select New Project from the Project menu the program hangs. I am using the latest beta.

Regards,

Nick Tzanos

[jps]

Does it get to the point of showing you a Save As dialog?

[corelon]

It is at this point that it hangs. It tries to open the Save As dialog, but it shows that without the buttons (it shows empty "holes" instead of the button) and the whole program become unresponsive.

Regards,

Nick Tzanos

[jps]

Do you have TortoiseHg installed by any chance? It installs a python-using shell extension, which breaks file dialogs in any python using application. Do the normal open/save dialogs work for you?

File dialogs have been one of the most troublesome parts of Sublime Text, in terms of number of issues reported - I believe it's a fundamental issue with the way Windows works: foreign DLLs get loaded each time a file dialog is displayed. I suspect the only way to reliably handle them is to spawn a new process just to show the dialog, so if it does fall over, at least it won't effect Sublime.

[corelon]

You are right. Not even normal save open dialogs work. I do have TortoiseHg installed, and I really need it, so it would be really inconvenient to uninstall it.
I had/have problems with PyScripter, WindIDE (and probably some other that I do not remember) for the same reason.
PyScripter has a workaround for this letting you declare in the command line which python dll to use. For some others I solved the problem by installing python2.6 and made it the default python, so TortoiseHg which loads a (custom?) python25.dll is no longer an issue)

Could you please implement a feature like PyScripter's?

It uses --PYTHON25 to tell it which python version to use
and --PYTHONDLLPATH to tell it which python DLL to use.

This really saved me.

Kind regards,

Nick Tzanos

P.S. The DLL hell problem of windows is really annoying, so I always believed that having the necessary DLLs loaded from the program folder by default (before the system wide setting for the specific DLL) is the way to solve this with the expense of some extra space. I still remember the awful problem with MFC42.DLL and its numerous versions. But still a command line switch like the one above is the best solution as you explicitly know which DLL the program is using.

[corelon]

Hello again,

Did you manage to find a solution for the problem with TortoiseHg? The solution that PyScripter follows works quite well.
Maybe even changing the python version that Sublime uses (maybe 2.6) would solve the issue, but still I think that a way to tell Sublime to use a specific python dll would be optimal.
Please fix this when you get the time, as I can only use sublime to only edit and save text, but I cannot use the open and save dialogs at all (or projects dialog)

Kind regards,

Nick Tzanos

[jps]

There's no TortoiseHg workaround yet, no.

The only foolproof way to solve this that I know of is to spawn a new process to handle the open and save dialogs, so that way when broken shell extensions like TortoiseHg try to load interfering DLLs, they won't interact with any in the host process.

I'm reluctant to add anything along the lines of a --PYTHON25 command line switch, it simply shouldn't be required: Sublime Text already uses its own private python25.dll.

I do have a task on the todo list to implement spawning a new process for open and save dialogs. I also have an item to upgrade to python 2.6, which would be a short term fix at least.

[corelon]

Hello again,

For the moment I uninstalled TortoiseHg. I installed CuteHg which still requires the command line but offers a very nice GUI. What really nags me is that I have seen long threads about this problem in many forums, like Sublime's here, WingIDE and PyScripter, but none in TortoiseHg's forums, which can only mean that the guys over there, think that since THEIR app works there is nothing to be done, while it's THEIR app that causes all these problems that other developers need to find a workaround for.

Anyhow, thanks for the update.

Nick

[SteveCooperOrg]

Looks like the TortoiseHg guys have made this a priority for the 0.8 release of THG. The current version is 0.7.5, and I think the intention is to release 0.8 in July.

http://bitbucket.org/tortoisehg/stable/ ... her-python

I'm finding it annoying, too -- have taken off TortoiseHg for now, but will have a play to see if I can find a compromise position or workaround.

[SteveCooperOrg]

... if I can find a compromise position or workaround.

My workaround so far;

Install the Mercurial command line tools (Mercurial 1.2.1, not TortoiseHg 0.7.5). This doesn't install the misbehaving shell extension. You get to use Mercurial, but only over command line. Maybe a ST plugin would be advantageous here, allowing you to do pushes, pulls, merges and commits? I've already done a rudimentary SVN plugin which I used regularly, so something should be possible.

Once you've installed the Mercurial tools, you should be basically good to go, except that SSH access needs to be configured. Where TortoiseHg installs TortoisePlink.exe, the Mercurial install does not. You can get TortoisePlink by installing TortoiseSVN, and then adding this to your mercurial.ini file;

Code: Select all

[ui]
; secure shell.
ssh="C:\Program Files\TortoiseSVN\bin\tortoiseplink" -ssh


That should be enough to allow Hg and ST to coexist without too much grief.