Community
Participate
Working Groups
Build Identifier: M20100909-0800 I have a dual monitor set up. See the attached screenshot where the pop up error message is longer than the length of the screen. The message gets cut off. Reproducible: Always
Created attachment 189624 [details] pop u perror
Forms component is owned by UA
(In reply to comment #2) > Forms component is owned by UA To me this looks like the cue form the combo which comes from UI. Did you verify that this is special Forms code?
(In reply to comment #3) > (In reply to comment #2) > > Forms component is owned by UA > To me this looks like the cue form the combo which comes from UI. Did you > verify that this is special Forms code? No, but from the screenshot, it looks like the Form's MessageManager.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Forms component is owned by UA > > To me this looks like the cue form the combo which comes from UI. Did you > > verify that this is special Forms code? > > No, but from the screenshot, it looks like the Form's MessageManager. OK, I must admit I haven't looked at that code for a long time but IIRC that class uses JFace org.eclipse.jface.fieldassist.ControlDecoration. Anyway, let's see what the Forms people say.
The control is inside a form but I don't think this is a forms bug - the form is just acting as a container and the popup is not bound by the size of the form.
I think you guys are probably right. I'll take another look at our code, and I suspect the bug is in our code
(In reply to comment #7) > I think you guys are probably right. Yes, as already indicated in comment 3 this is a bug in JFace (and not in your code). Steps to reproduce: 1. Start a workspace. 2. Open a text file. 3. Ctrl+F. 4. Move the dialog to the right of the screen. 5. Check 'Regular expressions'. 6. Put focus into 'Find' or 'Replace with' field. 7. Hover over the light bulb. ==> The hover is cut off at the right border of the screen.
Sorry for tagging the wrong component. Correcting it
*** Bug 305538 has been marked as a duplicate of this bug. ***
WIND00290151 Ciao All :) Can we get a statement from the JFace or Platform-UI team about this, how likely is a fix, how complicated would it be, is this an easy change we could opt to put into 3.7.1 even? Thanks a lot! :) Helmut
(In reply to comment #11) > Can we get a statement from the JFace or Platform-UI team about this, how > likely is a fix, how complicated would it be, is this an easy change we could > opt to put into 3.7.1 even? Presumably we'd have to change ControlDecoration's inner Hover class's getPolygon(*) and setText(*) method so that it would return the correct location and bounds for the tooltip. The code itself is probably not complicated but the testing might not be as straightforward (considering setups with multiple monitors and such). Since this seems to have been broken since day one we would have to be convinced that it is worth putting into SR1 or SR2.
Thanks Remy :) (In reply to comment #12) > The code itself is probably not complicated but the testing might not be as > straightforward (considering setups with multiple monitors and such). Helmut: I can help a bit by testing the fix using the issue we have found on our end > Since this seems to have been broken since day one we would have to be > convinced that it is worth putting into SR1 or SR2. Helmut: I would vote for a SR? fix only if the benefit outweighs the cost, so if the risk is really small and the fix is carefree I would like to get this in, but if you guys see any risk 3.8 might be the better target..
See also bug 352697 which indicates issues in RTL mode.
(In reply to comment #14) > See also bug 352697 which indicates issues in RTL mode. Remy,Dani, is this bugzilla on track for a 3.8 fix? TIA, Ciao, hh
(In reply to comment #16) > (In reply to comment #14) > > See also bug 352697 which indicates issues in RTL mode. > > Remy,Dani, > is this bugzilla on track for a 3.8 fix? > TIA, > Ciao, hh I don't think someone will work on this for 3.8. As Remy pointed out, we'd need not only shift the hover but also compute the polygon (with the arrow) in a different way and make it work for all the possible positions at which a decorator can be placed.
(In reply to comment #17) > I don't think someone will work on this for 3.8. As Remy pointed out, we'd need > not only shift the hover but also compute the polygon (with the arrow) in a > different way and make it work for all the possible positions at which a > decorator can be placed. Thanks Dani! :) How about e4, is this something that might be addressed there? TIA, Ciao, hh
(In reply to comment #18) > (In reply to comment #17) > > I don't think someone will work on this for 3.8. As Remy pointed out, we'd need > > not only shift the hover but also compute the polygon (with the arrow) in a > > different way and make it work for all the possible positions at which a > > decorator can be placed. > > Thanks Dani! :) > How about e4, is this something that might be addressed there? > TIA, > Ciao, hh It's not 3.x vs. 4.x. It's about finding someone who has time to work on this minor bug.
(In reply to comment #19) > It's not 3.x vs. 4.x. It's about finding someone who has time to work on this > minor bug. Thanks Dani, I understand! :) Helmut
(In reply to comment #20) > (In reply to comment #19) > > It's not 3.x vs. 4.x. It's about finding someone who has time to work on this > > minor bug. > > Thanks Dani, I understand! :) > Helmut Of course if someone contributes a patch we'll find time to look at it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
