Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: 1. Press F1 for the dynamic help view to appear 2. Click "Search" at the bottom 3. Click link "Default" near "Search scope" 4. Press "New" button 5. Enter a long string for the scope set name; Click OK 6. Select the new scope set just entered; Click OK 7. Notice the string "Search Scope" wraps such that it is unreadable in some cases More information:
Created attachment 57288 [details] screenshot of described bug
This bug is still present in 3.3RC4.
Assigning to Adam.
Created attachment 73381 [details] patch This turned out to be a forms specific problem, rather than help. The search part is using the section's text client in a very unusual way. In most cases, this is used for an icon or something similarly small and inconsequential. Thus, the layout algorithm gives the text client all the space it needs and gives whatever is leftover to the title. This patch changes the ExpandableComposite's layout to check if the text client is wrappable. If it is, it will attempt to divide the space evenly between the title and the client. Otherwise, it functions as it did before. In order to make this work properly, some heavy changes were required to the FormUtil.computeWrapSize() method (which was made public for visibility in ExpandableComposite). It was not handling several different cases correctly. For one, it was unable to correctly determine the size when one word required more space than the width hint. To allow this case it was necessary to sometimes return a value larger than the width hint. This resulted in an incorrect height being returned since the height was calculated under the assumption that the width hint was the absolute maximum. Correcting this requires a recursive call to the method in the case that the width calculated is greater than the hint. This recursion will only be required once per call to the method and only in specific cases. The performance hit should not be too great and is required to ensure correct functionality of the method.
Chris, can you review this patch for me? Also, Mike has been asked to review it from the perspective of whether it breaks anything in PDE.
Created attachment 73393 [details] patch I left some testing code in the last patch.
I did some testing and saw a layout regression. I'll post more details in a follow up comment.
Created attachment 73575 [details] patch The regression Chris is talking about is actually an existing inconsistency between ExpandableComposite.computeSize() and ExpandableComposite.layout() that this fix exposed. This new patch corrects the inconsistency as well. Basically computeSize was not adding the IGAP pixels required between the toggle control and the title label. Thus, it was reporting that the required width was 4 pixels smaller than the actual required width.
+1 for the latest patch. Will commit once Mike has given his approval also.
Comment on attachment 73575 [details] patch Tested well within PDE. Tested using the Plug-in Manifest editor and Simple Cheat Sheet Editor form pages and sections.
Patch committed to HEAD.
Hi, we are still seeing this issue on RedHat5. (Sled10, xp, vista all work fine) This is being flagged as "Section 508 blocking" by our accessibility team, so could this be looked into further?
Correction, our accessibility team did not find it to be 508 blocking since the issue only occurs on linux and mac. Setting priority to Normal.
We need to change the target milestone which is currently set to 3.4M1.
This is working fine on both Windows and Linux using I20080617-2000. Closing as WORKSFORME.
