Bugzilla – Full Text Bug Listing
| Summary: | [Field Assist] assist not opened at caret location | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | markus.kell.r |
| Version: | 3.2 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 120237 | ||
|
Description
Dani Megert
I guess this would need new API in IControlContentAdapter to get the right location, similar to IContentAssistSubjectControl's getLocationAtOffset(..) and getLineHeight(). This could probably be simplified to one query that returns a location just below the caret. It should probably be general enough to also work for multi-line texts and differing fonts. Fixed >20060206. If the proposalAcceptanceStyle is PROPOSAL_INSERT, then the content proposal popup will open at the caret location. If it is PROPOSAL_REPLACE or PROPOSAL_IGNORE, it will popup relative to the widget (as implemented now). I added a method to IControlContentAdapter to return a horizontal pixel offset of the cursor, but I did not take vertical location into account, since field assist always uses the control boundary itself. I don't see worrying about multi line cases since field assist is really for simple fields, and not complex multi-line/multi font documents. I think platform text content assist will continue to be used for those kinds of controls. >I think platform text content assist will continue to be used for those kinds of
>controls.
Actually no. I thought we agreed on deprecating "org.eclipse.jface.contentassist". This means Platform Text will only support ITextViewer. It think it is too much of overhead for clients to use a text viewer just to get content assist in a multi-line Text widget.If we don't deprecate then I most clients will just stay on the Platform Text implementation.
BTW: As far as I can see your API does not mention such a limitation.
My assumption was that most clients use a text viewer for that style of content assist. Perhaps it was a bad one. I am getting caught up in the original problem description which was "content assist for text fields." I take fields to mean "simple one-liners" but that may be too limiting. I will look at extending the API to provide the caret offset in the y direction. The issue here is that I didn't want the API to assume the bottom or top of the caret, since the placement of the content assist popup will change. Will revisit this. Fixed >20060207. The IControlContentAdapter API is now public Rectangle getInsertionBounds(Control control); which allows for multi-line text. Note: I verified that this API could be provided for a future StyledTextContentAdapter, but we don't offer this since the platform text content assist doesn't either. Let me know if this was ever requested by your clients as it is not difficult to provide. verified in 20060214-0800 on Win XP using the field assist example. Content assist opens at caret location when adapter is configured for insertion. |