You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see two routes to resolve this out of bounds issue.
When a user enters a value that would cause this, we edit the value for the opposing property. For example, starting from a valid scenario in a 10 m wide room:
xposition = 3
panel width = 6.
There's 1 m left over. If the user increases the panel width to 9, we'd move the window over to accommodate it (change xposition to 1). This could be a bit jarring as you'd click on one input and a different input value would change automagically....
The alternative is to define it differently, using:
xcenter (denotes the center of the panel in the surface in the x direction)
xpct (denotes the percentage of the widest possible panel at that location, given the room width constraint). Maybe a little less intuitive up front (?), but you'd never encounter a case where you'd change one input and another would also change.
I guess option 2 might be better, because none of the inputs would change based on other inputs. Any thoughts before I go one route or the other?
Resize the panel to fit on the surface even when a user enters a panel dimension/position such that the panel would be out of bounds.
Note: the GUI will still display the 'incorrect' (too large) dimension for that panel.
Other minor changes:
added var for minimum border size around panel (0.1 m)
limited maximum user inputs for any panel dimension to surface dimension minus 2*min border size
limited maximum user input for panel position to 2* border size (minimum panel dimension in any case is now the min border size)
I'm guessing you already know about this, but it's possible to specify a panel that extends beyond the wall, causing this:
@thoyt
The text was updated successfully, but these errors were encountered: