Right, not sure if this is a bug or whether PHPed has always exhibited this behaviour, but I hope someone can confirm this. I'm running build 5210 on Vista ultimate.

When I give another app focus and then click back on the PHPed window anywhere in my code, the caret position does not move to where I've clicked - it just gives the window focus and I have to click again to get the caret to move to where I'm clicking. This is particularly annoying when I have multiple copy/paste operations that are carried out using the mouse from another app into PHPed as I end up pasting the code into the wrong place! It's such a trivial thing but I'm sure it never used to do this.

Is it my imagination? Any ideas?

Chris

This was a feature request and is implemented in version 5.2.
I also prefer the previous way. So we are at least 2, which makes me hoping we can switch it back in IDE Settings in the next version.

KASI

Ah right I see - thanks very much for that kasi. Didn't think it would be requested as a feature! Also, following on from that thread, I understand that it may be accepted behaviour for a word processor, but I can't honestly see it as being very productive feature for a coding application.

I would also agree that it should be offered as an optional feature!

Chris

I personally can't stand having the state of the editor disturbed just because I'm trying to bring PhpED to the front. If, for instance, I just took the time to make a selection, I don't want that selection blown away when I switch back in. You may save a little time by not having to click twice, but you waste a lot more time trying to find an area of the window that it's safe to click on (such as the title bar), and moving other windows around to facilitate that. And, I don't want the IDE doing any of the other things on me that it's prone to doing when you move the cursor, like those pointed out by Dmitri in the other thread.

As for the comparison to the word processor, I think that it's not only relevant (PhpED's central feature, after all, is the editor), but that PhpED actually has far *more* reasons to behave this way, since cursor movement can trigger so many actions. Passing the clicks through means that a click to change application focus can kick off a variety of actions in the IDE, which doesn't make sense since the latter isn't the intent of the former.

You make a good argument and I can certainly see the case for it, and perhaps you are right in the comparison to a word processor.

I think my major gripe is not with the actual behaviour itself and rather the change from the existing that I've become used to (at least in the case of phped). I'm not opposed to (re)learning behaviour that may or may not conform to OS/GUI standards (e.g. the move/copy behaviour in the explorer pane for example) but it seems to me that this particular issue is a 50/50 on how much more productive it is over how much it reduces unwanted actions, and as such should be offered as an option rather than as the de-facto.

Of course it's a small issue and I don't want to make a big deal about it. Just wanted to check I wasn't imagining it had changed!!