Difference between revisions of "Thread:Talk:Robocode/Graphical Debugging/Debugging waves with onPaint()/reply (7)"

From Robowiki
Jump to navigation Jump to search
 
 
Line 1: Line 1:
 
Using getGraphics() also works. But I am implementing onPaint and storing an object in a member variable (that object contains the Graphics object), which is then consumed in the run() method. That variable is cleared before calling execute() (in case debug is disabled in the middle of a battle). It is bulky, but it is fast.
 
Using getGraphics() also works. But I am implementing onPaint and storing an object in a member variable (that object contains the Graphics object), which is then consumed in the run() method. That variable is cleared before calling execute() (in case debug is disabled in the middle of a battle). It is bulky, but it is fast.
  
If painting is disabled, onPaint is not called and nothing is setted in that variable. Yep, there is one check to see if the variable was set. The onPaint event is treated a bit differently (separated queue) from other events to make it easier to procees it at the end.
+
If painting is disabled, onPaint is not called and nothing is setted in that variable. Yep, there is one check to see if the variable was set. The onPaint event is treated a bit differently (separated queue) from other events to make it easier to process it at the end.

Latest revision as of 19:03, 17 May 2012

Using getGraphics() also works. But I am implementing onPaint and storing an object in a member variable (that object contains the Graphics object), which is then consumed in the run() method. That variable is cleared before calling execute() (in case debug is disabled in the middle of a battle). It is bulky, but it is fast.

If painting is disabled, onPaint is not called and nothing is setted in that variable. Yep, there is one check to see if the variable was set. The onPaint event is treated a bit differently (separated queue) from other events to make it easier to process it at the end.