Strange ComboBox problem & empirical solution

Dear newsgroup,

    I've found that when an attribute value's nil in an object that is part
of a collection you want to be displayed in a ComboBox, brings a problem.
When the application tries to open a window with this combo, some dialog for
example, it gets a invalid memory call. When tracking the problem, I could
find that an object with the attribute it wants to show was in nil.

You will find that this invalid call will happend only in two circunstances:

1. When you deploy an exe (in the development environment everythigs works
OK)

2. When you disable the XP look and feel of the Dolphin by modifying it's
installation, and try it in the development environment

I've fixed it by changing the getTextBlock on all the combos, for example if
the attribute is [:e| e description] , now is [:e| e descriptionString] and
the accesor:

--------------------------------------------------

ItemObject>>descriptionString

description ifNil:[ ^'?' ].

^ description

--------------------------------------------------

best regards,

Sebastián Sastre

[hidden email]

www.seaswork.com.ar <http://www.seaswork.com.ar/>

Sebastian

You wrote in message news:bqnm66$245n3d$[hidden email]...
> ...
>     I've found that when an attribute value's nil in an object that is
part
> of a collection you want to be displayed in a ComboBox, brings a problem.
> When the application tries to open a window with this combo, some dialog
for
> example, it gets a invalid memory call. When tracking the problem, I could
> find that an object with the attribute it wants to show was in nil.

Yes, this is really an error in the definition of your #getTextBlock. The
block must return a string. Even nil is not acceptable, though you may "get
away with it" in some cases.

However in the wrappers for the more sophisticated controls (ListView,
TreeView, etc) we made a modification in an earlier version (Dolphin 4.0 I
think) that makes them tolerant of this error, which is to always send
#displayString to whatever result is returned by the user defined
getTextBlock. This carries an insignificant overhead if the block does
answer a string, and prevents errors from occurring if it doesn't.  I've
entered an enhancement request to do the same for BasicListAbstract (the
superclass of Combobox), #1432. This will not, however, appear in 5.1.3, but
you can apply the hotfix patch below if you wish.

Regards

Blair
---------------------------
!BasicListAbstract methodsFor!

basicAdd: anObject
 "Private - Adds a string for the <Object> argument to the listbox control
at the end of the
 list. Answers the argument."

 self
  sendMessage: self addStringMessage
  wParam: 0
  lpParam: (getTextBlock value: anObject) displayString.
 ^anObject! !
!BasicListAbstract categoriesFor: #basicAdd:!adding!private! !

!BasicListAbstract methodsFor!

basicAdd: anObject atIndex: anInteger
 "Private - Adds a string for the <Object> argument to the listbox control
at the specified
 1-based <integer> index. If anInteger is zero then the string is added to
the end of the
 list. Answer anObject."

 self
  sendMessage: self insertStringMessage
  wParam: anInteger - 1
  lpParam: (getTextBlock value: anObject) displayString.
 ^anObject! !
!BasicListAbstract categoriesFor: #basicAdd:atIndex:!adding!private! !