Hi,

I've just installed version 4 and have found these bugs. I hope at least the urgent ones can be sorted out really soon.

Urgent Bugs
-----------

- when one page (e.g. a form) starts another page in the debugger, the new page no longer opens automatically - you have manually open it in phpEd.

- this also applies to non-php pages like css (which I have set up to be interpreted by php). They used to open and be debuggable, but now they don't, even though phpEd is still in debug mode.

- Find in Files produces a lot of unnecessary lines in the log saying it has skipped picture files and has found transliteration errors. This never used to happen.

- when running the debugger, every time I press F9 to run to the next breakpoint, all the debug windows close, then re-open when the breakpoint is reached. Also, the code explorer tab appears then disappears. I don't know whether all this happening is the cause, but it takes an age to get to the next breakpoint now, whereas before it just zipped to the breakpoint. Any ideas how to correct this?

- the debugger function keys e.g. F7, F8 etc. don't work unless the focus is on the code window, whereas they worked before no matter what windows had the focus. The previous way is so much more useable.

Other Bugs
----------

- when hovering over a variable in debugging mode and the variable has an & in it, the & doesn't show, however it does show in the locals window.

- when hovering over $HTTP_POST_FILES[$strFilename]["name"], the tooltip shows it as undefined, but it shows up correctly in the locals window.

- the 3rd line in the Searching dialog in 'Find in Files' says Seraching.

- when moving text in the editor, the leading tabs are replaced with spaces. The contents of the moved text really should be left as they were i.e. if there were tabs, then they should be left as tabs, not converted to spaces.

- the editor saves mouse and key presses and highlight and copy actions as undoable actions even when there hasn't been any real action. This is very annoying when trying to undo the real actions. Please stop it doing this.

- need to be able to switch between php and html even when the file extension is not .php.

- undone text should be left highlighted like most editors do.

- when you delete a tab using the backspace key, it deletes all the tabs back to the starting position of the previous line as well, instead of just one tab at a time.

Debbie

Thanks for your report.


Could you please submit code sample that will replicate the problem?



How did you do it?
If you work with SRV web server, you have to add an entry in Tools->Settings->SRV web server, "CGI handlers" table, where CSS should be associated with php.exe. If you work with Apache, check httpd.conf file and make sure php handles .css extension.
Then Tools->Settings->Associations, open list of extensions for php, add *.css there and remove *.css from the list for CSS type.



Hmm, what to do if some files are skipped (e.g. if their size is too big) ?



No. It should not happen. While IDE in debug session it keeps all debug windows shown. When one session is finished it returns back to "normal" layout where all debug windows are closed. As soon as new debug session is started it returns back debug windows. If you want them to be always shown, just select for example View->Debug windows->Locals while in Normal layout.

what hardware do you run IDE on?


It's known problem and will be fixed in update pack#1



got it.


Did you try to select all this text $HTTP_POST_FILES[$strFilename]["name"] in the editor then hover over?


known problem.


Could you please tell some more details about editor settings and editing actions performed ?


Not sure I understand it. Need more details on this issue.
Better if you contact me directly by email.


if extension is not .php but content is php, please add this extension to the list of extensions corresponding to PHP type in settings->tools->associations.


Sorry, what is "undone text" ?


Behaviour of TAB and BACKSPACE keys depends on the editor settings. If you have "BACKSPACE UNINDENT" turned on, it have to remove tabs until it reaches "unindented" column, otherwise it deletes whatsoever left to cursor one by one.

Perhaps there could be a checkbox "include errors, warnings, and notices in find results" ... I agree with her, it's useless information 90% of the time.

If it helps, I'm using WinXP Pro SP1, Apache 2.0.54, PHP 4.4, phpEd 4 build 4033, DBG 2.18.2 and Firefox 1.0.6.

I forgot to say it last time, but thanks for including some of my previous requests, like the multiple file upload, in version 4. phpEd is so much more usable now; not perfect yet, but very close. ;-D



I'm not sure what kind of code sample would illustrate this, but I'll try to explain further. It seems to be erratic - sometimes it happens and other times it works OK.

I have a page with a form, which calls another page via the form's action field and I would like to debug the second page. There are two points to make here:

1. The first page contains a call to a css file, which includes other css files (they contain some php statements but mainly css ones). All css files are interpreted by my Apache as being php files and so are fed to PHP. In previous versions of phpEd, it opened all these css files one at time, so I could debug them. Now, it only opens the first one, but if I manually open the next one while it is at a breakpoint, I can see the the highlighted breakpoint line.

2. The first page has a button to fire off the form. When I click it, sometimes phpEd flips to the front and opens the second page and sometimes it either stays on the browser and I have to manually flip to phpEd and open the page, or it does flip to the front, but doesn't open the page (the latter one happens more often). phpEd used to do this perfectly i.e. flip to the front and open the page at the first statement. I haven't yet been able to establish a pattern as to when and what situations cause this.

So, why does it no longer automatically flip to the front and/or open the pages that are being debugged?



Find In Files never used to produce all these superfluous lines. Why now? Surely, any file other than text files shouldn't need to be searched and we don't need to know about the ones that have been skipped. Size shouldn't matter either as we need all text files searched if we do a Find In Files search; files shouldn't treated differently because of their size.



I'm not talking about outside a debug session, I'm talking about when a debug session is running and I press F9 to run to the next breakpoint. What I'm saying is that it's really annoying having the layout flip backwards and forwards all the time. It's much better as it was - during the whole of the debug session, no matter whether F9 is pressed or not, the layout should stay the same.

I do understand the new concept of different layouts for normal/debug sessions and think it's lovely idea, but not when it flips between them during a debug session. This is maybe what is also causing the terrible slowdown in speed when F9 is pressed.



Are you going to fix it though?



OK, here's an example:

[tab][tab]Some text.

When you drag or copy this line to another location, it appears like this (assuming 4 spaces per tab):

........Some text.

The tabs should be left alone, not converted to spaces.



OK, this is probably my biggest peeve at the moment. The undo history shouldn't store every mouse action, just the ones that result in a real undoable action e.g. highlighting text and mouse clicks shouldn't be stored in the history as they are not real undoable actions. Copy, cut, paste, drag and drop etc. are real undoable actions. So in this sequence of actions:

copy, paste, mouse click, mouse click, highlight text, mouse click, highlight text, drag, drop.

Only the copy, paste, drag and drop actions should be stored in the history. It's really annoying having to go back through all the unnecessary mouse clicks and highlights to be able to undo the paste. It may not seem a big deal when you're reading this, but it sure is when you are coding. I'm sure I can't be the only one who does superfluous mouse clicks etc., because I change my mind on what I want to do.



This is related to the fact that I have php statements in my css files. It would be great for phpEd to be able to detect the <?php and ?> statements in these files and highlight accordingly. It does seem to detect them in the registered files as it changes the coloring if the cursor is outside of them, so I thought the same logic could be used for other files too regardless of whether they have been registered as php files.



It's text that has been undone using the Undo action. However, I don't think that's what I meant. It's more to do with copied and drag and dropped text. Leaving it higlighted is more usable as you usually want to do other things with it afterwards.

Here are some other bugs I forgot to include last time:

- both the tooltips when you hover over a variable and the locals tab show superfluous backslashes (\) whenever there is a slash in the value e.g. a windows filename would be displayed as "c:\\path\\to\\file\\filename.txt". This makes the value really difficult to read.

- when installing version 4, all my syntax colors, code templates and Editor/IDE shortcuts were lost.

- when you close an editor window, phpEd positions on the window to the right of the one just closed. It used to position on the last viewed window, which is much more useful.

- phpEd now opens a new editor window to the right of the active window. This is useful, but sometimes you need the old way of the new window being opened at the end of the tabs. There needs to be a setting to switch this new action off.

And lastly, I do hope I won't have to pay more hundreds of dollars to get the update releases if they include the fixes of the problems that shouldn't really have appeared in version 4.

Debbie

If the css is included in a .php file, php will parse it. First how are you debugging? With 3rd party or internal SRV or what? Second, you must understand that the css @import and links are not possible to debug unless you exlicitly launch them in the debugger and only then if they have a php extension, or they are used by require or include constructs. There is no way to know any css would be 'debuggable' otherwise.



This is probably a setting on your machine -- if you installed powertoys and have enabled 'don't allow windows to steal focus, and flash 3 times instead' that would be the reason. The other possibility is that it's a bug, I too have experienced this behavior on occasion.

So, why does it no longer automatically flip to the front and/or open the pages that are being debugged?



on the contrary, i like the ability to limit search to ignore files of large sizes (for reason of saving time, etc). Just because you find something contrary to your own productivity does not mean the feature is a bad one. Definitely I think there should be toggles and options for this kind of thing, because on this issue I'm on your side as the superflous results in the log are pretty pointless 90% of the time, but the other 10% they are helpful. So checking a box in settings '[ ] Old find behavior' would be a good one IMO.






F9 is not run 'next breakpoint' it is 'start debugger', and that makes complete sense why you are experiencing problems.

The function keys of the debugger are thus:

F9 = Start debug session (press ONE time to start debug)
F8 = Step over
F7 = Step into
Shift+F8 = Step out (which is what you would use to bypass all code til you hit the breakpoint)

You are misusing the debugger in error. Try it with shift and f8. You will probably have much much better luck The other bugs you mention are likely a biproduct of this misuse.




I don't experience this behavior. What settings are applied in your PhpEd settings for IDE settings? (screenshot would be best) -- I don't use persistent blocks, and I have some other settings turned off/changed as well to my preference which could be why I don't experience this (or not).



It does and can. Setup css as a php related filetype and then hit F12 to toggle (if you have auto-toggle disabled) from within a html/css or php block.



Those backslashes are not superflous they are a great feature IMO, letting me know exactly what is in the string/var as PHP understands it. Again this 'bug' is not a bug and it's a feature, and a good one at that.



Same here. I was bummed, but ddmitrie made the setup of the new code colors much much much less painful -- I use a dark background with bright foreground colors on elements -- in phped it took 5 minutes, in dreamweaver 8, take a guess.. almost 30 minutes. PAINFUL! A migration tool may make the upgrade path easier, besides this though the projects inherited fine and everything else worked right? So be grateful it wasn't worse



if you bought 4, you get free upgrades until 5. from first hand experience i can vouch for nusphere and their customer support -- even through the activation request debacle, they have been top notch and i consider their company and their software valuable assets.

2Debbie:


Do you mean that the "blue line" was shown on that file but this file was not activated automatically (as you say flipped) ?


Ok. Below is an example of code that works fine for me, at least
file1.html

file2.php:

as soon as I click "submit" on the form, file2.php pops up and blue line is shown on the 2nd line. No problems so far.

That's why I asked you to create and submit a code sample that replicates the problem. At least, replicates it often.



With v4, I'd recommend you to use File Masks, for example *.php;*.inc;*.css;*htm;*.html
In this case everything will work fine for you.
Regarding default *.* with v3.3, we got too many reports that phped "hangs" for long when run find in files and it always was caused by big files (often pictures of 10MB and more).



ok. We'd agreed on what debug session is first . For example suppose you have a file that contains some included files. You can start debug session, step through them with F7/F8 and once the last line is reached debug session is closed and Output window is activated showing you the results. It's an example of a complete debug session. Suppose the output contains "refresh", "location" or form submit, so it can either manually or automatically redirect you to another (or the same) URL. In this case debugger may start next session (keeping the same debug session ID or not). Anyway, that's another debug session for the IDE. When one session is finished, IDE turns back to "normal" layout and when new one is started it switches to "debug" layout.
There are few improvements we've done in build 4039. First, IDE delays switching the layout by approx 250ms and therefore if there is a new debug session waiting to start when an old one is just finishes, IDE will start it smoothly without overkill switch to normal and back. 2nd) We improved docking library and switch itself happens much faster. In my PIV1200GHz it takes 350ms now. Not bad comparing to 1s as it was in 4033.



It was fixed in 4035.



Okay. It works fine for me and all tabs are preserved. My settings are below, what are yours?



thanks, it's clear now.


It's not a bug. PHPED displays all values in PHP notatain. Therefore all forward slashes are doubled as well as all 0x10 characters are shown as \n and so forth.


It's known problem and is fixable on your side. Rename phped.cfg to phped.xml, open it in your favorite xml editor, correct <php> to <php4> and </php> to </php4>, then rename back to phped.cfg. That's all tricks Yet, setup does not do it for you when install v4 over v3.



PHPED does not support MDI interface anymore and therefore there is no so called 3D-order of the editor windows. All the editor windows are ordered by tabs as you see them.



Sure. All fixes of v4 are available to you for free.

2Rick:


Actually, F9 mean run. If no debug session is started, F9 runs it. If there is one, F9 continues execution.


no more activations
v4 requires only s/n that you get from us just one time and forever.

I humbly stand corrected

Yes thank god. It was nightmare. Poor people on nuSphere end doing the work. I can't imagine how much crap they ate because of it. Mia or whatever her name was, handled it all with perfect grace though.

Anyway, thanks for considering us and not being a jerk about activation. Saved me time already and now I don't have to fret when I reinstall my OS if I am going to be able to work the same day