On Fri, Oct 31, 2014 at 12:04:03PM -0400, John Van Ostrand wrote: > On Fri, Oct 31, 2014 at 10:45 AM, Dirk Hohndel <[email protected]> wrote: > > > On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote: > > > I was getting very frustrated adding a dive location to an existing > > dive. I > > > was expecting to be able to add a location then select the coordinates > > from > > > the globe and have the coordinates updated and the location name and > > > coordinates associated. Neither happens. The flag is planted without text > > > and the flag disappears when I save. > > > > That's not how it's supposed to work :-( > > It's not supposed to work the way I expected or the way it does?
flag should disappear when you save. > > > So I'm looking for ideas on proper behaviour. There are several > > > circumstances I can think of: > > > > > > 1. User is adding a dive.. Associate the location with the edit location > > > name of the dive. > > > 2. User is editing an existing dive. Associate the location with the edit > > > location name of the dive. > > > > I don't know what you mean by "edit location name of the dive" in both of > > these cases. > > I've looked at the code so I can write a little more concisely about it. > > 1 and 2. When adding or editing a dive dive double clicking on the globe > should add coordinates to the Coordinates field and place a marker on the > globe so the user can see that he selected appropriate coordinates *before > saving*. Neither happens, right now the action has no effect on the dive. Bug. Needs to be fixed. Sadly, this used to work :-( > I've been able to make changes so the ui.coordinates field is updated but > placing flags on the globe is more challenging. Since the edited location > name and coordinates only exist in the ui.location and ui.coordinates > variables the globe::repopulateLabels() function can't place a flag on the > globe, repopulateLabels() uses the dive list for coordinates and labels. > Adding code so it also checks isEditing() and places a flag based on the > edited fields would add that functionality. It should use the data from displayed_dive in addition to the dive list. Then all you need to do is make sure things are tracked correctly in displayed_dive (and they should, if not, that's yet another bug). /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
