Fixed. New build triggered
But be careful you donāt use odd numbers for outlines. It will not line up right.

Fixed. New build triggered
But be careful you donāt use odd numbers for outlines. It will not line up right.

Super! Thanks!
This fix apparently scrambled something else.
See the result of
image bounds(10, 102, 373, 58) corners(5) colour(30, 30, 30, 255) outlineColour(255, 255, 255, 100) outlineThickness(2) channel("image100")
image bounds(10, 166, 373, 58) corners(5) colour(30, 30, 30, 255) outlineColour(255, 0, 0, 100) outlineThickness(2) channel("image101")
image bounds(10, 166, 373, 58) corners(5) colour(255, 100, 0, 30) outlineColour(255, 0, 0, 100) outlineThickness(2) channel("image102")
in build #20210708.3 Merge branch ādevelopā of https://github.com/rorywalsh/cabbage into develop (left) and #20210708.4 fixing outlineThickess issue for image widget (right)
There is some transparency change and
note also the line thickness change.
No stress if you donāt manage over the weekend
Iāll make use of an older build for now, because I hardly see my widgets now (transparency issue).
Yup, I definitely screwed something up. Sorry, Iāll try to get that sorted asapā¦
I pushed for a fix for this now. Latest Azure build should have it. Apologies for screwing this one up
It looks normal now:

Iām not entirely happy with the drawing. I might try using a path for these widgets in the future. And I also noticed a long standing ābugā if you could call it that. But the outline of the rectangle is drawn over the underlying rectangle. So the outline colour may be affected by the underlying rectangle colour depending on the alpha blend. I canāt imagine thatās useful for anyone 
Youāre incredible! Thank you for so fast fixing! It is so exciting to see Cabbage getting better and better day by day, hour by hour!
Well, I guess some little steps backwards sometimes are inevitable on a real journey 
Iām sorry to return to this with a fresh new issue. The last fixes gave birth to a āfantasticā new little Cabbage destroyer! It has to do with checkbox and trighold that I use to blink a ālight indicatorā.
The code below used to work before. Now it is (1) blinking kind of randomly and it seems to mess with the form, because (2) it doesnāt stop blinking after I turn the instrument off, and (3) it also causes rslider to jump around (you get that when you move the slider to some sweet spots).
Please try running this simple example:
<Cabbage>
form caption("Test") size(350, 200), colour(0,0,0), guiMode("queue"), pluginId("sfi1")
rslider bounds(10, 10, 140, 110) range(0, 100, 0, 0.5, 0.0001) channel("slider1") colour(200, 200, 200, 255) trackerColour(200, 255, 200, 255) markerColour(0, 0, 0, 255) popupText("0")
checkbox bounds(150, 24, 20, 20), colour:0(255, 255, 0, 150), colour:1(255, 255, 0, 255) channel("blinkCheckBox"), value(0), shape("ellipse"), active(0) automatable(0)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d ;--midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
ksmps = 32
instr 1
kMetro = metro:k(cabbageGetValue:k("slider1"))
cabbageSetValue "blinkCheckBox", trighold:k(kMetro,1/ksmps) ; blink
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
i1 0 z
</CsScore>
</CsoundSynthesizer>
[edit] I actually had to go back to 2.7.5 to get rid of it, havenāt tried 2.7.6.
For now I can solve this by using cabbageSet on an image within a special devoted triggered instrument, but it seems a less elegant solution to blinking lights. Iād also be interested in any comments/suggestions on this.
This should be fixed now. I just triggered a new build. It was a recursive loop in the checkbox widget, but honestly, I canāt see how this worked in earlier versions. The last change made to the checkbox class was in April.
Can you test the latest build?
Iām glad you found the bugger and will test soon when it builds. Iām quite regularly updating beta versions last few months and I tested today with 2.7.5. Strange indeed. Hopefully there was not another recursive loop spinning in the opposite direction so they cancelled each other 
Now it works. Thank you!!!
Hi Rory, congrats and best wishes for the baby and the family!
A quick question: if I have a custom identifier and I click the widget or I move it, the identifier is erased.
Would it be possible to remedy this little nuisance?
Agreed, totally annoying behaviour. I think the new build system is almost ready, so I can start pushing out some bug fixes / feature in the next week. 
Two questions:
combobox items at init, e.g. cabbageSet ācomboā, ātext(āAā,āBā)āThanks!
I fixed this a week ago, but Iām still trying to put the finishing touches on the new build system. I should hopefully have new beta builds ready for later this evening 
I think this is only possible if you set the channel type to string, as a combobox that can be automated by the host cannot have its items changed at run time.
Thanks!
The changing of items makes sense (now again). I read it before in the docs, but managed to forget and think that the names list would be an attribute just like colour. So, I guess cabbageCreate might do the job ⦠as long as I am not mousing on the widget after.
yeah, itās because the host assigned a range to any widget that is automatable. If one changes this afterwards it will mess up the host automation. That being said, it should be possible with string channel comboboxes as these are not automatable.
I actually used automatable(0) but this still doesnāt permit changing the items, right?
I see that this works, but I still prefer the default behaviour, it seems easier to associate with array values and shows 0th item as default/initial, while with string, no item seems to be selected initially (but maybe thatās easy to change with some initial value?)ā¦
Did you use channelType("string")
Use can set the initial value using value("string")
Yes. With strings it works⦠but tedious to associate to array values. I donāt need automation on thisā¦