Project

General

Profile

Bug #9743

UI_ScaleEdit: marking window as dirty creates an inconsistent state

Added by pellinor almost 8 years ago. Updated over 7 years ago.

Status:
Updated
Severity:
Very Low
Assignee:
-
Category:
Plugins/Add-Ons
Target version:
-
Start date:
05/21/2016
% Done:

10%

Version:
Platform:
Windows
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

When configured with two or more intervals, the highest interval does not like the part window marked as dirty.

To reproduce this, I added the following code to a partModule:

[KSPField(isPersistant = false, guiActiveEditor = true, guiName = "testField", guiFormat = "0.000", guiUnits = "")]
[UI_ScaleEdit(scene = UI_Scene.Editor)]
public float testField = 1;

public override void OnStart(StartState state)
{
    // ...

    var range = (UI_ScaleEdit)Fields["testField"].uiControlEditor;
    float[] a = { 1f, 2f, 3f };
    float[] b = { 0.01f, 0.01f };
    range.intervals = a;
    range.incrementSlide = b;
    range.sigFigs = 3;
}

[KSPEvent(guiActive = true, guiActiveEditor = true, guiName = "Debug")]
public void debugOutput()
{
    Debug.Log("testField1 =" +testField.ToString());
}
[KSPEvent(guiActive = true, guiActiveEditor = true, guiName = "UpdateWindow")]
public void updateWindow()
{
    Debug.Log("updateWindow");
    foreach (var win in FindObjectsOfType<UIPartActionWindow>().Where(win => win.part == part))
    {
        win.displayDirty = true;
    }
}
Reproduction:
  • go to the editor
  • take a part with your module
  • open debug log
  • tweak testField to 2.5, press 'Debug'
    => log says "testField=2.5", slider says "2.5" (ok)
  • press "updateWindow"
    => slider jumps to 100% and says "2.0" (not ok, should stay at 50% and "2.5")
    It looks like the tweakable decides to display the wrong interval.
  • press "debug"
    => log says "testField=2.5" (ok, but shows that the UI is not consistent with the internal value)

If the window ends up marked as dirty after every button press, then this behaviour makes the highest interval pretty much unusable.

Workaround: add a dummy interval.

History

#1 Updated by TriggerAu over 7 years ago

  • Status changed from New to Needs Clarification

#2 Updated by pellinor over 7 years ago

  • Status changed from Needs Clarification to Updated
  • % Done changed from 0 to 10

Still present in 1.1.3

#3 Updated by pellinor over 7 years ago

Still present in 1.2.0.1523

Also available in: Atom PDF