When in another application, if you click on a PhpED window to bring it to the front, the click is passed through and processed by PhpED. Often, these clicks, which I almost always perform with most of the target window obscured, cause something to change. This is most annoying in the edit area, where a selection may be lost or the insertion point moved (both of which, in turn, may catastrophically modify the undo/redo stack - doh!), but they can have annoying side-effects elsewhere, too.

It'd be much nicer if such background clicks were not passed through, but served simply to bring the window to the front.

Any chance?

I don't think it's an expected behaviour.
Suppose you have the IDE window overlapped in just one pixel in the right bottom corner by say Notepad which you even don't see.
In other words, whole the IDE is behind you and you click on a button (by purpose) and what? it will just bring the window forward and eat your click.

Well, Word--perhaps the most-used editor of all--works this way.

That said, I understand that it's very common in Windows. Here's an interesting write-up on click-through in Mac versus Windows, and some of the finer UI issues surrounding click-through:

http://daringfireball.net/2003/05/the_problems_with_clickthrough

Additionally, here are Apple's guidelines for click-through:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_4.html#//apple_ref/doc/uid/20000961-TPXREF20

I know we're talking about Windows here, not the Mac, but the logic they present is worth considering irrespective of platform.

And again, Word works this way. While most users don't touch most features of Word, this is one that nearly every user will deal with on a day-to-day basis.



That's why background windows have a different appearance - you know at a glance that the window is not the front-most and there's no confusion. (Though, Windows could do much better in this respect, such as with background selections - but that's just the usual lack of refinement from MS.)



Yes and no. Your click is not eaten (which implies it just disappears somehow without doing anything) - it performs the specific action of bringing a background window to the front. It's a clearly defined action that's predictable and tied to the visual status of the windows. I'll take this any day over a click-through system that can easily lead to data loss!

this alone would be enough to mention as a good reason.

implemented in PhpED v5.2

Is there a switch because I prefer the old behavior.
Best is do like Visual Studio (which is closer to PhpED than Word) and place the cursor (if possible) on the clicked position but do no further action.It is annoying to click twice into the edit-area (doing this too fast selects the word = 3. click) before start typing.

KASI

It's virtually impossible to move cursor and do not do any further actions.
There are too many actions bound to cursor movement... Just for example, text selection will be unselected, code navigator will be updated, even code completion may trigger and show another function arguments etc...

I thought you are specialized in doing the impossible ?
So what is about a switch Settings->IDE->clickthrough : true | false??

KASI