Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 164748 - [FieldAssist] Content assist popup in Find Replace dialog for regexp covers regexp text
Summary: [FieldAssist] Content assist popup in Find Replace dialog for regexp covers r...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2.1   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P5 minor (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 204599
Blocks:
  Show dependency tree
 
Reported: 2006-11-15 21:43 EST by Tim Engler CLA
Modified: 2007-10-30 16:58 EDT (History)
5 users (show)

See Also:

Attachments
Screen shot of quick fix window covering half of find box (42.22 KB, image/gif)
2006-11-17 11:59 EST, Tim Engler CLA 		no flags Details
content assist in find/replace dialog (49.54 KB, image/png)
2007-07-03 04:24 EDT, Andre Weinand CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Engler CLA 2006-11-15 21:43:41 EST 
It is difficult to see what you are typing in the "Find:" text box when entering a regexp, since when the quick fix window comes up, it covers the bottom half of this dialog.
Comment 1 Dani Megert CLA 2006-11-17 08:15:21 EST 
The find field is visible.
There are no plans to change this.
Comment 2 Tim Engler CLA 2006-11-17 11:59:15 EST 
Created attachment 54081 [details]
Screen shot of quick fix window covering half of find box
Comment 3 Tim Engler CLA 2006-11-17 12:00:32 EST 
On a PC, yes, it doesn't cover the find text box. However, on OS X, it covers the bottom half of the text box. See the attached screen shot.
Comment 4 Dani Megert CLA 2006-11-18 01:49:12 EST 
That's not as it should be. We are using field assist from Platform UI.

Which means back again in Tod's land - mea culpa ;-)
Comment 5 Susan McCourt CLA 2006-11-20 11:33:50 EST 
Tim, which OS X?  I haven't seen this before on my Mac...
Comment 6 Tim Engler CLA 2006-11-21 12:29:07 EST 
Mac OS X 10.4.8 (8l2127), Darwin 8.8.1 on a Mac Mini Core Duo 1.66 Ghz with 2 GB of memory.

I'm running eclipse version 3.2.1 build id M20060921-0945
Comment 7 Susan McCourt CLA 2007-02-13 12:32:46 EST 
Are you running any Eclipse 3.3 builds and if so, do you see the problem there?
Comment 8 Dani Megert CLA 2007-07-03 03:01:22 EDT 
André, have you seen this on your Mac?
Comment 9 Andre Weinand CLA 2007-07-03 04:24:06 EDT 
Created attachment 72933 [details]
content assist in find/replace dialog

Yes, I'm seeing this too. See attached screenshot of Eclipse 3.3.
Comment 10 Susan McCourt CLA 2007-07-03 13:15:33 EDT 
marking 3.4 (likely will be looked at M2 but there is no milestone yet for that...)
Comment 11 Eclipse Webmaster CLA 2007-07-29 09:21:08 EDT 
Changing OS from Mac OS to Mac OS X as per bug 185991
Comment 12 Markus Keller CLA 2007-08-10 06:46:16 EDT 
The implementation of ComboContentAdapter.getInsertionBounds(Control) should use Combo#getCaretLocation() (requested in bug 44072) and Combo#getTextHeight().
Comment 13 Susan McCourt CLA 2007-09-06 12:09:10 EDT 
investigate/fix for M3.
Comment 14 Susan McCourt CLA 2007-09-25 15:08:23 EDT 
Fixed in HEAD.
The problem reported was with the y placement of the popup, and I could fix this by not using the problematic implementation of getInsertionBounds, which depends on some bogus getClientArea results on the Mac.

The long term solution of adopting SWT API requested in bug #44072 is now tracked in bug #204599.
Comment 15 Susan McCourt CLA 2007-09-27 13:36:04 EDT 
Reopening as this solution does not play well with multi line text.
Should push a platform workaround down into the content adapters.
Comment 16 Susan McCourt CLA 2007-09-27 15:27:12 EDT 
Fixed (again) in HEAD >20070927.
The placement is now correct with multi-line text.
The ComboContentAdapter will compute the text bounds differently on the Mac.  The correct solution is still to use SWT API when it becomes available (as tracked in bug #204599).

Note that the position of the proposal popup is still too far to the left on single line edit fields on the Mac.  This is a problem with the caretLocation API, and has always been true (at least as observed on my ancient Mac running 10.3.9).
Comment 17 Susan McCourt CLA 2007-10-30 16:58:03 EDT 
verified on Mac, I20071030-0010