`apply_statusbar` read `file=` and `<Color>` off `<BarTexture>` and passed them to
`SetStatusBarTexture`, which builds the fill region itself. Every other attribute of
the element went unread, `name=` among them. In the reference `<BarTexture>` is a
Texture element and StatusBar's LoadXML (`0x782ef0`) builds the fill through the
shared texture ctor, which registers the name like any other region's.
A dropped `name=` is invisible until Lua reaches for the global, and then it raises
inside the addon. ATSW2's `SPELLCAST_START` arm shows the progress bar, tints it per
ore through `ATSWProgressBarTexture` — the raise — and only then calls
`ATSW_StartProcessing`. So every craft left the bar shown and running with nothing
able to stop it: `Processing.Active` stayed false, `SPELLCAST_INTERRUPTED` was never
registered, `ATSW_StopProcessing` and `ATSW_CompleteTask` were never reached, and the
guard `not Processing.Active` let the next craft re-raise. grom's log has seven in a
row and his screenshot has the stuck bar.
Named now, both ways, as Button state textures already were: the region registry for
`GetName()` and `_G` for `getglobal` and a sibling's `relativeTo`. A named
`<BarTexture>` with no paint still builds its region. Four of the five in this install
declare a name (`ATSWProgressBarTexture`, `ATSWRankFrameBar`, two QuickHeal bars); no
stock FrameXML status bar names its fill, so the base interface neither gains a global
nor collides with one.
Also in the skin: the reagent names under the icons take the same black-to-white
`SetTextColor` wrapper as the tools line. They measured 1/1/1 in a capture and read as
correct, but a capture has no item links and `ATSW_ShowRecipe` paints the title black
only inside `if RLink then` — in play it runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
b39651d9b4