Community
Participate
Working Groups
Build Identifier: 4.1M7 Hi, I don't know if ths is e4 related, but at least I hope to get some tips where to search for. I have a compatibility view part with a tableviewer. I found that when I schedule a Job _or_ open a message dialog the table somehow scrolls to the top. I put breakpoints in Table.showItem, and other points that looked like repositioning and found that the rendering engine does some stuff when setting the font but sets it back to the original position. I don't have any further idea where to put breakpoints to find out why this happens. I stepped through readanddispatch of a messagedialog and it didn't happen. if i make it run again - booms it scrolls to the top. Any ideas ? You can see my ViewPart at http://mango.googlecode.com/svn/trunk/de.eiswind.mango.client.search/src/de/eiswind/mango/client/search/ui/SearchView.java Any help or hint will be appreciated! Reproducible: Always
Hi Thomas, thank you for your bug report. I am able to reproduce the problem with a pure SWT snippet actually. I do not see the problem you describe when regularly using the SDK though. If you open the 'Package Explorer', scroll to the bottom, open the search dialog with Ctrl+H and close it, the view is still okay, right?
(In reply to comment #0) > I put breakpoints in Table.showItem, and other points that > looked like repositioning and found that the rendering engine does some stuff > when setting the font but sets it back to the original position. When we set the font to the table, please attach the call stack to this bug, thanks.
I opened a bug against SWT for the simple case, see bug 370997.
Created attachment 210781 [details] stacktrace from setFont I don't think this is the problem as the topIndex gets restored afterwards and the actual repositioning seems to happen somewhat later (at least from my visual impression) But I'm just guessing. I don't see this in the SDK, but I see it at different situations in my app. To the stacktrace: My codebase is a little outdated, the line numbers are from 4.1M7 build.
(In reply to comment #4) > I don't think this is the problem as the topIndex gets restored afterwards and > the actual repositioning seems to happen somewhat later (at least from my > visual impression) But I'm just guessing. If you comment out the setFont(*) call in CSSPropertyFontSWTHandler, then you don't have any scrolling problems, correct?
Yep thats right.
What does your CSS file look like? Do you have multiple CSS files? Could you attach them here? Perhaps it can be used to try to reproduce your problem since the SDK doesn't seem to exhibit this problem.
Created attachment 210799 [details] css that makes the trouble Slightly modified CSS at my side.
(In reply to comment #8) > Created attachment 210799 [details] > css that makes the trouble I guess your first definition is probably the problem. > CTabItem, Label, Tree, Text, Combo, Table { > font-family: "Arial"; > }
Yep! Thanks so far. I'll fall back to default Table font until this gets fixed. I had some complaints from users with really long table results... But now I can work around at least.
Hi Thomas, I can reproduce the problem. It seems to only affect Tables which is why we don't see it in the 'Package Explorer' (since that is a Tree). I think we can mark this as a duplicate of bug 370997, what do you think?
Ok. As always: Thanks for your support.
(In reply to comment #12) > Ok. As always: Thanks for your support. No problem, Thomas. We could workaround this on the CSS side by checking whether the fonts are equal before we set it but I'll check with the SWT people to see what they think first. I'll leave this bug open in the meantime.
Thomas, I will mark this bug as a duplicate. If you'd like to keep the Arial font, you could change the code of the handler to check the font before setting it. I will talk to the SWT team to try and get bug 370997 fixed. private static void setFont(Widget widget, Font font) { if (widget instanceof CTabItem) { ((CTabItem) widget).setFont(font); } else if (widget instanceof Control) { Control control = (Control) widget; FontData[] setData = font.getFontData(); FontData[] currentData = control.getFont().getFontData(); if (setData.length != currentData.length) { control.setFont(font); return; } for (int i = 0; i < setData.length; i++) { if (!setData[i].equals(currentData[i])) { control.setFont(font); return; } } } } *** This bug has been marked as a duplicate of bug 370997 ***
