Hello everyone,

I've been testing PhpED for a couple of days now. I've been using Macromedia Homesite for several years now and have always been missing the convenience and help in debugging an IDE can/should provide. Seems as if PhpED could make it as our new development platform. Good work!

Still there are some bugs or issues I'd like to discuss, maybe helping other people in evaluating the software. Unfortunately, I cannot describe all of them as precisely as I would like to. I've been using PhpED 3.2.1 Build 3239 eval on WinXP with a remote linux server (Debian, PHP4.1.2, PhpED-supplied DBG extension).

1. When debugging, PhpED tends to open a lot of files in an not always comprehensible manner. Sometimes it seems as if every file which is included by a script is opened, also if you don't "step into" it. This clutters up the file tab - debugging a more complex application gives me about 15 or 20 open files after just two or three requests.

2. I get an "Unexpected Error: Access violation at address 003B4EB1 in module 'phpED.exe'. Read of address 00000040." quite often. This seems to be somehow related to debugging and hitting files that have not yet been opened. You can ignore the error and continue working, however this causes PhpED to miss some of your requests, i. e. you need to reload files in the browser serveral times before PhpED intercepts one of the requests for debugging. Additionally, breakpoints are missed at random after that and the IDE stops on the first line of a script when debugging, even if told not to do so. After restarting the IDE everything works fine again, at least until the error pops up again.

3. When debugging, small blue dots are shown left of the code. However it seems as if not all of these marked lines are valid positions for breakpoints. Especially the lines marked with an * seem not to be valid breakpoints, although suggested.

function foo() { // *
if (true)
print 'foo'; // *
} // *

4. Starting a debug session (F9) with an external browser feels slow, it always takes a few seconds for the window to come up. This is much longer than the browser startup time. What might be the cause for that? I'm sitting right next to the maching running the Apache server.

5. The @ character is not working on German keyboards, this is a known issue.

6. I'm using the PEAR::DB classes in my application. When debugging, I always end up in one of the PEAR files after script execution (more precisely, in PEAR::_PEAR_call_destructors()). This is annoying, as I'll have to switch back to the file I've been editing before after each run. I think that after the debugger has finished, you should be at the same position in your code as you've been when you started it.

7. Is it possible to debug remote files accessible via FTP only (not Samba), using the remote server and not copying everything to local? How to specify the appropriate mapping? It seems as if PhPED was missing a "local file" then.

Thanks a lot for the support,
mp.

Concerning #1:

It seems as if PhpED tries to open every file directly requested by the browser plus the file where script execution ends. It might miss one of them, but reloading the corresponding frame/page will, hm, "work" .

E. g. I start debugging by calling a login form, which is posted to a login script; the browser is redirected to a frameset containing three frames. Now after that I have (without having set breakpoints, without "stopping on the first line after run", without stepping through the code!) six open files. PEAR.php is one of them, having focus as the _PEAR_call_destructors method has been called last. (This explains issue #6 above?) One of the frame scripts is "missing" (I don't want to see it at all ), but reloading the frame pops it up. That makes a total of seven windows before I even reached the interesting part of the code .

Concerning #7:
This is a FAQ and - if I get it right - not possible. I'd like to be able to debug files on a remote (production) server not running samba. Copying everything to local first is too expensive.

Also if you just want to edit the file (not running the debugger), you will have to make a local copy, edit that and publish it afterwards. You cannot edit files "purely remote", as it would be possible at least with Homesite.

mp

Concerning #7:
You don't need all the files be copied locally, but the files being debugged only.

Anyway, it's a normal practice when all files are kept and edited locally and sent to the web during a kind of sync. Especially if you use source-control system, you have no other choise .

Concernint #1:
It happens if you have frameset only. In order to debug such stuff you should add DBGSESSID argument to one of the scripts listed in FRAMESET and run frameset itself without debugger.

ad #1

Well, where's the point opening all those directly requested files if you don't "stop on the first line" and don't step into them?

That does not apply to framesets only, PhpED will open all files your browser requests?

This relates to #6 as it always opens the file where execution ends and leaves that one focussed. So you can't just change some lines, reload the file in the browser, switch back and continue; you will have to press Ctrl-F4 first to return to your position in code

mp

Would you show a sample script that replicates the problem ?
As far as I know PhpED does not open anything by its own intents
It opens only files where you step in.


Problem with Framesets has no relation to the above.
If you open a frameset, IE (or whatsoever browser) open all frames using independent HTTP connections and if you have DBGSESSID session cookie enabled, all they will get debug requests and therefore multiple debug sessions will attempt to start. PHPED 3.2 IDE can not handle more than just one debug session at a time.


Agreed. It's not too convenient to have last executed file opened at the end of debug session.
But why don't you use navigation bar ? It would bring you back to the original point easily.
Also, don't forget you can set "Default file to run" in the project settings.
While you have it set, you don't need to switch to anything.

Ddmitrie,

I really appreciate the support you're providing and the time you spend answering posts in this forum.


Try the following three scripts. Create a project for them, set test.php as the default file to run. "Close all files" and run the scripts in an external browser window by pressing F9 (don't set any breakpoints and make sure to disable "stop on first line after run"). Click the submit button in "test.php", and you'll get "Hello world". At least my PhpED installation has all three files open after that - even without using frames.




Assumed I've got a frameset, loading two php scripts. Now I'll set breakpoints in both of them. Reloading the frameset will miss the breakpoints in one of the two scripts, as the browser uses different connections? Which one will be missed is probably not predictable?


It's a matter of convenience. I would like to edit the code, press Ctrl-S to save it; switch to the browser; reload the frame or window; Alt-Tab to switch back to PhpED and continue working.

Otherwise, you'll have to remember the file name , find it in the tab. Especially difficult if a dozen of files has been opened by the debugger and "your" file scrolled out of sight. Besides that, you might have a couple of files with the same name (index.php...) Then you probably won't find the right one as fast as you can press Ctrl-F4 .

Your help is great and I highly appreciate it.
All the issues are addressed in phped 3.3 with dbg-2.16.3. Now you can debug frameset(s) easily