Hello,

Please could you tell me the exact method for setting conditional breakpoints?

I tried to use the Breakpoints properties dialog, opened by right clicking on a breakpoint, which opens the following dialog:



In this dialog, I can write my expression (here $ST->id == 1002), then I close the dialog, but if I reopen it right after,
the expression is no longer there, and the Expression input item is blank.

I also tried to set my expression in the Breakpoints list window, where all breakpoints are listed one per line, but the result is the same:
whatever I write there disappears nearly immediately (there may be a 1/10 second delay, however).

I am using CLI mode with SFTP connection (but I already had the same issue using Samba connection) if it matters.

Is the syntax of my expression correct?
I don't get any arror message however.

Gingko

Hmm, interesting effect. Location inputs are disabled, so it's just a regular positioned breakpoint rather than global one.
Condition expression shouldn't disappear in any case even if it's syntactically incorrect but it's absolutely correct in your case

Chances it's effect of the remote project? Can you reproduce with a local one, without samba or SFTP?
Is there any connection problems with SFTP?
When you get it reproduced with Samba, is the file name shown in Windows Share style like \\host\share\folder\file or using regular disk name S:\folder\file?

I'll check myself too, a little later though.

PS thanks for adding so many styles to your post, but they were not really needed to read your post

I always use remote projects, I never use PHP on Windows, meaning that I will have to build a new local project from scratch if I want to reproduce this locally.
Maybe I will do that a little later too though.

Anyway, aside of that, I must say that I have a lot of problems with breakpoints that I find very hard to even define clearly.
Sometimes they work, sometimes not, sometimes they work only if set during the current launch and not in the next one, and so on, I will certainly come back later with this.
I already described some of them in this topic too.

This is at the point that I often find safer to include DebugBreak() instructions inside my code rather than using breakpoints, which is certainly a good workaround, but I doubt this is the point of having a breakpoints feature inside PhpED.

I think that you would probably need to run a full regression testing sequence about them.


Many people put flowers inside their house.
I don't think that one could see that they are strictly needed either.

Gingko

Sorry, I didn't reproduce the problem with neither local nor remote projects running under Windows and Linux using pretty standard configurations. Also I have to say that we didn't get any recent reports about problems with breakpoints. Taking into account how many customers we have, I doubt the problem with breakpoints is common. So this all sounds like there is something specific to your platform/environment/configuration.
In order to find what causes the problem, I'd highly recommend you to try local projects first. It will be much easier to deal with the problem if you exclude network from the equation.
Also you can try to a) remove / disable various caches -- including but not limited to -- php opcode cache, web server cache (if any), project framework cache. Problem with caches is -- if cache is in effect, actual script may not be executed at all, so debugger will not get cache to break execution -- because there is no script execution at all, but rather cached content brought up. In case of php opcode cache, it's more complicated, but still debugger is bypassed in many ways so if if you want to debug php you'd turn it off. b) if you use php as fcgi module, make sure that the fcgi driver has long enough timeout. Same goes to the web server and php itself. c) increase logging level -- for php, for web server itself and for fcgi driver in particular, and if you're not lucky with local projects -- meaning they work stable -- and you're still experiencing problems with remote ones -- increase logging for sshd daemon. As soon as you reproduce the problem, check all the logs. Don't forget to make sure that correspond to the time when the problem arose.
Let me know if you find something. I'll be happy to help.