We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › g.fillR, fillG, fillB not working anymore
Page Index Toggle Pages: 1
g.fillR, fillG, fillB not working anymore? (Read 707 times)
g.fillR, fillG, fillB not working anymore?
Aug 11th, 2005, 11:39am
 
Didn't this use to work?
Code:

println(g.fillR + " " + g.fillG + " " + g.fillB);


Error:
Code:

Semantic Error: The field "fillB" in type "processing.core.PGraphics" has default access and is not accessible here.


How do i get access to these values?

-seltar
Re: g.fillR, fillG, fillB not working anymore?
Reply #1 - Aug 11th, 2005, 12:18pm
 
this might have been an oversight when moving the code from BGraphics -> PGraphics.

the old version of processing didn't make use of java packages, the new version does (i.e. the main code is now in a package called "processing.core"). because of that a class method or variable which is not explicitly declared as "public" is not accessible from your sketch (unless you declare it to be in that same package).

unfortunately, there's is no easy way to force package membership of your sketch via the Processing PDE and hence get direct access to these variables... at least not in this version, if it really wasn't an intentional step taken by ben to protect these variables, it might well be fixed in the next release. just please don't take my word for it! Wink

there're quite a few of those variables in PGraphics for which it would be great to have direct access to, but maybe it'd be more safe to have "getter" methods for those. afterall, users who're using those properties directly could be considered to be more experienced and should use more "correct" java style methodologies? offering "public" access will open those vars to be uncontrollably overridden too... it's becoming a political decision again... Wink
Re: g.fillR, fillG, fillB not working anymore?
Reply #2 - Aug 11th, 2005, 5:05pm
 
g.fillColor will give you the color (as an 'int'), and g.fill is a boolean that says whether the fill is enabled or not.

so to get fillR etc:
int fillRi = (g.fillColor >> 16) & 0xff;  // number between 0 and 255
float fillR = (float) fillRi / 255.0;  // number between 0 and 1

the others look like:
int fillAi = (g.fillColor >> 24) & 0xff;  // number between 0 and 255
int fillGi = (g.fillColor >> 8) & 0xff;  // number between 0 and 255
int fillBi = g.fillColor & 0xff;  // number between 0 and 255

or you could even use red(g,fillColor) (and the rest) and set the colorMode to use the units that you want.

fillR and fillRi and a bunch of the others were made no longer public because they aren't used consistently across all the renderers. so rather than updating a bunch of variables each time fill() is called for a use that's quite rare (people needing to grab the colors) it's easier to just keep track of one.

as for accessors, the general plan is that g.someName will usually contain the parameter, if it's something that can be stored properly. i.e. g.colorMode contains the current colorMode, or g.strokeWeight contains the current strokeWeight.

some of this can also be seen in the javadoc-in-progress, inside the link to 'core': http://dev.processing.org/reference/
Re: g.fillR, fillG, fillB not working anymore?
Reply #3 - Aug 12th, 2005, 3:33am
 
Thanks alot! Smiley This will get me going on the right track!

And there was really alot of usefull information on http://dev.processing.org/reference/core/ .. worth checking out for everybody Smiley

*back to work*
-seltar
Re: g.fillR, fillG, fillB not working anymore?
Reply #4 - Aug 12th, 2005, 9:49am
 

Good call on the documentation ref.
Page Index Toggle Pages: 1