Hi,
is there a way to add another button to have a "Run to breakpoint"?
It's something more then "Step over" and "Step out" .

In other IDEs its name I remember is "Continue". The effect is to continue the debug until it reaches a breakpoint of a user input request.

It's not required, b'ze [Run In Debugger] button plays this role. Once debug session is started, clicking on ths button just continues script until it finishes or hits a breakpoint.

yer ddmitrie you're ok.
it seemed that clicking that button the debug session restarted again from the beginning.
I had some troubles with notice alerts.

Thanks!

Actually it can not restart from the beginning if debug session is already started (in other words when "Stop" button is red).

PLEASE NOTE, some "fatal errors" (such as compile-time errors, syntax errors etc) may stop execution. In this case IDE shows Error message and stop the session. In this case pressing Run would run a new session.

Are you sure it works in this manner if the breakpoint is in another file?
It seems not...

I start the execution in index.php, I've the breakpoint in the first line of subs.php which is required from index.php
The debugger stops at the first line of index.php, when I click again on the debug button the script runs until it ends, without stopping at the breakpoint in subs.php

If I debug step by step I can reach the breakpoint...

Yes I'm sure it works in this manner regardless breakopoints are set in current file or not. As soon as a breakpoint hit, debugger pauses execution and returns control to the IDE.
If you're experiencing problems and want people there to help you, please submit some more details on what you're doing. In particular it would make sense to know the project (if any) settings, server environment, php version, php settings, phpinfo output etc. Alternatively you may want to contact NuSphere Support dept.

now I'm out of office, I'll install the registerd version (not eval) and then contact the support if it doesn't work as expected.
So I'll test your advanced support

Thanks for the moment.

hi ddmitrie,
I'm again in my office and here I've phped (not eval) build 4048

The "run to breakpoint" for me doesn't work.

Here is my code:

1) index.php
... some code...
require "a.php".
... some code...

2) a.php
... some code...
require "b.php".
... some code...

3) b.php
... some code...
breakpoint
echo "Hi Guy!"


I press F9 (Run in debugger) the debugger stops at the first line of index.php then I press again F9 (Run in debugger) and the debugger runs without stopping at the breakpoint in b.php (but I can see the text echo(ed) "Hi Guy!"


I've just made another test: after the debugger stops at the first row of index.php I've pressed F4 (Run to cursor) in b.php, but the debugger hasn't stopped in b.php


The only way to reach b.php during the debugging is to make a step by step dubug (with F7 and F


Could you please help?

I think it's an high priority bug

The main reason for such faults is that when a cache/accelerator works php does not execute internal byte code through its own loop and therefore can not be intercepted by debugger.

Check if you have php accelerators and/or caches installed in php.ini.

yes you're right.

I use eAccellerator to use shared memory and semaphores; have you some suggestion on how to disable script caching just during the debug?

Please consult with eAccellerator guys. As far as I remember their module checks for compatibility with other extensions and with DBG in particular.
As the best scenario, I'd prefer if the contact me and we'd solve the problem together (disable caching if debug session is requested).
Meanwhile, the only way is to comment out this extension in php.ini.

To me it would make sense to avoid using caches in a development server where developers perform debugging. What do you think?

ddmitrie yes I think it's very important to disable caching in a development server; btw I need eAccelerator on the dev server too because I use semaphores and shared memory with the methods of EA. They seems to work better then shmop_ of php (and with less risks of deadlock due to script crashes)
At the moment I've seen that disabling eAccelerator in php.ini the sem and shm function continues to work, so for the moment it's ok.