Hi:

One thing that would remove a major annoyance for me is if you could add a feature to disable debugging and run hotkeys when there is no current debugged context attached to an external browser.

I *never* use the internal browser yet out of reflex I often press the run or trace hotkeys when there is no current external debugging context. This of course triggers the "Do you want to store Run configuration in LaunchBox?" dialog to which I have to answer "No" which then, after a pause, brings up the "Waiting for debug session" dialog to which I have to select "Cancel" after which I get further accosted with the "Do you really want to cancel this operation?" dialog to which I have to answer "No." This process totally breaks my train of though, it happens probably 2 to 3 times an hour, and it is for something I *never* use. *Ever*.

By analogy consider how the PhpEd debugger user interface is similar to an automobile whose brake pedals worked normally except when the vehicle is at a stop. When at a stop the brake pedals would instead cause accelleration; imagine how many mistakes people would make if that were the case. Of course this aspect of the PhpEd debugger user interface results in less tragic outcomes, but is highly frustrating nonetheless.

So please, please add a user-selectable option to disable hotkeys for launching a debugging session from within the internal browser. Of course for those users similar to me but that do occassionally use the internal browser you could continue to allow the toolbar buttons to launch the internal browser and once launched enable the hotkeys for that debugging session.

BTW, while you are at it please consider adding explicit "Debug next Page" and a "Debug next POST" buttons which would "kill two birds with one stone." Many times the debug button is disabled so I have to refresh the page enable or disable those options which in many cases is a problem because either the page's code is not ready to be executed or that I want to turn off debugging. In addition it would be a lot nicer to just be able to hover and click instead of having to select the drop down, move the mouse cursor, select the correct option, and then click.

Thanks in advance for considering these usability enhancements. Yes, they are small things but these kinds of things make the difference between software people love to use, and the software people curse.

I'm not sure what "debugged context" you mean and how to detect if it is "attached" to the browser. Could you please explain in details?


you can disable this popup and it will always proceed with your last answer.

If I got you right, time after time you press "run with debugger" while you don't want to. If so, just stop the listener and all the debugger commands will quickly become disabled.


I'm not sure what kind of problems you have with Debug next page/debug next post menus? Do you want them to be buttons instead?

"debugged context" was a term I made up to describe if the debugger was being invoked from within the IDE or from the toolbar button on the browser. You have to know internally that there is an active session using an external browser otherwise how would you know to continue debugging and not instead start a new debugging session?



Yeah, but it doesn't solve the basic problem of invoking the debugger when I had no intention to invoke it using the internal browser. The problem occurs when I think the debugger has an active session that was invoked from the browser but infact does not. Since this unfortunately happens often, I'd like to disable having the Run and Step keys launch a debug session from within the IDE.



Yes, I am accidentally , I *want* the debugger to work, it's just that I don't want the Run and Step keys to invoke a new session from within the IDE. Current the Run and Step keys have two purposes:

1. Launch a new Debug Session, then Run or Step, and
   
2. Run or Step the current debug session.
   

I want to be able to disable the hotkeys from doing #1.

Basically what you have is a modal system where the hotkeys behave differently depending on the current "mode" (an active debug session or non-active debug session.) I studied usability 20 years ago and even back then we knew that modal design is suboptimal. Here's a blog post about modes: http://www.osnews.com/story/18904/Common_Usability_Terms_pt._V:_Modes

20 years ago we studied the idea of "Auto-Tab" in data entry forms (i.e. autmatically moving the cursor to the next field when the field is filled.) Auto-Tab very bad for usability because users get in a rhythm of entering then tabbing and if they have to think to recognize whether or not the field is filled it breaks their rhythm and results in much greater data-entry error rates.

I have the same problem with your debugger hotkey modes. I get in a rhythm and accidentally press the hotkey and it takes me off into a feature of the program I didn't intend.

Good usability is partly about ensuring that bad things don't happen when the user makes a mistake, and though the hotkeys launching a new debug session from within the IDE when there is no active debug session is more annoyance than destructive, for me it happens constantly so for me it is HIGHLY annoying.

Please consider fixing this; it really shouldn't be that hard to add an option and an IF statement to you code, is it? The option could be "Launch New Debug Session with Run and Step Hotkeys" with a default of "Yes" (to be just like current functionality so as not to confuse other users) but it would let me set it to "No."



Yes I'd really prefer to have buttons instead of the drop down. Frankly for constantly used functionality drop downs are not good for usability and can be very frustrating to use repeatedly.

If debugger sees its session and session is enabled, it continues. From what you said: sometimes you don't need it to continue, so just run without debugger. It's enough to drop debug session. Debugger session is cookie-driven so it will be dropped as soon as you open new instance of the browser.


Looks a bit funny
How would you start new session then? They are the only buttons in the IDE that may start new session. If what you offered is to use IE toolbar buttons, it will not cut. What would people using internal browser do? What would people who use say Opera do? How would they start debugger without buttons in the IDE?


Not at all. If we talk about Run and Step buttons, their behaviour is consistent and does not depend on the "mode". Indeeed, Run always makes script to run until it reaches a breakpoint regardless if the IDE is in debug or not in debug mode. Same goes to the Step button that makes script to perform just one step regardless if debugger was started or not. If it is not started, Step starts from the beginning. And this behaviour pretty consistent among many other IDE with integrated debugger. By breaking this behaviour we may upset many people who used to work that way.



great. Would you please describe your two ideas in simple words and start two corresponding polls in this forum? If we get many people supporting your idea, we'll add them into the plans. It's democracy there

You are still not following me.

Step by step, consider this: I'm debugging with the external browser. I'm alt-tabbing back and forth from the external browser to the IDE. I hit F5 twice, accidentally. The first F5 finishes the current run in the external browser. The second F5 attempts to load the internal browser. Crap. I wait until I can cancel it and then cancel it.

A few minutes later I'm clicking the debugger button on the external browser, but nothing happens. I alt-tab to the IDE to find the debugger is on a breakpoint. I click F5 to run it to the end, and then another session loads again because through my inadvertent actions have queued up several requests. So I press F5 again. Then I press it again. Oh sh*t, I pressed it too many times; it loaded another internal session!!! Now I have to wait for it again until I can once again cancel it. Grrr. Very Frustrating.

This happens constantly.

The answer is not to run without debugger. This typically only happens when I'm in the midst of trying to debug, but when the IDE is in not in the right mode for my actions. Telling me to run without the debugger is like telling me to walk to work with I complain about the noise my car engine in making. Yes, I would not have the problem if I ran w/o the debugger, but what good would that be. I use PhpEd because of it's debugger, all other features are secondary.

The IDE currently has a usability issue, and seperating the "Launch Internal Browser and Run/Step the Debugger" from the "Run/Step Debugger" would solve it for me. Heck, it'd be nice if I could have Alt-F5 "Launch Internal Browser and Run/Step the Debugger" and F5 "Run/Step Debugger."

That said, another thing I'd like is a button in the IDE to terminate ALL pending requests so even if I have 3 pending requests it will clear them out.



Did you men me asking that it be implement as an option with the current behavior being default? Per my suggestion all those people would do *exactly* what they have been doing. Only people like me would go into your setting and disable the hotkey to invoke a new session. I'm asking for an OPTION for me, not a forced change for others.



Ah, but your last sentence (which I bolded & italiced) contradicts your first two sentences (which I also bolded & italiced.) The fact that Step starts from the beginning if the debugger is not started is the mode to which I referred.

The solution is to provide an OPTION to decouple those two behaviors: 1) Starting from the beginning and 2.) Stepping.



So are you saying you want to be no better than the others?

Anyway, are you sure the others provide the exactly same functionality? It may be that their implemention is better and such makes this less of an issue.



NO ONE WOULD GET UPSET. By providing a setting that is optional but that defaults to current behavior, no one will get upset because for them no existing behavior would break (or even change.) The only people who even notice are the ones that set the option.



Well, we are getting somewhere. However, is the purpose of the poll to determine if people want it or which of the things you would spend your development time on?

I fear going through the process of a poll because:

• What I'm asking for takes a bit of time to understand and polls don't do well for things that are not really obvious. I can poll to ask "What version of PHP do you use?" Or poll "Which CMS/Framework do you use?" but asking questions about the hotkeys not launching the internal debugger is most certainly going to get poor response because most people bother to spend the time to 't even understand what I'm asking. Look how long this thread is, and I'm still not sure you understand my concern.
  
  
• Assuming you are just asking for a vote on preference and not on where to spend your resources then forcing me to rally support for an optional feature is very customer unfriendly. Why should I be forced to convince a bunch of people who don't understand my problem to vote yes on a feature they don't understand? Even if it is presented as an option they will still vote no if they don't understand it, even if it will not affect them in the least.
  
  
• If you want a vote so you can determine where to spend your resources I'll argue that I'm only asking you add a single checkbox to one of your setting dialogs (that can't take much time, can it?) and then to put an IF statement that will not start the debugger from any of the stepping hotkeys within the browser with that option is checked (adding that IF statement can't take long, can it?
  

As for the buttons on the toolbar vs. a drop down, I'd also like to see that request be implemented as an option but I do accept that that might take a little more work than the hotkeys. If you'll grant me my first request (because it seems to me that it would be brain-dead easy to implement and as an option not affect anyone negatively) then I'll be happy to roll the dice and add a poll asking for toolbar buttons. Even though you could implement that as an option so it wouldn't affect anyone negatively, it is at least easier to explain in a poll than the request for an option to disable starting the debugger from a stepping hotkey.

Deal?

no, of course not.

I can't imagine that it happens to anybory any frequently so that we need something to do with F5 to get it working differently.
If this key is located differently on your keyboard so that you press it accidently many times a day, you can change shortcut for Run In Debugger to any other key.
Btw, Run has F9 as a shortcut by default. Seems you've reassigned this command. I think you've done this for purpose. Did you ever work in MS Visual Studio? Try F5 there and you'll see exactly the same behaviour as in PhpED.


F5 stands for Run and it works this way. If you don't need internal browser, why don't you switch to External browser in Tools->Settings->Run And Debug?


If you need to cancel, why don't you click Stop (Shift-F2). Would you please explain?


Not a correct word. We want to follow standards adopted in the area of IDE and debuggers.


if you don't want debugger to follow the requests, just uncheck Debug Session checkbox in Tools->Settings->Run And Debug and it will follow just one request.


Definitely, you're comparing apples to oranges.
Your original complaint is all about unwanted debug sessions caused by multiple clicks on F5. I hope you have a very strong reason why you're clicking or it that accidently and that frequently. A bit fun won't harm, why don't you jump through the window accidently? If you jump at all, it's not any harder that clicking F5 multiple times. Ah, I remember you mentioned car breaks. That's the problem! F5 is an accelerator, not a break. Break is Shift-F2 (if you havn't reassigned it).



I know there are many people who will not agree with you on this statement


Don't worry. Please, run a poll and stop your complaints. I replied with my points and let's see people votes.

It has nothing to do with my key mapping and everything to do with the fact that I get in a rhythm and press F5 when it is in the wrong "mode." When I had the key mapped to F9 I had the problem even worse.

Actually I had a lot of problems with the default debugger key mapping; I was always selecting the wrong keys and loosing my train of thought. So I spent literally an afternoon remapping the debugger keys to make them more logical (to me) and work better (for me.) Here is what I came up with:

Run in Debugger - F5
Run to Cursor - Ctrl-F5
Pause - Alt+F5*
Stop - Shift-Ctrl-F5*
Toggle Breakpoint - F7
Step Into - F9
Step Over - Ctrl-F9
Step Out - Shift-Ctrl-F9#

* I rarely use this because I never remember it
# I use this constantly once I learned it was there!

Note how I grouped:

• Similar functions are on the same keys only modified by alt/ctrl/shift,
  
• The more "dangerous" keys (except F5/Run) use "Shift-Ctrl" or Ctrl so I have to go to extra effort to use them and thus don't use them unless I meant to, and
  
• the functions so that no two keys are side-by-side (I don't use F6 or F8 for debugger because having them side-by-side.)
  

In addition, though it is hard to *see* this, once learned this set of keystroke combinations makes for a much better rhythm during debugging than the default layout. With this layout I far less frequently press a key I didn't intend to press during debugging, and as you know pressing the wrong key during debugging can cause one to completely loose one's train of though.

I *could* put Run on something like Shift-F5 which would help but not solve the problem, but I use Run (and Step Into) so often that it would be really cumbersome and fatiguing to do so.

BTW, why are you so focused on trying to tell me that I am not using PhpEd right and why instead won't you please listen to my concern?



It is already set that way, and I still have the problem with my use of PhpEd.

So maybe I've explained the problem slightly wrong. I guess the explaination should be give me an option to turn off launching ANY browser from a debugger hotkey.

Let me explain why this is such a big deal because it may be that you simply never use PhpEd in the same way I use (and many others have to use) PhpEd. PHP-based websites can be architected in 1 of 2 ways (for sake of discussion, please ignore that there may be more than 2 ways because even if there are it is unimportant for our discussion.):

Even page on the site is loaded from:

• 1.) A different kind of PHP file, i.e. products.php and articles.php.
  
• 2.) index.php with a lookup for what content to display.
  

In case #1, the debugger's configuration mention would not be a problem. However for case #2, which is how Drupal and WordPress work, the file I am editing is NEVER the file that I should debug. So ANY timeWHICH IS NOT WHAT I WANTED (EVER!) I press the Run or Step hotkeys PhpEd invokes the debugger in a manner in which I did not want it to.

Maybe if I ask for a different feature then maybe it will help you understand. Assume I asked for you to let me set the URL that the browser will load whenever PhpEd wants to start the debugger AND make it convenient to set and see that URL (i.e. in an input field in a IDE toolbar button.)

In case that is unclear, let me explain Drupal a bit more. Drupal 99% of the time uses this URL format:

http://myserver/index.php?q=the/page/I/want

Now MOST Drupal sites (mine included) use Mod Rewrite so when we enter those URLs into our browser they look like this:

http://myserver/the/page/I/want

To give a more realistic URL, it might look like one of the following:

http://myserver/news
http://myserver/node/325345
http://myserver/events/concerts

Now, let's assume I'm working on a function in the theme for the events section of my website. That file might be:

C:\apache\htdocs\test.com\site\all\themes\my-theme\template.php

Now when I finish editing template.php and want to see the results of my work, I might load the following URL:

http://myserver/events/concerts

OTOH if I press F5 when editing template.php, PhpEd attempts to load template.php WHICH IS NOT WHAT I WANT (EVER!). What would be much better is if I could have set the URL path to debug to be "/events/concerts" so that, until I change the URL path PhpEd will open the external browser and always load that URL. (Note URL Paths to debug would be specific to each project.)

So as we discuss this, the problem is becoming clearer to me: PhpEd doesn't not do a good job of handling the use-case of architecture #2 which is where I work 99.9% of the time (Drupal ~95%, WordPress, Mediawiki, etc. ~5%.)

INTERESTINGLY, those two open-source projects and the many others that architecture #2 represent a HUGE market. Maybe you should consider paying attention to my concerns and possibly ensuring that PhpEd debugger works really well with Drupal, WordPress, and similar? I'll be happy to help if you'll do that where I can.

As a matter of fact, I have already helped. I gave a presentation to the Atlanta Drupal User Group on using PhpEd and they were all amazed at it. There is a HUGE market for Drupal users to use PhpEd, but frankly PhpEd has too steep a learning curve for most Drupal users because PhpEd by default configuration makes debugging Drupal too hard.

Minimally, giving the option to disable Run & Step keys from *starting* the debugger would help. In addition, giving the option to quickly and easily set the URL path to debug would REALLY help. And if you did let us set the URL path to debug it would be great to have an option where you reset the path automatically whenever I type the URL directly into the external browser and I launch the debugger from the external browser.



I used MS Visual Studio for a while, but never with an external browser so the problem never came up for me. However, almost all ASP.NET websites use architecture #1 with explicit .ASPX pages so my problem would never have surfaced for them.


Two reasons: 1.) I can never remember that hotkey, but 2.) the example I gave you was not as important as the fact that I am constantly having it launch a browser when I didn't intend it to. Still, the insight that is is probably because of architecture #2 is probably more helpful. If F5 launched the browser on a URL I specified then I probably would never notice this as a problem.



So the problem is you don't work optimally for architecture #2 which is Drupal, WordPress, and many others.

BTW, I think architecture #1 is on the decline and architecture #2 is on the rise because of people's recent greater desire to control the architecture of their website's URLs. Even Microsoft Visual Studio is recognizing this need with their Model-View-Controller project.



That is a different issue. I *do* have that option unchecked.

The problem I'm referring to is that I frequently issue several browser requests before I realize the IDE is already waiting at a breakpoint in my code somewhere. Then when I realize it I have to click the stop button, wait a second for the debugger to restart, hit the stop button again, and sometimes even have to do that a 3rd or 4th time. I'd like to be able to click a button and/or hotkey that just stops EVERYTHING that is currently queued.

BTW, though I can't ever pinpoint the problem exactly, PhpEd sometimes seems to continue debugging sessions even though the debug sessions option is off and I have to close and reopen both PhpEd and the browser to get it to stop. That problem has seemed to diminish some with recent bug fixes, but I think it still happens from time to time.

Here's another thing to consider: When I click the "Debug this Page" button on the external browser, why not have it stop the debugger if it is sitting at a breakpoint, or at least ask me if I want to stop what's in the debugger? Currently it just queues up forcing me to manually stop the current and all queued requests so that I can be sure of what I'm actually debugging.



Are you familiar with the study of human factors also known as human-machine interface and/or the study of usability? Your comments make me think that you are not. Certain designs are bad designs because human cognition works in certain ways and even though you can say that the human should do something differently it is unnattural and just doesn't work that way.

Humans are very used to getting into a rhythm which is why modal command designs have been found to be really bad. The more a person has to concentrate on a task, the more important that rhythm can be. The process of debugging is very concentration intensive. Whenever someone is required to stop and think "should I do A or should I do B" during heavy concentration it is very bad human factors.

Imagine a race car driver whose car required him to shift forward-backward when going straight but required him to shift left-right when in a corner. That would be a VERY BAD design. If you have ever raced (I have raced motorcycles) you know that all of decisions needed to operate the machine need to become instinct and then you can just focus on going fast and not on operating the machine. Anything that requires you to consciously think how to operate the machine is bad, screws up your rhythm, and results in constant mistakes.

Having to think "Should I press F5 now or alt-tab to the browser?" when I want a specific thing to happen during intensive debugging sessions (which for me is more than 90% of my use of PhpEd) results in me constantly making mistakes. I have gotten to the point where operation of PhpEd's debugger is (mostly) in my subconscious and I can instead concentrate on my code logic (Imagine how hard debugging would be if you had to actually think about which key you need to press each time before you pressed it!) I can't put operation of PhpEd's debugger 100% in my subconscious because I need to consciously think "Should I press F5 now or alt-tab to the browser?"

What probably makes it worse for me is that I my use-case: architecture #2, i.e. Drupal. My guess is you are not familiar with using PhpEd in this use-case. I'll bet if you did a lot of Drupal module and theme development you'd come to realize the same problem I have with the debugger hotkeys.

I really wish you'd be willing to try and see it from my perspective instead of continuing to try and tell me how my perspective does not make sense. I've already spent many hours on this discussion when I could be working on my paying client project, and I really just want the debugger to work better for me.




And I'm sure there are others that will agree with me that IDE currently has at least one usability issue, but what do our two respective statements prove? Nothing!

I have tried hard to control any sarcasm on this discussion, but permit me this one:

• It's amazing to see how much you really care about your customer's concerns! <sic> ;-(
  

BTW, and this is an honest question, it is cultural? I know from my travels in Europe that not all countries have that same culture, especially those from former communist countries.

In the USA we have a saying "The customer is always right" and the reason we have that saying is because as a culture we have learned that when you treat the customer's concerns with dignity and you do your best to make the custom feel like you value their opinions, you get a lot more customers and those customers are happier to spend money with you. OTOH, when people at a company do their best to make their customers feel stupid (which arguably your comments seem to be attempting to do with me) then it causes those customers to resent the company or simply tire of having to constantly debate and then they take their business elsewhere. Some times when people at companies treat their customers this way they even get so mad that they actively look to undermine those companies, for example writing blog posts about how great are the products of that company's competitors.

I don't in any way want to imply "My culture is better" because it is only different, but I will say that treating customer's concerns with respect instead of derision improves sales and profitability, and also when you are when you are selling products to another culture it is important to recognize their culture and appreciate how they prefer to be treated. And I'd really prefer it if you'd actually listen to me instead of constantly telling me how I am wrong, even if you do include a smiley after your statement.

If I wasn't already using your product and didn't think that your treatment of me might be based on a different culture, I would be incredibly offended and have already taken my business elsewhere because this is probably the 10th condescending interaction I have had with you on this support forum. OTOH, I can only take so much before I start looking for other options, and that will include telling my Drupal user group about my experiences.



Don't worry? You haven't addressed my concerns about the poll. People will not understand it and will thus either not vote or vote against it.

And my comments are not complaints, they are feature requests. My only complaints are that you seems determined to prove that the problems I as one of your customers have identified with PhpEd are not legitimate.

Tell you what I've done instead; I've asked people what they use PhpEd to debug:

• what-do-you-use-phped-to-debug-t4648.html#19294
  

Mike,
Thank you for your input, and please be assured that we listen to everybody and respect our customers. Our engineering will put your feature request on our list to consider.
Best regards,
Sergey - Nusphere Customer Care