DBG Support???
Moderator: kfury77
Forum rules
Please try to follow these guidelines. This will help to receive faster and more accurate response.
Please try to follow these guidelines. This will help to receive faster and more accurate response.
- Check the Support section of the corresponding product first. Chances are you will find your answer there;
- Do not create new topics for already reported problems. Add your comments to the existing topics instead;
- Create separate topic for each problem request. Do NOT post a number of non-related problem reports in a single topic;
- Give your topic a meaningful title. Titles such as "A question," "Bug report" and "Help!" provide others no clue what your message is about;
- Include the version number of the software you are using;
- This is not an official customer support helpdesk. If you need a prompt and official response, please contact our support team directly instead. It may take a while until you receive a reply in the forum;
DBG Support???
Hello,
Do your products allow for DBG integration for debugging PHP scripts?
Thanks.
Chris
Do your products allow for DBG integration for debugging PHP scripts?
Thanks.
Chris
I would like to see this feature too, so I did some searching. And you're right, there isn't any documentation! :/
I did find this though: http://support.nusphere.com/viewtopic.p ... ght=delphi
You can access it through the COM interface.
Also, PHPEdit, which makes use of DBG and is written in Delphi, is GPL'd open source. Because it's GPL'd, you can't include the source in your program, but maybe you could sneek a peek to get an idea of how it works, then write your own code. I'm not sure if that's legal because it's kinda a fine line..... but... *shrug*
Thanks!
I did find this though: http://support.nusphere.com/viewtopic.p ... ght=delphi
You can access it through the COM interface.
Also, PHPEdit, which makes use of DBG and is written in Delphi, is GPL'd open source. Because it's GPL'd, you can't include the source in your program, but maybe you could sneek a peek to get an idea of how it works, then write your own code. I'm not sure if that's legal because it's kinda a fine line..... but... *shrug*
Thanks!
You can get the source for PHPEdit 0.8, which was released under the opensource QPL license here:admin wrote:Where do I get the source of PHPEdit?
http://www.waterproof.fr/action.php?id= ... rce&file=1
I assume that after the 0.8 release, the license was changed to non-opensource.
It appears to have support for the DBG interface in tools/dbg.
Yeah, I looked at the xdebug website the other night. They have some pretty extensive documentation.
http://xdebug.org
Thanks
http://xdebug.org
Thanks
There is also an opensource debugger called gubed at http://gubed.mccabe.nu. This one is interesting because it doesn't need to be installed, it's not a PHP-Module but PHP-scripts so you can just copy it to the webserver. It's integrated into quanta plus (which is gpl). Quanta has an interesting approach: they have a general debug plugin system so different plugins could be written.
What i personally would care for is remote debugging, so when debugging, a browser page opens and you can see the output of the webserver in the browser page. In the editor, all included PHP-files open automatically. When a link is clicked in the browser window, the new page is debugged as well. The browser window handles sessions, cookies, javascript, forms etc.. This browser window does not have to reside inside the editor, i think it's even better if you can open the page in your main browser. I think this is less confusing because you have the usual environment to view the page, and in the editor the code is always visible.
I'm looking forward to the next major release. A debugger would really be nice!
What i personally would care for is remote debugging, so when debugging, a browser page opens and you can see the output of the webserver in the browser page. In the editor, all included PHP-files open automatically. When a link is clicked in the browser window, the new page is debugged as well. The browser window handles sessions, cookies, javascript, forms etc.. This browser window does not have to reside inside the editor, i think it's even better if you can open the page in your main browser. I think this is less confusing because you have the usual environment to view the page, and in the editor the code is always visible.
I'm looking forward to the next major release. A debugger would really be nice!
- Karlis
- Site Admin
- Posts: 3605
- Joined: Mon Jul 15, 2002 5:24 pm
- Location: Riga, Latvia, Europe
- Contact:
flz,
I'll take a look at the debuger, however what you descibed 9runing pages in an external browser, e.g. Internet Explorer or Mozilla) while debugging with the editor is not quite possible as the editor can not talk to Mozilla or Internet Explorer at least not by the technology currently used. In the best case (if we manage to implement the debugger) it would be possible to run scripts in the editors' internal preview window.
I'll take a look at the debuger, however what you descibed 9runing pages in an external browser, e.g. Internet Explorer or Mozilla) while debugging with the editor is not quite possible as the editor can not talk to Mozilla or Internet Explorer at least not by the technology currently used. In the best case (if we manage to implement the debugger) it would be possible to run scripts in the editors' internal preview window.
Thank you for the infos. About running scripts in an external browser, the debugging client doesn't necessarily have to talk to the browser window, it can communicate with the debug server, and the browser gives the debug command to the debug server, which is located at the webserver.
For example with the gubed debugger, which consists of php-scripts there are two ways to achieve this:
- including a special gubed script in the page to be debugged.
- passing the script to be debugged as a parameter to gubed.
The debug server then tries to establish a connection to the debug client, starts a debug session and sends the output to the browser. A plugin for firefox exists, which automatically does the task of rewriting the urls (didn't try this yet).
With xdebug, it's more easy because xdebug is installed as a module on the webserver, so you can give the command to start a debug session via a special parameter (?XDEBUG_SESSION_START=user) attached to the script you want to debug. The command is then stored in a cookie so subsequent pages are also debugged.
There is an editor which uses remote debugging with xdebug, however i didn't get it to run smoothly, i can't tell whether this was the editors, xdebugs or my own fault. With the gubed debugger remote debugging works well (as far as i can see), as the gubed client doesn't have an internal preview window, this is the only way to run gubed anyway.
For example with the gubed debugger, which consists of php-scripts there are two ways to achieve this:
- including a special gubed script in the page to be debugged.
- passing the script to be debugged as a parameter to gubed.
The debug server then tries to establish a connection to the debug client, starts a debug session and sends the output to the browser. A plugin for firefox exists, which automatically does the task of rewriting the urls (didn't try this yet).
With xdebug, it's more easy because xdebug is installed as a module on the webserver, so you can give the command to start a debug session via a special parameter (?XDEBUG_SESSION_START=user) attached to the script you want to debug. The command is then stored in a cookie so subsequent pages are also debugged.
There is an editor which uses remote debugging with xdebug, however i didn't get it to run smoothly, i can't tell whether this was the editors, xdebugs or my own fault. With the gubed debugger remote debugging works well (as far as i can see), as the gubed client doesn't have an internal preview window, this is the only way to run gubed anyway.