Print at Dec 21, 2025, 8:59:05 PM

Posted by jmbraben at Dec 26, 2020, 1:17:29 AM
Re: Can someone please explain plan view "other level' wall visibility?
I have a further understanding of the code behavior related to the plan view, but still learning.

The code/rules are obtuse and inconsistent (IMO).

  • paintOtherLevels: paints the "reference" (shaded/hidden walls)
  • - If at "level0" (the magic "first level created"..."level0" does NOT have to be lowest elevation), ignore any other levels at the same eleveation, show (as reference) any levels that are at the "next HIGHER elevation" (any levels at equal elevation), ignore any levels "above" this. Note that if you insert a level with an elevation between "Level 0" and your (until now seen as reference) levels...they will disappear and only the new level visible.
  • - If NOT at "level 0", only show as reference the "next LOWER elevation" levels. Your lowest elevation level (if not "level 0") won't show guides. Therefore the order of adding levels impacts behavior.

  • getDrawableWallsInSelectedLevel: paints the "editable walls" (walls on current layer and those walls from other layers that intersect that layer (...not really))
  • - If a layer is determined to be "editable" by these rules it overrides "reference" drawing (or at least it is dominant from plan view behavior)...If a wall would have been drawn as "reference" and "editable", it will be shown as "editable"
  • - If a wall intersects (wall elevation < current layer elevation < wall elevation + wall height) the selected wall is "editable"
    ...UNLESS the walls elevation is EQUAL to the current layer elevation...in which case the layer attribute "elevationIndex" is checked and only walls on layers with LOWER "elevationIndex" are presented. I currently don't yet understand all the use cases for "elevationIndex", so it is unclear to me if serves any useful purpose.


The above is a simplified explanation of a hierarchy of method calls related to the plan drawing, and some of the lower level class methods may have correct behavior for other hierarchies calls (.ie I really don't want to hack at the low level methods without understanding how they are being used in other cases)

I can only imagine that this behavior is somehow an artifact of when "level" support was added, but the current code violates UI first principles (at least as I have been taught and how I have implemented them in my 30+ year career).

Personally I have no see no value in being able to edit walls on layers not selected...but I really do need to be able to reference/align to them in many cases.

For my first pass at this, I'm just going to add a layer attribute that allows view as reference to replace "paintOtherLevels" logic, and I'm going to modify "getDrawableXXXInSelectedLevel" to only present the stuff in that layer and see how that works for me (If I decide I want other layers editable, I'll do it via layer attribute).