Graphic symbol, Hatch pattern fill - STYLE_FORWARD_DIAGONAL cannot be colored?

[ChrisMcGovern]

Maybe I haven't looked or experimented enough, but on the API reference page at:
http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/arcgis/help/jsapi_start.htm#jsapi/si...

The part that talks about fill styles for graphics states

The fill style. See the Constants table for valid values. The default value is STYLE_SOLID. Color is valid only with STYLE_SOLID.

So I cannot create a hatch patterned graphic who's hatch lines are not default black?

I want a graphic with a red outline and red hatch pattern fill. Can it be done?

[TrinaNair]

2.8 just came out.  Maybe the documentation is still dated with 2.7.  Have you tried it?

[AdrianMarsden]

This still seems to be the case at 3.5 - is that really the case??  Amazing oversight surely?

Any work a-rounds?

Cheers

ACM

[MichaelSmith2]

This still seems to be the case at 3.5 - is that really the case??

Still the case at 3.7. Not only that, it is not just Firefox, neither Internet Explorer nor Chrome can apply color or transparency values to hatch patterns. What is up with color for hatch pattern fills in the Javascript API? The ArcGIS for Flex team implemented this a couple years ago.

[BenFousek]

The hatch patterns cannot be altered via the api because they are images.

Only STYLE_SOLID will use the color provided. STYLE_SOLID and STYLE_NULL are the only "pure" esri/symbol/SimpleFillSymbol(s).

All the other fill options like STYLE_BACKWARD_DIAGONAL, are actually esri/symbol/PictureFillSymbol(s), which use images that are included in the api http://js.arcgis.com/3.7/js/esri/images/symbol/sfs/vertical.png.

The solution, work-around or what have you is to use esri/symbol/PictureFillSymbol with your own custom images.

[MichaelSmith2]

Thank you Ben for the description of why it does not work. However, I think this is something that needs to be justified by the Javascript API team as it does not answer the fundamental question of why this is the case to begin with.

The plain fact is the Javascript API team has once again shown it is not as concerned about its user community as the other API teams. The Flex team was able to incorporate this hatch fill capability into their API at least three years ago (when I first used it). My guess is the Flex Team did it because it helps to build new applications more rapidly. I want to change the fill so the graphic features called by a Find function are both color-coded based on whether the graphic is for a jurisdiction, school district, fire district, or water district and show the actual color values of the features under them. Now I have to create four images before I can finish the tools I am working on instead of just coding in a color value and moving on to the next thing.

Trust me, if Flex was supported on mobile devices I wouldn't touch the Javascript API. Sure, if you are a full-time coder, their bare bones API and lack of plug-and-play tools is probably fine, but experts are not what ESRI focuses on. When you listen to Jack, ESRI wants everyone to be able to create data, maps, and applications with as little hassle as practical. The other API teams get this. I was able to get my first Flex application up and running within two days (I did not use their application builder) because they release template viewers with each release of their API. After it was up and running I was able to customize it so it looked and performed the way I wanted it to because of the rapid progress I was able to make with the template and tools they developed for their user community. When a group within its user community expressed that they wanted the same thing, the Javascript API team responded that that wasn't their problem as they did not believe in providing template applications as they were personally concerned that that might lead to too many applications in the wild that looked the same.

We do not have plans to add a "layer list" or "table of contents" widget to manage map layers and sublayers. We've resisted adding this to the API because we don't want to encourage building generic, kitchen sink style viewers. I realize that we (Esri) do not have a consistent story on this as we still provide generic viewers for other platforms/technologies. We're open to discussing it further, but I personally agree with anti-viewer, anti-portal sentiments that some have expressed online for the past couple of years.
- Derek Swingley (ArcGIS API for JavaScript Team Member)

Then, once they did begrudgingly produce a template viewer, they produced something that was so convoluted and hard to build on that I can only suspect that they did it intentionally to prevent anyone from asking them to do it again.

The ArcGIS API for Javascript Team, turning ESRI's "GIS for Everyone" slogan into "GIS for Experts and Consultants."

[FredSpataro]

Adding some more details for everyone's reference, since I spent too much time trying to solve the same problem...

I don't have a definitive answer but if you look at the documentation for SVG path drawing (Fills and Strokes - SVG | MDN ), it's actually not technically possible to "fill" with a hatch pattern.  This means the symbol would have to manually draw each hatch line as a separate path which would be ugly code and a performance hit.  One potential option would be to create a "dynamically colored" image to use as the fill, but I didn't find a simple solution for that either (EDIT: actually that is what's implemented in Simon's solution below, but it uses data:Uri, which aren't fully backward compatible to older browsers).  

So I can't really fault the Javascript team for skipping this implementation but a simple note in the docs "if you want a colored hatch fill, (which you probably have in your map service), use a PictureFillSymbol. Here's our black & white ones...." would have saved hours of wasted time.

[SimonUyttendaele]

As @btfou mentioned, the pattern is displayed via images (background-image css property).
However, there is a valid solution to this issue which just hasn't been implemented in the API (yet).

Please vote upon the following idea which is precisely about this.

Meanwhile, you can use the following solution.

Regards

[AdrianMarsden]

Hi

I have just had a quick go with that solution, but I can't seem to get it incorporated into my legacy (nonAMD) code.  Any pointers anyone.  No obvious error messages.

Cheers

ACM

edit - it was this

if( !fill.src.startsWith('data:image/png;base64,') )

that my code didn't like - removing it and it all works

[DanielWebb2]

I agree with other commenters that the non-solid fills in polygons should be able to have different colors.

However, I found that when I define an outline color for the polygon, the inner hatch will have the same color when printed to a PDF (even though the inner hatch shows black on the app).

This might not be the best solution, but at least users can still have different colors on the printed maps.

Hope this helps someone!