#897 Inconsistent highlighting of rows

[ooofest]

When JBidWatcher first starts up, no items in the
initial tab's list are selected with a highlight. Upon
clicking any visible row, a dark grey background is
used to highlight that specific row.

This dark grey highlight remains on the UI for selected
rows until the program is restarted.

Additionally, a right-mouse-button click can bring up
the context menu for any visible row, but how that
context menu visually relates to a dark grey highlit
rows is not intuitive.

Some suggestions to minimize confusion with the row
highlighting in each tab:

1. When JBidWatcher first launches, highlight the
first row (or, last selected row(s) - if an option is
offered) within the initially shown tab. If no rows,
obviously there won't be anything to highlight.

2. On RMB clicks, perhaps bold the text of row(s) in
question, so as to show where the context menu visually
relates - even if that relation does not fall within a
currently selected row or rows.

[ooofest]

Logged In: YES
user_id=1269853

I should have mentioned that there is an alternative to item
2: any time a user right-mouse-button clicks to obtain a
context menu for a row, then ensure that row is highlighted
- either by it being already highlighted and/or included a
in group of highlighted rows when a Ctrl or Shift key is
pressed at the same time.

[Nobody/Anonymous]

Logged In: NO

I think, to clarify a point here:

Clicking the right mouse button on the grid does NOT move
the selection highlight before it shows the menu. Hence in
a ten item list, if you left click item 2 so it goes
highlighted, then move the mouse down and right click item
8, then the context menu that appears will actually be
related to item 2

Workaround: Users must always left click on the row they
want to menu, before right clicking to show the menu

[Morgan Schweers]

Logged In: YES
user_id=19745
Originator: NO

Greetings,
Bugs filed before 1.0 and bugs without responders are being juggled in terms of priority (9 is highest priority). I'm raising bugs filed with a submitter, post-1.0 to P6. Bugs which are filed post-1.0, but without a submitter are P5. Before 1.0 bugs with a submitter are becoming P4, and pre-1.0 bugs without a submitter name become P3.

If the bug is still relevant, and has a watcher (i.e. you got notified when I changed this bug), feel free to bubble it back up again.

Email addresses in bugs are great, but I can't always respond via email. Sometimes, especially for duplicate bugs, I use automated tools (like I'm doing right now) to change status on a large number of items at once.

Thanks for your patience, while I try to pare back the bug list to what may actually still be in the program.

-- Morgan Schweers, CyberFOX!