I am interested in knowing Debugging setup that'll allow a programmer to be most productive. Assuming knowledge about debugging in general.
I am mainly interested in knowing how and where you place different windows like the variables window, code window, the stack. Also possibly the relative size of different windows.
I'd prefer if there are screenshots attached and a description of why the setup works for you or one that is efficient.
I mainly use Eclipse and Netbeans.
Most productive? That's going to vary greatly from person to person. You shouldn't focus on what works best for other people or details like precise window placement... figure out what works best for you with some trial and error.
For me, multiple monitors are important. I keep code and tools (Eclipse, SQL manager, etc) open on one, and use the other for the console and the running program (whatever it may be: website, windowed application, etc).
First you have to know how to use the debugger really well and then after that the placement of windows is just frivolous detail, for the most part. It will just fall into place without having to mimic other people's comfort level with the tools.
It sounds like you're looking for a static setup but likely you will show/hide windows depending on what you're debugging and size them to different situations. At least that's what I do. So I would post many screenshots and they'd all look different.
"I'd prefer if there are screenshots attached and a description of why the setup works for you. "
You're exactly right knowing it works for the other person.
In addition to what others have said, one thing that I do with respect to variable windows - Visual Studio gives you 4 different watch windows. I usually put them all into a single tabbed window, and each tab will represent a different programming context. For example, tab 1 will list variables that I usually need to look at when dealing with area A, tab 2 has variables for area B and so on.
Doing this, I find that the watch windows don't get over cluttered and I spend less time setting up variables
Related
I'm currently designing a GUI using JavaFX and SceneBulder.
I would like it be composed of several windows, each of which can be hidden, resized, deleted, etc.... in much the same way that is posible in Final Cut Pro 7.
For example: http://www.squarebox.com/legacy/xfer_fcp7.png
I have read various posts and articles (e.g. Angela Caicedo's article for Oracle) about creating apps with multiple windows but none of them seem to address displaying several windows simultaneously and enabling the contents of these separate windows to communicate with each other.
I have read a post which suggests just creating several stages (and therefore windows) in the start method of the main Class. I am tempted to go down this route but am suspicious as it seems crude and I get the sense that this might lead to problems later down the line with regards to getting each window to interact.
Any help or recommendations with regards to design would be appreciated.
Thanks for reading.
My machine seems to be experiencing some weird issues with java swing.
This sort of thing happens with other programs as well but the corruption goes away with scrolling or highlighting the text. What could be causing this and why doesn't java go the same? All the characters seem to be cached so that when a character gets corrupted, all of the characters of the same type have the same corruption (not true of anything but java swing).
I have been googling around for this sort of issue but most of them only suggest issues with graphics drivers and settings for windows... (I am running kubuntu)
Side note: Sorry if this doesn't belong here. Didn't really know where else to ask.
Among the many possible causes,
Verify that all correctly synchronized Java Swing programs using standard font families with the default Look & Feel exhibit this behavior; if not, it may very well be a driver problem.
Investigate whether the Ubuntu video driver permits alterations similar to the one required in this Windows case.
Try a different window manager.
Try a different Look & Feel.
I wanted to know if there is a way to measure the overhead of a specific function or even the running time of an application in Eclipse (with the capability to run the test for arbitrary times to get the average time).
I have a code that should be executed in Eclipse therefore looking for such a thing. I know that we have Jmeter in Netbeans and I'm looking for something similar in Eclipse.
Thanks
I have had good experiences with JProfiler. It should be precise enough to give usable data even when you run your function only once, depending on how you set it up. It also optionally integrates with Eclipse.
It's not free, but there's a fully functioning trial available.
I used Traceview before and it worked quite good to me.
It quite easy to use, just open the DDMS view in eclipse and look for the icon with three arrows with a red dot (Start Method Profiling). Click the icon and test your app as you want. When you are done click on stop. The trace should open in a new tab.
You could use the following
http://www.jvmmonitor.org/
It's called Java Monitor and comes as an eclipse plugin. You can install it from eclipse market place.
I'm working with a legacy Java app that is new to me so one way to figure out how it works and find things easier, I have thought would be to be able to get the full stack trace after I perform actions, so as to be able to see which classes are being used based on a particular UI action. I had thought this was possible in the debugger but it seems that it only works if I insert a breakpoint and in this case part of the purpose of this is so that I don't have to know what's being called to be able to insert the breakpoint first (as this would help tell me that).
I apologize if this is a basic question, I have searched on this but I'm not finding the correct answer.
This doesn't directly answer your question, but maybe it will solve your problem better. Take a look at BTrace. It lets you instrument a running Java app and insert some basic code of your own. You could, for instance, have it write out entire method call chains to help you find your way through the app. It's somewhat similar to AspectJ, but with an entirely different purpose and requiring no change in the project source:
"BTrace is a safe, dynamic tracing tool for Java. BTrace works by dynamically (bytecode) instrumenting classes of a running Java program. BTrace inserts tracing actions into the classes of a running Java program and hotswaps the traced program classes."
A few suggestions:
Some profilers will allow you to walk from any particular method up (and sometimes down) to see what's calling and being called. I've found this surprising informative about flow, even in apps I thought I knew well.
For understanding the mainline flow, I don't think there's a better substitute for working interactively with a debugger. It will lead you into learning other important things. Not what you wanted to hear, I know. This presumes that you can rapidly restart the app when you miss a key off-ramp.
Reverse-designing large legacy apps is the one place where I use UML fairly regularly. There's too much to keep in my head to form a good big picture. If you have a UML tool that will do reverse-engineering, load it up with the app, then probably prune down hard on the classes you don't care about, because they are trivial or obvious. Arrange the diagrams in a way that helps you understand. I've used Together, Magic Draw, and Visual Paradigm in this way. Together worked the best - but it was a decade ago.
When you are in the debugger perspective, you will see a view showing the launched processes. In that view you can tell it to pause all threads of a process. Once stopped, you will be able to browse through threads to see what they are all doing. To try to catch what a particular action is doing, you would have to start the action and then quickly pause all threads.
You could always run the application with the VM arg of -verbose:class. You could then watch the console output and see what classes the VM is loading when you perform a particular action. This could possibly give you a starting place for where to place breakpoints. This won't always work depending on the scenario, but may be helpful.
Another trick you can use is to figure what classes you know that have to be involved in the code path you are trying to trap. For instance, you mentioned that it's a Java EE web app and therefore the action is likely some kind of a servlet interaction (at some level). I don't have the API in front of me, but you can place a breakpoint on the method in the response object where the output stream is retrieved. Once that breaks, you will know the code that's trying to service the request.
You can always see where a method is called by clicking "Open Call Hierarchy" from eclipse (left click on the selected method or CTRL+ALT+H ). Also, you always can inspect where a method/class is defined by clicking "Open Declaration" (left click on the selected method/class or F3).
Is it possible in Delphi to keep a window on top of all other windows? For example when you have an error message in your application, let's say you want to keep the window on top and make sure the user has to click something before he can do anything else. And I really mean anything, like clicking another program in the background. And how about in Java?
No. Raymond Chen of Microsoft has a great article about why not here. The gist of it is that no matter how hard you try to keep your window on top, someone else can always come along and do the same thing.
You could do this in the old days. It was called a system modal dialog and you used the now obsolete SetSysModalWindow() function.
They were utterly repugnant and so sense and order was restored when Windows NT based versions of Windows took over.
In Delphi you can do FormStyle:=fsStayOnTop;. This will put you in front of all normal windows.
But if there are other windows which have that style set too(such as the task-bar) those might be on in front of yours. In particular among those windows the one that has focus is has the highest priority.
You can try to ensure that your window always has focus, but that's rarely a good idea. And you will incur the wraith of Raymond.
You can also use a layered window. I think those are in front of normal always-on-top windows. But this has severe side effects and is most likely not the correct choice for you.