On Thursday 05 April 2001 00:30, Markus Gälli wrote:
> am 04.04.2001 19:02 Uhr schrieb Ned Konz unter ned at bike-nomad.com:
> > I've just published a new version on Bob's with the following changes:
> > * added UML class diagram button bar
> > * added more shape constructors, especially for UML shapes.
> > * fixed NCConnectorMorph owner logic in cases where both ends connect to
> > shapes that are on different playfields
> >
> > I'm still looking forward to comments and criticism, as well as
> > suggestions and wish-lists.
> >
> > I'd like to formally publish the change set(s) soon...
>
> Hello Ned,
>  thanks for your great work.
> One bug I might have found:
> - Drag a handle of a connector on the start /end of the connector and drop
> it. Squeak on my system (powerbook pismo os9.01) went into a loop. Can you
> reproduce that? Otherwise I'd try again and give you more specific info.

No, I haven't been able to see it (if I had, you wouldn't be...). Can you 
interrupt it (using alt-. or cmd-.) and get me a stack trace?

> Some questions:
> - How do I destroy handles of connectors (especially the last one)?

What do you mean by "destroy handles"? If you mean the little red squares, 
they'll be visible until they're connected to something. What are you trying 
to do? How would you like it to look?

If you just want a line, use a LineMorph (or PolygonMorph). If you want to 
have a line that's connected on one end, you can (programmatically) turn off 
the visibility of the handle using:

	myConnector constraints last visible: false

I suppose I could change the code so that the "connect to nothing" menu 
choice also makes the handle invisible (and the other connect choices make it 
visible). Would that work?

> - As I wrote a neural network-simulator on VW2.5 with HotDraw, I know
> HotDraw a bit. As I remember, also the connections hade a modelthere, so I
> could easily double the hierarchy (Graphical/Morph-Stuff vs. the domain).
> I'd like to stick with that design, do I need to subclass the connector,
> or can I use it as it comes? How?

It depends on what you want to do. If you want to update a model through 
making attachments, you can subclass and override (for connectors)
	enterConnected
but this is more of an internal method, and I wouldn't recommend it for 
permanent code (see below).

and for other shapes, you can override:
	Morph>>attachFrom:at:

but I haven't really addressed using these in a program yet (which is why I 
haven't published the change sets yet). That's next on my list...

What I think I'm going to do is have a notification called when the 
connections on a connector change, perhaps:
	NCConnectorMorph>>connectionsChanged.
>From that in a subclass, you can look at the connections:
	self connections
which will return a 2-element Array with whatever the ends are connected to.
I suspect that I'll change the existing connections method to always return a 
2-element Array, and rename connections to validConnections.

Another strategy is to just use the existing event notification mechanism in 
Object (when:send:to:, trigger:, etc.)

Which would you prefer? Subclassing or event notification? I could also (or 
instead) make the individual NCConstraintMorphs trigger event notifications 
when their inputs are changed, so you could watch when just one end of a 
connector (or anything else that uses an NCConstraintMorph, like a 
NCLabelMorph) gets changed.

I also need to make some way for Morphs and Connectors to reject attachments 
(to keep a model valid). I was thinking about a 2-way query like the one that 
currently handles morph dropping (wantsDroppedMorph:event: and 
wantsToBeDroppedInto:), but would need some additional information (like 
which end is being connected (or disconnected?)).

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com