EditToolbar reverts TextSymbol halo color to white

195
2
Jump to solution
11-06-2017 01:33 PM
YohanBienvenue
Occasional Contributor II

ArcGIS JavaScript API 3.22

Recently we added the possibility for the user to set the Halo color of the TextSymbol for new Graphics added to the map. The user sets the color first and then the app will setHaloColor of the symbol before the Graphic is added to the map. It works fine, except I noticed that the first time a text Graphic in the map is put in edit mode using this.editToolbar.activate(Edit.MOVE | Edit.SCALE | Edit.ROTATE, graphic, {}); then the halo color of that Graphic will revert to white.

If I inspect the SVG element using the chrome dev tools, I will literally see the filter attribute color change back to 255_255_255_1 when I edit the Graphic.

It happens only the first time, one time. It's fine after that for any other Graphic. Until the web app is reloaded.

 It happens will all browsers. Almost seems like a bug where somewhere in the API some variable is not set at first, and it breaks the halo color only the first time editToolbar.activate is used.

Can anyone confirm this issue?

Thanks

0 Kudos
1 Solution

Accepted Solutions
YohanBienvenue
Occasional Contributor II

Thanks Robert. I mainly wanted confirmation of the bug, so I'm grateful for that.

I'll stop looking for a mistake in our own code.

I tried the workaround suggested in the other post but it just didn't work for me. I tried a bunch of variations too, included redraw call for the GraphicLayer, added setTimeout before removing the temp graphic, etc.. but it still happens.

For now I'll just document the bug in our code as a known issue. It's too minor to waste additional time on it.

Thanks

View solution in original post

2 Replies
RobertScheitlin__GISP
MVP Esteemed Contributor
YohanBienvenue
Occasional Contributor II

Thanks Robert. I mainly wanted confirmation of the bug, so I'm grateful for that.

I'll stop looking for a mistake in our own code.

I tried the workaround suggested in the other post but it just didn't work for me. I tried a bunch of variations too, included redraw call for the GraphicLayer, added setTimeout before removing the temp graphic, etc.. but it still happens.

For now I'll just document the bug in our code as a known issue. It's too minor to waste additional time on it.

Thanks

View solution in original post