Pinesoft-Widgets-gvc.242 and SystemProgressMorph>>#nextSlotFor:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Pinesoft-Widgets-gvc.242 and SystemProgressMorph>>#nextSlotFor:

Klaus D. Witzel
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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: Pinesoft-Widgets-gvc.242 and SystemProgressMorph>>#nextSlotFor:

Gary Chambers-4
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: [hidden email]
> [mailto:[hidden email]]On Behalf Of Klaus D.
> Witzel
> Sent: 20 October 2007 3:12 PM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: Pinesoft-Widgets-gvc.242 and SystemProgressMorph>>#nextSlotFor:

Klaus D. Witzel
Thank you Gary, SystemProgressMorph reset is of great help here.

Debugging activeSlots is not easy since until a debugger finds its way to  
the screen things look as having been changed already. Maybe, perhaps,  
it's a race problem.

Thanks again.

/Klaus

On Mon, 22 Oct 2007 11:32:23 +0200, Gary Chambers wrote:

> 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: [hidden email]
>> [mailto:[hidden email]]On Behalf Of Klaus D.
>> Witzel
>> Sent: 20 October 2007 3:12 PM
>> To: [hidden email]
>> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/ui


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui