Bug 107362 - [Widgets] Find dialog not always showing selection
Summary: [Widgets] Find dialog not always showing selection
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: Macintosh All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact: Felipe Heidrich CLA
URL:
Whiteboard: stalebug
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-08-18 15:26 EDT by Matthew Conway CLA
Modified: 2020-05-25 17:26 EDT (History)
6 users (show)

See Also:


Attachments
file with long lines (11.18 KB, text/plain)
2005-08-18 15:28 EDT, Matthew Conway CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Conway CLA 2005-08-18 15:26:03 EDT
When using the Find dialog to search and replace in a text file, if the text
file has very long lines, at some point clicking next in the dialog takes you to
the next selection, but it is not visible within the editor.

I'm attaching a file in which this behavior happens - open the file, Apple-F,
type in tr-NEXUS in the search field, then the 30th click of Find doesn't show
the selection.

This is on eclipse 3.1 using Java 1.4.2_09 on OSX 10.4.2
Comment 1 Matthew Conway CLA 2005-08-18 15:28:32 EDT
Created attachment 26259 [details]
file with long lines
Comment 2 Dani Megert CLA 2005-08-19 05:34:32 EDT
Works for me using R3.1 on WindowsXP. Which build id?
André, can you reproduce on Mac?

Moving to SWT.
Comment 3 Grant Gayed CLA 2007-09-10 16:37:57 EDT
In mac we can't handle long strings (in my machine anything over 4500 characters stop working).
TextLayout and GC#drawString are broken the same way.

public class PR107362 {
public static void main(String[] args) {
	final Display display = new Display();
	final Shell shell = new Shell(display);
	final Font font = display.getSystemFont();
	final StringBuffer buffer = new StringBuffer();
	for (int i = 0; i < 1000; i++) {
		buffer.append("Word ");
	}
	buffer.append("Last");
	System.out.println("Buffer length: " + buffer.length());
	
	shell.addListener(SWT.Paint, new Listener() {
		public void handleEvent(Event event) {
			TextLayout layout = new TextLayout(event.display);
			layout.setOrientation(shell.getStyle() & (SWT.RIGHT_TO_LEFT | SWT.LEFT_TO_RIGHT));
			layout.setText(buffer.toString());
			layout.setFont(font);
			Rectangle ca = shell.getClientArea();
			Rectangle textBounds = layout.getBounds();
			layout.draw(event.gc, ca.width - textBounds.width - 10, 10);
			layout.dispose();
			event.gc.setFont(font);
			event.gc.drawString(buffer.toString(), ca.width - textBounds.width - 10, 80);
		}
	});
	shell.setSize(280, 240);
	shell.open();
	while (!shell.isDisposed()) {
		if (!display.readAndDispatch()) display.sleep();
	}
	display.dispose ();
}
}
Comment 4 Grant Gayed CLA 2007-09-10 16:39:39 EDT
SSQ: don't you have a duplicate for this ?
Comment 5 Andre Weinand CLA 2007-09-10 16:47:28 EDT
Scott, is this a known problem on Mac?
Comment 6 Silenio Quarti CLA 2007-09-11 11:23:31 EDT
This is the first time I have seem this problem.
Comment 7 Scott Kovatch CLA 2007-09-11 14:12:01 EDT
Grant, is 4500 characters a hard-and-fast limit or does it seem to be stopping at roughly that amount? It could be that 4500 characters times the width of a character overflows an Int32, and that's confusing CoreGraphics in some way. I will file a bug linking back to this one.
Comment 8 Felipe Heidrich CLA 2007-09-11 14:39:25 EDT
Hey Scott, I reported comments 3 and 4. (Grant was logged in bugzilla on my machine, I didn't notice that till I saw the notification).

I think the limit is in the width not in the number of chars. The textbounds in example is 32767 (which is 0x7FFF).
I talked to SSQ and he said the type Fixed has 16 bits for the whole number and 16 bits for the decimal part. 16 bits minus one bit for signal gives 15 bits (0x7FFF).

Scott, do you agree the above ? Can this be fixed ?
Comment 9 Scott Kovatch CLA 2007-09-11 17:26:43 EDT
Ah, the dreaded Fixed type. If it overflows on addition, the value of the result will be clamped to 32767.0. TextLayout.computeRuns() is the likely culprit here -- ATSUGetGlyphBounds is probably returning 32767.0 for the longest string, and then the Fix2Long converts to the integer value 32767.

Do text editors in eclipse support wrapping lines after some fixed character width? I didn't see an option for it in the preferences. I know that TextMate and BBEdit can do this.

I don't think this is fixable by the SWT, because even if you could internally overcome the limitations of the Fixed type, ATSUI won't be able to draw a string that wide. You'd have to look into introducing your own soft breaks and forcing a wrap.
Comment 10 Dani Megert CLA 2007-09-12 03:08:31 EDT
>Do text editors in eclipse support wrapping lines after some fixed character
Not out of the box, but people can build their own editor and set the SWT.WRAP flag on StyledText.
Comment 11 Felipe Heidrich CLA 2009-08-19 12:27:07 EDT
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
Comment 12 Eric Williams CLA 2017-06-30 12:32:45 EDT
Bug triaged, visit https://wiki.eclipse.org/SWT/Devel/Triage for more
inforamation.
Comment 13 Eclipse Genie CLA 2020-05-25 17:26:41 EDT
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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.