Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Is there some way in the eclipse debugger to identify what specific pointer it views as the one that is null when it shouldn't be?</p> </blockquote> <p>The answer here is Yes and No. <strong>No:</strong> You cannot tell Eclipse to specify which pointer to check for null at. All you can do is watch the pointers themselves when you are broken in the class or function. <strong>Yes:</strong> All you have to do is split up your calls and you can find the object. For instance, the code in question <em>seems</em> to be: </p> <pre><code>_currentGraphic.getCoordinates().setX((int) event.getX() - _currentGraphic.getGraphic().getWidth() / 2); </code></pre> <p>You would split this up into (forgive the pseudo, but I don't know which types you are working with):</p> <pre><code>Type _coords = _currentGraphic.getCoordinates(); Type _graphic = _currentGraphic.getGraphic(); Type _width = _graphic.getWidth(); _coords.setX((int) event.getX() - _width / 2); </code></pre> <p>Now, the line of code is broken up into one object per line, easily able to determine which is the offender.</p> <blockquote> <p>Why are breakpoints being ignored?</p> </blockquote> <p>This one is a bit more complicated. Your breakpoints may or may not be being ignored. In general, if you are getting to one breakpoint, it should be getting to all of them in order. However, I have noticed, in Eclipse, that sometimes breakpoints are ignored given certain circumstances. For some reason, the adb is not completely integrated with the Eclipse debugger. This means that if you change breakpoints in the middle of a currently running debug, it may or may not recognize them. Often it is enough to kill the app completely and redebug it.</p> <p>Additionally, sometimes the adb and debugger do not synchronize correctly. There is a command that you can use (best at the beginning of your code) that helps that along quite nicely. If you insert the command <code>Debug.waitForDebugger()</code>, the synchronization will come into place allowing the earliest breakpoints (those in your first onCreate() and similar) to work correctly. The command does make you debugging much slower though. Using this at key points will also mitigate the blatant breakpoint ignoring discussed previously.</p> <p>Now it is important to note that just because you think it is ignoring them, does not mean it is. Sometimes (especially with Android, right now), execution does not necessarily go through the paths the developer thinks that it does. For instance, one might set a breakpoint in the <code>ViewClass(Context context)</code> constructor, when it is actually created via XML with the <code>ViewClass(Context context, AttributeSet attr)</code> constructor. Heck, even a forgotten creation of an object can completely steer execution in the wrong way. This may be especially true if the object has <code>static</code> members or code that is run on <strong>class</strong> initialization (not <strong>object</strong> initialization). Without looking at your code, I cannot say which is happening, but hopefully this gives you the tools to find your answer.</p> <p>Hope this helps,</p> <p>FuzzicalLogic</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload