Bug #481

Editing alarms on "new model" seems to break something

Added by Espen Solbu about 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:06/13/2012
Priority:HighDue date:
Assignee:-% Done:

100%

Category:-Spent time:-
Target version:2.0 Multiple models

Description

2.0 Beta 5
Scenario:
  1. Install application
  2. Connect, update currentmodel if mismatch
  3. Make new model, change name, click FrSky alarms
  4. modify alarms, and save

This will modify the new model's alarms as well as the CurrentModel's alarms

This ONLY applies when editing alarms on a "brand new" model. Probably because it uses currentModel if modelId == -1

Solutions:
  • we should get a model id before allowing the alarm edits.
  • Prevent enabling of that button until model has a id (poor solution)

Associated revisions

History

#1 Updated by Espen Solbu about 5 years ago

The Alarm Edit actually gets the correct id, even of new models. so there must be something wrong with
  • _model.setFrSkyAlarms(_alarmMap);
    or
  • FrSkyServer.saveModel(_model);

Or possibly, are we somehow constantly recording incoming alarms and applying them?

#2 Updated by Espen Solbu about 5 years ago

In onServiceConnected, we use the currentmodels alarmmap if we didn't have any alarms when we arrived here.
I think this is what is causing updates to alarm map to also modify current model

Needs to be changed to copy the alarms, reinitialize for this model, or prevent this state entirely (add alarms to model on creation)

#3 Updated by Espen Solbu about 5 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Applied in changeset r449.

Also available in: Atom PDF