Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!ix.netcom.com!netcom.com!billw
From: billw@netcom.com (William Wright)
Subject: ParcPlace Combo Boxes
Message-ID: <billwDAqErC.ByI@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Sun, 25 Jun 1995 13:57:12 GMT
Lines: 65
Sender: billw@netcom4.netcom.com


ParcPlace VisualWorks 2.0 Problem with Combo Boxes

In ParcPlace there is a UI widget called a ComboBox. This is
basically a drop down single selection list, but, unlike the 
selectionInList object, is implemented very poorly. I am at a
lost to explain why ParcPlace implemented this widget so
differently from the selectionInList. The ComboBox should
simply accept a list of objects and answer the selected object
whenever the #selection message is sent to it (just like the
selectionInList widget), but it doesn't work this way.

Upon changing the selection in a ComboBox a bizarre 
sequence of events takes place. The ComboBoxInputBoxController
gets sent the message #takeNewEditText: aText. The last thing
this method does is send itself the #checkForAutoAccept message to 
itself. This message sends #privateAccept which sends 
#hasEditValue to itself. This message does the following:

	editValue
	   | v |
	   v := displayContents text copy.
	   converter notNil
		ifTrue: [ v := converter readValueFrom: v]
	   ^v.

converter is a PrintConverter and the method readValueFrom:
is written like this:

	readValueFrom: aPrintRep
	   ^toRead value: aPrintRep.

The ivar toRead is a block of code that has been setup to try and compile
the text of the selected object!! Hence, when you try to change selections
in a ComboBox which contains a list of objects, you don't get a walkback
but get a text pane opening up with the message "Syntax Error"!! This is
absolute bizarre. You can't even debug the problem because you don't 
have a debugger! I am very confused by this sequence of events. I don't
know why the ComboBox is implemented in such a vastly different manner
from the selectionInList. They should be almost identical.

The above problem can be solved by changing the
PrintConvert>>readValueFrom: message, which is only called from this
ComboBoxInputBoxController path, to the following:

	readValueFrom: aPrintRep
	   ^toPrint value: aPrintRep.

This makes sense, since at this point all the system should be trying to do
is obtain the printed form of the selected object so that it can be dispayed
as the value. Not try to compile the printed representation! Why would you
ever want to do that when selecting from a ComboBox!? But even with 
this hack, I'm confused. Why the histrionics for something so simply?
Does anyone have a clue what ParcPlace was trying to do with this
widget and why they got it so messed up?

Any help/comments appreciated. Obviously, I am quite confused.

Thanks,
Bill Wright
-- 
Bill Wright	(billw@netcom.com)
             or (bill_wright@mail.amsinc.com)
Home: (303) 494-7232
Work: (303) 969-3583
