[UI] Pinesoft-Widgets-gvc.242 and
gazzaguru2 at btinternet.com
Mon Oct 22 09:32:23 UTC 2007
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
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).
> -----Original Message-----
> From: ui-bounces at lists.squeakfoundation.org
> [mailto:ui-bounces at lists.squeakfoundation.org]On Behalf Of Klaus D.
> Sent: 20 October 2007 3:12 PM
> To: ui at lists.squeakfoundation.org
> Subject: [UI] Pinesoft-Widgets-gvc.242 and
> 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
> 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.
> UI mailing list
> UI at lists.squeakfoundation.org
More information about the UI