This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Consider the following scenario reported by customer: I remember I asked you to move dbx options outside of project and got an answer that if I was so lazy to modify options in all projects, then I could change .dbxrc. OK, I don't know dbx commands so well and have a workaround, so I was fine. Now, I attached a process, set all right breakpoints in my callback and ... nothing. I do step and nothing is called. Then I realize that by default in solstudio there is no stop on breakpoints on next command. Oops. This time there is no workaround. For an attached process I have no way to change dbx options on fly except from dbx console. Need to RTFM. Also, I remember that you insisted to hide dbx console from user's eyes and even remove from window list completely. Just try. FYI: in workshop I can do it in few clicks. dbxtool has had a "Configure Current Session" action on it's debug menu just to deal with this scenario, so perhaps the IDE could benefit from this too? There is one interesting problem here to which I don't have a solution. Say debugger properties are stored in a projects configuration. Then suppose you start two sessions from that configuration. If you change debug properties in one session should the configuration "backing store" track and remember it? Should it re-broadcast the change to all other sister sessions started form the same configuration? Should it push the change further "up" to the global properties?
Same action can be added to Sessions View context menu.
(In reply to comment #0) > Now, I attached a process, set all right breakpoints in my callback and ... > nothing. I do > step and nothing is called. Then I realize that by default in solstudio there > is no stop > on breakpoints on next command. Oops. This time there is no workaround. For > an attached > process I have no way to change dbx options on fly except from dbx console. > Need to RTFM. When attach to a process we have <create new project> or <choose one of open projects> for IDE user to manage debug configuration which is part of project. So if users anticipate modifying debug configuration while attaching, they need to have a project. > Also, I remember that you insisted to hide dbx console from user's eyes > and even remove from window list completely. Just try. > FYI: in workshop I can do it in few clicks. We should restore dbx console in IDE, that's one of the strength of dbxgui. > > dbxtool has had a "Configure Current Session" action on it's > debug menu just to deal with this scenario, so perhaps the IDE > could benefit from this too? IDE has project configuration to be equivalent. > > > There is one interesting problem here to which I don't have a solution. > > Say debugger properties are stored in a projects configuration. > Then suppose you start two sessions from that configuration. > If you change debug properties in one session should the configuration > "backing store" track and remember it? > Should it re-broadcast the change to all other sister sessions > started form the same configuration? > Should it push the change further "up" to the global properties? Currently, we do "backing store" track and remember it in debugtarget (dbxtool) or project configuration (IDE), so if two sessions share same debugtarget/configuration, they would override each other. Note: the definition of "same debugtarget" means - same executable path - same host - same args - same debug engine
(In reply to comment #2) > > > Also, I remember that you insisted to hide dbx console from user's eyes > > and even remove from window list completely. Just try. > > FYI: in workshop I can do it in few clicks. > > We should restore dbx console in IDE, that's one of the strength of dbxgui. > Not all users will know dbx commands. We should not use dbx console as a fallback for poorly designed UI. > > > > dbxtool has had a "Configure Current Session" action on it's > > debug menu just to deal with this scenario, so perhaps the IDE > > could benefit from this too? > > IDE has project configuration to be equivalent. > One of the frequentlt performed tasks is changing thw roking directory and run args of a debugging scenario. Going though projects requires too many clicks. This is something customer complains about repeatedly. "Configure Current Session" is a whole lot quicker.
(In reply to comment #3) > (In reply to comment #2) > > > > > > Also, I remember that you insisted to hide dbx console from user's eyes > > > and even remove from window list completely. Just try. > > > FYI: in workshop I can do it in few clicks. > > > > We should restore dbx console in IDE, that's one of the strength of dbxgui. > > > > Not all users will know dbx commands. > We should not use dbx console as a fallback for poorly designed UI. No matter how good your UI is, you can never cover all the functions that dbx console can do. > > > > > > > dbxtool has had a "Configure Current Session" action on it's > > > debug menu just to deal with this scenario, so perhaps the IDE > > > could benefit from this too? > > > > IDE has project configuration to be equivalent. > > > > One of the frequent performed tasks is changing the wroking directory > and run args of a debugging scenario. Going though projects requires > too many clicks. This is something customer complains about repeatedly. > "Configure Current Session" is a whole lot quicker. Then the question is how to implement this : For debug session that has no project/configuration, should we create temporary one ? should we persist it afterward ?