Community
Participate
Working Groups
If you edit a protocol message from the properties view of a protocol message, by selecting the protocol message in any of the three tables, and then press the pen button above the table to edit the selected protocol message, then the edit dialog presents a parameter table which is incorrectly sized. Only the name column shown, and a horizontal scrollbar is shown which is need to be used to show the type column. But the width only makes it posible to show one column at a time. I guess this is partly related to general issue of the resize handling of the parameter table, which is also a major issue in the properties view. Steps to reproduce: 1) Create a UML-RT model 2) Create a protocol in this model 3) Create a protocol message for this protocol 4) Create a parameter for this protocol message 5) Select the protocol and open the properties view 6) Select the created protocol message and press the pen button above the list 7) Observer how the table in the edit dialog that pops up only shows the name column, the type column is not visible, and a horizontal scrollbar is displayed which you need to scroll to make the type column to be shown Observe also how resizing the edit window does not resize the table which seem to have a fixed size.
This needs to be addressed. However, we need to decide the severity of this user experience issue and where this type of UI enhancement belongs. Moving to New
Keep in mind the related Bug 495352. I have a feeling that they are very related, i.e. there is some general resize issue with the table, which is visible both in the protocol message edit dialog, as well as in the properties view itself. I guess fixing one will (hopefully) fix (parts of) the other...
New Gerrit change created: https://git.eclipse.org/r/82277
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/82277 The current patch-set for this Gerrit change causes a major regression related to the same table in the properties view, i.e. basically what Bug 495352 is about. I suggest that both Bugzillas are handled at the same time.
Gerrit change https://git.eclipse.org/r/82277 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=52a8d33285f25159bd788f76697d58bbc7ab8cde
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/82277 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=52a8d33285f25159bd788f76697d58bbc7ab8cde There is something really strange going in here. I just tested this merged fix. When I tried an earlier version of this fix, I made a comment that it caused a regression in the properties view, where it caused only the name column to be displayed, see https://git.eclipse.org/r/#/c/82277/ and my comment on patch-set 1. When I now test this final merged fix using the tester setup, I can see the same regression, i.e. the name column slowly fills up the complete table hiding the type column. But, here is the strange thing, it seem to happen randomly. First I thought that it only happens the first time in a new workspace (similar to he issue discussed in Bug 503083). When reselectng the protocol message a second time, then the table works okay. But trying once again in a new workspace, then I manage to get it consistently, where the name colument gradually started to fill the complete table. This randomness could explain why I did not see this behavior when testing patch-set 2.
(In reply to Peter Cigehn from comment #6) > (In reply to Eclipse Genie from comment #5) > > Gerrit change https://git.eclipse.org/r/82277 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > > ?id=52a8d33285f25159bd788f76697d58bbc7ab8cde > > There is something really strange going in here. I just tested this merged > fix. When I tried an earlier version of this fix, I made a comment that it > caused a regression in the properties view, where it caused only the name > column to be displayed, see https://git.eclipse.org/r/#/c/82277/ and my > comment on patch-set 1. > > When I now test this final merged fix using the tester setup, I can see the > same regression, i.e. the name column slowly fills up the complete table > hiding the type column. > > But, here is the strange thing, it seem to happen randomly. First I thought > that it only happens the first time in a new workspace (similar to he issue > discussed in Bug 503083). When reselectng the protocol message a second > time, then the table works okay. > > But trying once again in a new workspace, then I manage to get it > consistently, where the name colument gradually started to fill the complete > table. > > This randomness could explain why I did not see this behavior when testing > patch-set 2. I've tested this a bit more, and now I at least can get this repeatable. The strange behavior where the name column gradually gets expanded to fill the complete table (and this hiding the type column), only happens if you have a vertical scroll bar in the properties view. If you resize your workbench or view pane where the properties view is shown to ensure that no vertical scrollbar is shown, then this strange resizing happens. This also explains the "random" behavior I saw from before, when trying in different new workspaces were the layout of the perspecitive and view panes differed. I will provide some screen shots that shows the difference.
Created attachment 264575 [details] Screen shot showing the single column case This screen shot shows how the table has gradually been filled with one single name column. Observe the vertical scroll bar for the properties view itself.
Created attachment 264576 [details] Screen shot showing the correct situation with two columns This screen shot shows the expected result, i.e. two columns, name and type. This only happens if you ensure that the properties view have not vertical scrollbar.
(In reply to Peter Cigehn from comment #9) > Created attachment 264576 [details] > Screen shot showing the correct situation with two columns > > This screen shot shows the expected result, i.e. two columns, name and type. > This only happens if you ensure that the properties view have not vertical > scrollbar. Does it reset to the correct table when different protocol message is selected?
(In reply to Young-Soo Roh from comment #10) > Does it reset to the correct table when different protocol message is > selected? If I select a second protocol message, then the same thing happens the first time for the second protocol message as well. If I then select the first protocol message again, then the table is reset to a correct table. If I then select the second protocol message again, then the table is also reset to a correct able for the second protocol message. And when you have gotten a correct table, then it stays correct. The problem only seem to appear for the first protocol message in a new workspace. If I remove the meta-data as dicussed in Bug 503083 Comment 3, then I can get it to repeat again in an existing workspace. So this issue seem to (partly) be related to similar aspects as in Bug 503083 related to that it only happens the first time in a new workspace.
New Gerrit change created: https://git.eclipse.org/r/82627
Gerrit change https://git.eclipse.org/r/82627 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=65d610741ac6b0624216f4293d55379ac86127ea
Verified to be fixed in the latest Papyrus-RT build. The table in the edit window now shows both the name and the type column, without having to use the scrollbar. There is still a horizontal scrollbar shown, both in the properties view and in the edit dialog. And the table does not resize when the properties view or the edit dialog is resized. But since this is depending on needed changes in base Papyrus, the current behavior is "good enough" for 0.8. The remaining issues identified (including workarounds for them) are tracked by Bug 495352, Bug 504743, Bug 504710 which all depends on Bugzillas in base Papyrus. This one however, is put into verified fixed.
Closing as verified fixed.
Closed again because of collision...
