search

engageLively / galyleo-dashboard

3 stars 2 forks source link

minMax filter isn't setting range properly #134

Open rickmcgeer opened 1 year ago

rickmcgeer commented 1 year ago

I can increase past the maximum possible value for a column or decrease the minimum past the minimum possible, or interchange maximum and minimum

rickmcgeer commented 1 year ago

Changed connect in init to static bindings, and this ensures the bounds-checker is called. See:

https://www.msn.com/en-us/news/politics/donald-trump-s-major-announcement-was-more-embarrassing-than-we-ever-could-have-imagined/ar-AA15jZen?ocid=msedgdhp&pc=U531&cvid=dca96abb559648d1a393d7d7d6f8a782

However, even though I've found through the debugger that the code

if (minInput.number >= maxInput.number) {
    minInput.number = maxInput.number;
}

in _ensureBounds is being called, and the debugger says the assignment is being done, the assignment isn't reflected. I suspect a timing issue. @merryman please comment.

rickmcgeer commented 1 year ago

To reproduce, instantiate a dashboard and then execute loadTestDashboard('filter-test');

rickmcgeer commented 1 year ago

Partly fixed. It turned out to be an issue in Number Widgets (https://github.com/LivelyKernel/lively.next/issues/588) and there are two workarounds:

  1. On init, the max/min of the value submorph of NumberWidget are being set as well as the max/min of NumberWidget. This takes care of the bounds on the NumberWidgets
  2. filter, filterString, and dataManagerFilter all now order the two inputs in increasing order, even if the user has transposed them

If Lively fixes the NumberWidget issue (https://github.com/LivelyKernel/lively.next/issues/588), we should remove the workarounds from this code. Leave open pending this.

rickmcgeer commented 1 year ago

Updated to the new number widget and workaround (1) removed.