Community
Participate
Working Groups
Created attachment 258804 [details] Opaque behavior editor dialog with large amount of code The Opaque behavior editor dialog does not provide scroll bars when the amount of code gets too large, as shown in the attached screen shot. Note that neither the C++ editor box nor the dialog itself provide ways of scrolling, so both parts of the code and parts of the dialog are no longer accessible by the user.
Some more testing shows that the behavior is inconsistent... When a large amount of code is entered for the first time, there are scroll bars provided for the code editing area and there is no need for scroll bars for the dialog itself. However, upon closing and re-opening, the code editing area is maximized, forcing the bottom part of the dialog to become obscured and unreachable. If you then resize the dialog to shrink is vertical size, the size of the code editing box is not resized and scrolling bars are not added, making parts of the code unreachable for editing (except by cursor, but there is no way to figure out where the cursor went as the display does not follow). Even if you do not resize the dialog, as per the previous paragraph, if the code is longer than what the dialog supports, i.e., all the bottom dialog controls are no longer visible, some code becomes unreachable as scroll bars are not provided for the code editing area. As per above, it is still possible to use the cursor to get into the portion of the code that is not visible, but there is no way of knowing where you are...
Isn't this one "superseded" by Bug 494288? Personally I would prefer if we spent more time getting that one in place instead of improving the current, rather cumbersome, OpaqueBehavior editor. If improvements are going to be made this this editor, I guess that is probably something that really should be made in base Papyrus, and not specifically in Papyrus-RT (which would focus in getting the code snippet view in place instead).
(In reply to Peter Cigehn from comment #2) > Isn't this one "superseded" by Bug 494288? Personally I would prefer if we > spent more time getting that one in place instead of improving the current, > rather cumbersome, OpaqueBehavior editor. If improvements are going to be > made this this editor, I guess that is probably something that really should > be made in base Papyrus, and not specifically in Papyrus-RT (which would > focus in getting the code snippet view in place instead). It does appear like it could be superseded by Bug 494288, and I do agree that Bug 494288 would be a usability improvement - but we also need to ensure that the same behavior is not present in the solution presented in Bug 494288 for the field(s) where code is edited (which I did not see).
(In reply to Charles Rivet from comment #3) > It does appear like it could be superseded by Bug 494288, and I do agree > that Bug 494288 would be a usability improvement - but we also need to > ensure that the same behavior is not present in the solution presented in > Bug 494288 for the field(s) where code is edited (which I did not see). I added Bug 49428 Comment 1 to make it more clear that scroll bars must be used to allow large amount of code to be added in the code snippet view.
I can reproduce tje following behavior with a current oxygen build (neon behaves identically) on a Linux machine: - Initially, the window for entering the code is quite small, ~7 lines, but the text area with the code has a scrollbar. - If you click on an existing behavior descriptions with more code, the text area is adapted to this size. There is 2nd scrollbar for the whole property view. This is not consistent and not very ergonomic, since you need to scroll down to see the additional attributes of an opaque behavior below the code. While the property view is not very adapted for large chunks of code anyway, it would be more consistent, if the height of the the code area does not depend on the initial contents of the behaviour. It should always have the same height sufficient for a "reasonable" amount of code (e.g. 15 lines).
Keep in mind that this bug originally was written specifically for Papyrus-RT (and it is still assigned to the Papyrus-RT project). If this issue needs to be fixed in base Papyrus, I suggest creating a separate bug for the Papyrus project (which this Papyrus-RT bug can depend on). Also for the record: This bug is probably not that relevant for the Papyrus-RT project itself anymore, since the new code snippet view (that only exist specifically for Papyrus-RT) more or less completely replaces the need for the generic opaque behavior editor in base Papyrus. But it would of course be good to get this issue fixed in base Papyrus anyway, and thus a separate bug for base Papyrus is probably the best to handle this.
(In reply to Peter Cigehn from comment #6) > Keep in mind that this bug originally was written specifically for > Papyrus-RT (and it is still assigned to the Papyrus-RT project). If this > issue needs to be fixed in base Papyrus, I suggest creating a separate bug > for the Papyrus project (which this Papyrus-RT bug can depend on). > > Also for the record: This bug is probably not that relevant for the > Papyrus-RT project itself anymore, since the new code snippet view (that > only exist specifically for Papyrus-RT) more or less completely replaces the > need for the generic opaque behavior editor in base Papyrus. But it would of > course be good to get this issue fixed in base Papyrus anyway, and thus a > separate bug for base Papyrus is probably the best to handle this. I agree with Peter. The original intent of this bug is addressed by the Papyrus-RT code snippet view. As such, if this is considered an issue for Papyrus, a separate bug should be created to address it. This way, we could close this (Papyrus-RT) one and rely on the Papyrus solution for the generic opaque behavior solution.
