开云体育

Bob,

Tried out 0-9-3-2 today. Sorry if these comments seem overly critical, and
of course they are just one person's opinion. And no I'm not just miffed
because the flyouts weren't possible :-) As always I am very appreciative
of all your efforts and for the opportunity you have provided for us to
provide input and voice opinions.

Ok. First I think the programmer display is too busy now. Could the
Manufacturer name list be converted to a combo box? That might help. The
mfr list is quite long, but many don't have any decoders available. Perhaps
suppressing those would make it easier to get through the list. In any
case, I would suggest making the mfr default to the one that was selected
the last time the programmer was used would be a good thing.

It looks like the decoder family names show up in the decoder list. I found
this very confusing. This might be ok if there was a way to see that there
were two distinct types of items in the list - family names and decoder
names. For example indenting, bolding, or something else might make it
more apparent, especially if the app would prevent the user from selecting a
family name (but I fear that would not be easy to implement). I was able to
open a programmer with a family name selected, but the config did not match
any of the members of that family for the Throttle-Up decoders I checked.
(maybe this is really a problem in the throttle-up decoder files I made?)

In the case where there is only one decoder in the family it was especially
confusing since it seemed unclear which name to select. For example, under
Throttle-Up there is "Soundtraxx DSD Diesel decoders" on one line followed
by "DSD Diesel" on the next line. Maybe changing the word "decoders" to
"family" would help, but I don't think that will be enough to eliminate all
confusion. (Selecting the DSD diesel family name produces a programmer with
only 4 columns in the function map, while selecting the DSD diesel decoder
name produces the correct function mapping with 12 columns.)

Other stuff

Would it be possible to update the mfr and decoder list selections when the
user selects an item from the "Use locomotive settings for" combo box? This
would be a handy way of checking roster entries to see what decoder types
were used.

I was able to open more than one programmer setup window at the same time.
Hadn't noticed this before. Wouldn't think you would want this for
programming track use. If Ops mode programming gets supported this might be
good, but you would probably want to supress programming of the loco ID in
this case?

The mfr name list was scrambled when I first ran the update. After
reindexing it appeared in alphabetical order.


Robin

Sorry for the slow reply, it's been a busy week. Also, I've rearranged the paragraphs below so the reply makes more sense, and coincidentally to put the good news first.

At 3:30 PM -0700 6/19/02, Robin Becker wrote:

Bob,

Tried out 0-9-3-2 today. Sorry if these comments seem overly critical, and
of course they are just one person's opinion.

No problem. I _like_ getting feedback like this, and wish there was more of it.

Ok. First I think the programmer display is too busy now. Could the
Manufacturer name list be converted to a combo box? That might help. The
mfr list is quite long, but many don't have any decoders available. Perhaps
suppressing those would make it easier to get through the list. In any
case, I would suggest making the mfr default to the one that was selected
the last time the programmer was used would be a good thing.

I shortened the list to just manufacturers that have one or more decoders defined. That does make it cleaner, thanks. A manufacturer will also show up if one of their decoder is seen when doing an identify, just so it's clear what was seen by the programmer; in that case there's still no decoder name shown though.

Making it default is a good idea, I'll try to do that.

I tried to switch back to a combobox (selection box) for the manufacturer, but with the decoders in a list it looks really ugly. But that got me thinking of another approach, see below.

Would it be possible to update the mfr and decoder list selections when the
user selects an item from the "Use locomotive settings for" combo box? This
would be a handy way of checking roster entries to see what decoder types
were used.

Great idea! I did that.

The mfr name list was scrambled when I first ran the update. After
reindexing it appeared in alphabetical order.

Right, that's due to the auto-index-on-update feature that's still missing. I've got to get to that pretty soon...

I was able to open more than one programmer setup window at the same time.
Hadn't noticed this before. Wouldn't think you would want this for
programming track use. If Ops mode programming gets supported this might be
good, but you would probably want to supress programming of the loco ID in
this case?

This is just laziness on my part. I was putting off fixing this until I had ops mode programming working, but it's not yet ready yet. The idea was that you could open as many ops-mode windows as you want, but only one that used the programming track. I'd prefer to not fix it now, as I'd rather fix it as part of reworking the first screen to include an ops-mode button. OK?

It looks like the decoder family names show up in the decoder list. I found
this very confusing. This might be ok if there was a way to see that there
were two distinct types of items in the list - family names and decoder
names. For example indenting, bolding, or something else might make it
more apparent, especially if the app would prevent the user from selecting a
family name (but I fear that would not be easy to implement). I was able to
open a programmer with a family name selected, but the config did not match
any of the members of that family for the Throttle-Up decoders I checked.
(maybe this is really a problem in the throttle-up decoder files I made?)

In the case where there is only one decoder in the family it was especially
confusing since it seemed unclear which name to select. For example, under
Throttle-Up there is "Soundtraxx DSD Diesel decoders" on one line followed
by "DSD Diesel" on the next line. Maybe changing the word "decoders" to
"family" would help, but I don't think that will be enough to eliminate all
confusion. (Selecting the DSD diesel family name produces a programmer with
only 4 columns in the function map, while selecting the DSD diesel decoder
name produces the correct function mapping with 12 columns.)

All of these points are correct, and important.

When I was working on this interface, I was mostly concentrating on the case of Digitrax and Lenz decoders (which I have). They have a large number of defined decoders in a couple of families. For them, the interface seems to work OK. You select "Digitrax", and get a pretty long list, and just look for your decoder; you can ignore the family names. But people tend to refer to decoders as "FX decoders", so if that's what you think you've got, you can select that family and it also works. And when you push "ident", it shows you a nice list of the possible specific models within the family that was identified by CV7.

Unfortunately, it seems that this breaks down for Soundtraxx. They've done a better job of identifying specific _decoders_ with CV7, so there's less of a need for the "family" idea. And the list of all Soundtraxx decoders you get when you select the manufacturer is _really_ hard to read because of that.

I started to think of a way to use indenting to make all this clearer, but it soon occurred to me that I was recreating a "tree" structure.

So let me ask the accumulated wisdom on the list: Would a tree GUI work better?

The idea would be to have a single part of the selection window (probably with scroll bars) that shows a tree ala the various "Explorer" things. The tree would have three levels: Manufacturer, with family below that, and decoder below that. For cases like Soundtraxx DSD Diesel, where there's no clear distinction between family and model, just the model would appear directly under the manfacturer name.

At first, just the list of manufacturers would appear. You could click on one to open it, and see all the families and decoders. Selecting a decoder or family would let you push the open-programmer button. Only one could be selected at a time.

If you use the ident button, the tree would be closed-up except for the part of it that satisfies the identify results. If that's a specific decoder, that'll be open and selected. If a family was identified (e.g. Digitrax FX), the tree will be open to them, with the general family selected, and all the individual decoders visible. If the model (CV7) wasn't recognized, all the decoders for that manufacturer will be unfolded. Etc.

The only thing that I can think of that this would make _more_ difficult is "I've got a DH142 decoder, and I can't remember which manufacturer made it"; in that case, the user would have to open all the manufacturer names to look for it. (I could start with everything open in the tree, but that's really annoying to people who're looking for a specific thing). And in that case, clicking ident will go to the right place anyway.

This has the other advantage of being easy to code.

What do people think? Should I code it up so people can try it?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.

I shortened the list to just manufacturers that have one or more
decoders defined. That does make it cleaner, thanks. A manufacturer
will also show up if one of their decoder is seen when doing an
identify, just so it's clear what was seen by the programmer; in that
case there's still no decoder name shown though.

This is the first time I have tried this for a while so I haven't seen all
the intermediate versions but I like this a lot more that what we had
before. I think it is good.

I guess the smoke is still comming off this version, but after I first went
in, created a new roster entry, read all the CVs from one of my locos
values, saved the config and then tried to reload by selecting the roster
entry at the top of the screen, it throws a NullPointerExecption at this
line in CombinedLocoSelListPane:

String modelString = locoEntry.getDecoderModel();

Here is the stack trace

Exception occurred during event dispatching:
java.lang.NullPointerException
at
jmri.jmrit.symbolicprog.CombinedLocoSelListPane.setDecoderSelectionFromLoco(
CombinedLocoSelListPane.java:233)
at
jmri.jmrit.symbolicprog.CombinedLocoSelPane$3.actionPerformed(CombinedLocoSe
lPane.java:135)
at javax.swing.JComboBox.fireActionEvent(JComboBox.java:870)
at javax.swing.JComboBox.selectedItemChanged(JComboBox.java:894)
at javax.swing.JComboBox.contentsChanged(JComboBox.java:950)
at javax.swing.JComboBox.intervalRemoved(JComboBox.java:1017)
at
javax.swing.AbstractListModel.fireIntervalRemoved(AbstractListModel.java:137
)
at
javax.swing.DefaultComboBoxModel.removeAllElements(DefaultComboBoxModel.java
:167)
at javax.swing.JComboBox.removeAllItems(JComboBox.java:568)
at jmri.jmrit.roster.Roster.updateComboBox(Roster.java:107)
at
jmri.jmrit.symbolicprog.CombinedLocoSelPane.propertyChange(CombinedLocoSelPa
ne.java:245)
at
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.ja
va:152)
at jmri.jmrit.roster.Roster.firePropertyChange(Roster.java:290)
at jmri.jmrit.roster.Roster.addEntry(Roster.java:70)
at
jmri.jmrit.symbolicprog.CombinedLocoSelPane.openNewLoco(CombinedLocoSelPane.
java:403)
at
jmri.jmrit.symbolicprog.CombinedLocoSelPane.openButton(CombinedLocoSelPane.j
ava:362)
at
jmri.jmrit.symbolicprog.CombinedLocoSelPane$5.actionPerformed(CombinedLocoSe
lPane.java:175)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)
at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButto
n.java:1504)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:3
78)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)
at
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener
.java:216)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:230)
at java.awt.Component.processMouseEvent(Component.java:3715)
at java.awt.Component.processEvent(Component.java:3544)
at java.awt.Container.processEvent(Container.java:1164)
at java.awt.Component.dispatchEventImpl(Component.java:2593)
at java.awt.Container.dispatchEventImpl(Container.java:1213)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1200)
at java.awt.Window.dispatchEventImpl(Window.java:926)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:131)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:98)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)

It seems that there is a problem with either

locoBox.getSelectedIndex()
or
locoBox.getSelectedItem()

in CombinedLocoSelPane around line 133

IMHO I think the whole roster thing is overkill and has added a level of
complexity that we could do without right now. I would be happier with just
saving a locos config to discrete files with the decoder address as the
filename and pop-up a file Load/Save dialog box that would let me choose
subdirectories etc so I can manage where things end up.

Anyway no matter how this stuff works - this is way better than fumbling
with the manual and my DT400 while doing hex conversions in my head... even
if I don't save anything to rosters etc and load it all from scratch out of
the loco...

Cheers

Alex