| Hi Jos,
you can bind your custom implementation in your MyDslUiModule:
public Class<? extends ICompletionProposalAcceptor.Delegate> bindICompletionProposalAcceptorDelegate() { return FilteringAcceptorDelegate.class; }
It may be even easier to override AbstractContentProposalProvider.doCreateProposal(String, String, Image, int, int, ContentAssistContext) and return null for any unwanted proposal.
Regards, Sebastian On 29.06.2009, at 14:44, Warmer, Jos wrote: Sebastian, That sounds ok to me, can you point me to the place where I can bind my own descendant of ICompletionProposalAcceptor? to suppress a common set of proposals, you may want to bind a descendent of the class ICompletionProposalAcceptor.Delegate and override the accept method: public void accept(ICompletionProposal proposal) { if (!proposal.getDisplayString().endswith(...)) Hope that helps, On 29.06.2009, at 14:27, Warmer, Jos wrote:
In Xtext/oAW we have used the completion Proposal provider extensively. As we have an optional “description” element in front of each real modelelement we always get a “description” in the proposal list.\ In oAW/Xtext we used the following operation to generically filter out the description proposals. /** Filter out all proiposals that end with Description. * This eliminates the descritions from all proposals. * Also put a space at the end of all proposals List[Proposal] sortProposals(List[Proposal] proposalsToSort): proposalsToSort.reject(p | p.label.endsWith("Description")); The sortProposals is implicitly called by each proposal provider, meaning that we only have to implement this operation once. It is always automatically caller. In TMF/xtext a proposal is added to the “acceptor”: acceptor.accept(completionProposal); At the end we would like to remove something from the acceptor, e.g. like this: acceptor.remove(completionProposal); This allows us to keep the generated proposals as they are and only put the “remove” in the overridden operation. However, The acceptor does not have a “remove” operation. 1. is it possible to add this “remove” operation to the acceptor? 2. Is there something like the sortProposals() which is always called for all proposals lists in TMF/xText ? This would allow us to implement this once, instead as for each rule. Regards, Jos Warmer
Partner
Ordina Application Outsourcing en Projecten B.V.
Centre of Excellence Disclaimer Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de afzender te waarschuwen en dit bericht met eventuele bijlagen direct te verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid voor schade die voortvloeit uit de inhoud en/of de verzending van dit bericht. This e-mail and any attachments are confidential and are solely intended for the addressee. If you are not the intended recipient, please notify the sender and delete and/or destroy this message and any attachments immediately. It is prohibited to copy, to distribute, to disclose or to use this e-mail and any attachments in any other way. Ordina N.V. and/or its group companies do not accept any responsibility nor liability for any damage resulting from the content of and/or the transmission of this message. _______________________________________________ xtext-dev mailing list xtext-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/xtext-dev Disclaimer Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de afzender te waarschuwen en dit bericht met eventuele bijlagen direct te verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid voor schade die voortvloeit uit de inhoud en/of de verzending van dit bericht. This e-mail and any attachments are confidential and are solely intended for the addressee. If you are not the intended recipient, please notify the sender and delete and/or destroy this message and any attachments immediately. It is prohibited to copy, to distribute, to disclose or to use this e-mail and any attachments in any other way. Ordina N.V. and/or its group companies do not accept any responsibility nor liability for any damage resulting from the content of and/or the transmission of this message. _______________________________________________ xtext-dev mailing list xtext-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/xtext-dev
|
