I work for a company that employs both Linux & Windows programmers/developers.
When we got wind of PhpED we hoped that this might be something that could help us in our dilemma:

We like to work on our servers directly. (Today we do this via Linux and Windows editors like Ultra Edit.)
What we'd like to avoid is two people opening the same file and write over each others work.

As I understand it you can lock and open a file that's on the server in the Explorer mode.
You edit it and nobody else but you can save it while it's locked.

I've searched the settings in vain for some kind of option to lock the file by default when you open it. Is this possible?
(It would also be nice if the file was unlocked if it's closed again, but the former option is the very thing that will make or break PhpED for us.)

Thanks in advande for any feed back!

locking across network is not supported by protocols used for getting/saving files, such as ftp, sftp or webdav.
Latter supports "logical" locking. It means that while all other people are using webdav, they will get notifications that file is locked. But I'm not sure that it's a good approach at all.
Software developers should use source control systems like SVN, CVS, Visual Source Safe or PVCS (you'll find much more if you want to).
SVN and CVS are cross-platform systems so no problems will happen if half of people are working under Windows while the others are under Linux.
Each developer should have his/her own virtual host to work independently, and have a script (I prefer shell script) that gets the most recent (or specified by tag) snapshot from the source control repository in to his own private directory (NO FILE SHARING AMONG DEVELOPERS, other than through source control!). Then work with this private copy as usual. After some certain piece of work is done and preliminary tests are okay, repository should be updated with his/her changes so the others will chance to get those sources (changes), and so forth.

Hi dmitri, and thanks for your reply!

I get what you're saying and where you're coming from. Don't mean to invent the wheel all over again but we work differently, as we have servers-a-plenty at our disposal and our development team are all located in the same office.

Here's how we work:
1. Files are edited directly on a local development server
2. Changes are tested...
3. ...approved or removed.
4. Working edits are submitted through CVS and published to the public server

Our problem, and why we're looking at PhpED, is finding a way to lock files as hassle-free as possible.
Our low-tech solution of simply asking each other (by hollering across a room or via ICQ/AIM) if someone is working in the particular file you want - is understandably tiresome.

All we really need is an app of some kind (like PhpED) that everyone can use to access and lock/unlock files, without risking to overwrite someone elses work.

PhpED can do that for us, but:
1. Files aren't automatically locked when they are opened (which we'd love to see)
2. We probably won't use the other 99% of the of PhpED, which is a shame

Perhaps someone here has an alternative idea for a Linux/Windows solution for us?

We don't mind paying for PhpED, even if we only use 1% of it's capability, if it had only locked files automatically when they are opened.

personally I'm working as software developer and designer since 1988 and all my experience proves that each developer regardless how team is big, should work as independently as possible.
Say somebody work on a low level routine (say DB aware level) and needs to change something. It means that his/her files will be broken for some time while changes are not finished. What would other people do during this time? Certainly they can be informed by ICQ or AIM, but it's a contraproductive way. They don't need to be informed they just need old sources that work until new are tested and committed to the repository.
To me team-working on a shared project directory is the same as working with shared browser - somebody enters URL, somebody enters button, somebody reads. Works but very inefficiently. If you really need it, use WebDav to lock files. It's available in PhpED.

Again, I hear what you're saying and I'm hardly one to argue having only 10 years of experience... but I'm gonna.

No but seriously, I've worked in the way you describe as well, which in some projects are vital to the success of the end product.

However, what we need this particular solution for are smaller projects where each edit reprecents at most a couple of hours of work. Ideas need to be bounced back and fourth within the development team and it's vital to the process that everyone is looking at the same thing during the discussion. We need to be able to edit and test changes with a minimum of extra clicks.

So... yes. We could use virtual hosts for each emmber of the team anyway. Upload changes to the local server for review and discussion, and then publish it to the public server once everyone's looked at it. But it's an extra step that in this case we don't particularly need.

Still, thanks for your input! It's nice to visit a support forum where you're able to bounce ideas off the actual developers of the product.

file locks just aren't good
If we locked the files that we open, it would be quite difficult to use external tools writing to the files, like for example cvs (checkout). Add there performance and stability. Samba may not support locking on some platforms or become unstable with many locks. Windows may fail to lock files too, it uses delayed locks (lazy locks) and may take long to escalate real locks when needed or fail to do so. To me it looks like file locks may bring more problems than solve . I'd also mention that some people said thanks that we do not lock files opened in the editor .
I know what you're talking about too and I was quite lazy to setup repositories for each projects of 10-15 files But finally realized that there are many good benefits with source control systems, not available otherwise. Just a little example. One project was not touched for 3years. Then one guy got his task to make a few changes and after a week or so we found that project became unstable. Nobody of us remembered the project structure and related stuff. With source control we easily found all changes and it appeared that the problems were not added recently, they were there all the time. Without sourcecontrol we would just blame the contractor who made all changes recently .
You said "with minimum extra clicks". Well, for editing and local testing, sourcecontrol is not needed. You already checked out files to your home dir and are working with them. What would you need to click? Just nothing. Extra clicks are needed 1) to checkout at the very beginning and 2) to update repository with changes, say every evening, or morning. In other words one extra click a day. What are we talking about?