Klaus,
For the #nextSlotFor: method my changes were just to take into account the border width of the bar. Looking at the method I guess it would fall through if all (10) bar slots are considered to be occupied (non-nil and having an owner). However, the value of activeSlots *should* be 10 also, at this point, leading to an early return of 0. So the self return is likely to only happen if all slots are full and the activeSlots count is out of sync for whatever reason...
This would, of course, happen with the original method also.
The #label:min:max: method includes some enhancements by Keith Hodges but has the same protection check as the original method, so a self return from #nextSlotFor: would cause an error as with the original.
It might be worth your while investigating the activeSlots value at the time when the error occurs.
To cleanup try doing SystemProgressMorph reset and see if it helps (changing the uiTheme sends this also).
Gary.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Klaus D. Witzel Sent: 20 October 2007 3:12 PM To: ui@lists.squeakfoundation.org Subject: [UI] Pinesoft-Widgets-gvc.242 and SystemProgressMorph>>#nextSlotFor:
Gary,
I've seen you adapted this method, could I have a 2nd opinion regarding its use.
When #nextSlotFor: finds a slot with nil it puts a SystemProgressBarMorph into the slot and returns the corresponding index.
When it finds an occupied slot which has nil owner it also returns the corresponding index.
When all that fails it defaults to return self :(
I have an image in which the sender, #label:min:max:, fails when it attempts to do
bar := bars at: slot
because slot := self was returned by #nextSlotFor:.
Do you see a workaround/fix other than returning 0 at the end of #nextSlotFor:, what could be the reason for #nextSlotFor: to fall through.
Thanks in advance.
/Klaus
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui