I didn't manage to find any functionalities for minimizing/maximizing programatically.
I want to minimize my editorArea when all the editors are closed.
Any suggestions?
Thanks in advance.
I found a workaround to minimize the editorArea. It's not very nice but it's doing the job.
WorkbenchPage page = (WorkbenchPage)PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
IEditorReference[] editorReferences = page.getEditorReferences();
if(editorReferences.length==0){
page.getActivePerspective().setEditorAreaState(IStackPresentationSite.STATE_MINIMIZED);
}
I really don't like that cast but I cant get the concrete class.
Any suggestions for improving this?
You can show/hide editor area using IWorkbenchPage.setEditorAreaVisible(). You could do this by adding IPerspectiveListener to the window.
public void perspectiveChanged(IWorkbenchPage page,
IPerspectiveDescriptor perspective, String changeId) {
if (changeId == IWorkbenchPage.CHANGE_EDITOR_CLOSE) {
if (page.isEditorAreaVisible() && page.getEditorReferences().length == 0)
page.setEditorAreaVisible(false);
}
}
While it is also possible to minimize editor area using setPartState() method of the page, this can't be done after all editors are closed. Even though the last editor reference is available in close editor event handler, the reference to ILayoutContainer has already been removed and thus can't be used to change the state.
I found this bug on bugs.eclipse.com: https://bugs.eclipse.org/bugs/show_bug.cgi?id=29840 but i can't find the ZoomManagement.
Related
Pretty straight-forward question, but I can't find this anywhere. I'm using WicketStuff's TinyMCE to make a Rich Text Editor in my application, and can't find anywhere how to get the input from the text area. For brevity's sake, the following is a simplified version of the code I'm using.
private String input;
...
TinyMCESettings settings = new TinyMCESettings(TinyMCESettings.Theme.simple);
TextArea<String> textArea = new TextArea<String>("editor", new PropertyModel<String>(this, "input"));
textArea.add(new TinyMceBehavior(settings));
form.add(textArea);
Using this, I would expect the usual manner to simply use my String 'input' since it's set as the model. This always results in null as the model isn't being updated.
I tried using the auto-save plugin in case it was expecting the save button to be clicked (which doesn't update the model either), and neither worked. The only thing I've been able to do to get the user's input is to add a HiddenField, with a new model, and make a JavaScript call like
document.getElementById('hiddenField').value = tinyMCE.get('editor').getContent();
but this has led to other problems with trying to call the JS in the desired place and to get it to work properly. I feel this shouldn't be necessary anyways, as surely someone must have implemented a method to get the contents of the text area being used.
Any help would be greatly appreciated.
Thanks to a blog post at Nevermind Solutions, the way to get the model updated is to add the following JavaScript to the form's submitting button:
onclick="tinyMCE.triggerSave(true,true);"
My text area is inside a panel with the button outside of the panel, so it doesn't directly work for me. The trick was to add the JavaScript call to the button's onSubmit, move the logic into the onAfterSubmit, and to make the button MultiPart so that it could call the save trigger before doing the other logic associated to the model.
Hope this might help some others in the future.
You have to add a modifier to the submit button so that the model can update.
AjaxButton btnSubmit = new AjaxButton("btnSubmit", new Model()) {
#Override
public void onSubmit(AjaxRequestTarget target, Form<?> form) {
doSomething();
}
};
btnSubmit.add(new TinyMceAjaxSubmitModifier());
Have a look here for more info
I'm wondering if it is possible to determine what input was just entered inside of an editor in Eclipse - I'm currently working off of the example JDT editor - and then perform an action based on that input.
e.g.: I have a file example.jav open in my editor window. I push the 'a' key. 'a' would appear in the editor window per normal, but 'a' would also print out to the console.
Obviously the operation I'll be performing will be more complicated than a System.out.println() statement, but if someone could help show me where the change gets detected by the editor itself, I can take it from there.
A few notes:
I'm working in Eclipse 3.7.2 with Java 1.7
If you cannot find the JDT example editor, go to Help > Welcome > Samples and click on "Java Editor".
Thanks in advance!
Figured it out!
As the Editor API is so vast in eclipse that it is difficult to know where to start, I focused on adding a KeyListener to my Shell. Turns out that is slightly problematic in SWT, as when an item inside the Shell gains focus, the Shell itself looses focus. After a bit of searching though, I stumbled across someone else who had the same problem. By adding a filter to the Shell's display, you can add a Listener object which works for the entire application. Such as:
IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
Shell shell = window.getShell();
shell.getDisplay().addFilter(SWT.KeyDown, new Listener()
{
public void handleEvent(Event event)
{
System.out.println("" + event.character);
}
});
To further this and only worry about keys pressed in a specific non-widget part (otherwise you could just add a KeyListener to that part) you can add a check to make sure that the currently active part is the same as whatever part you wish to perform the actions for by using a simple if check.
final IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
Shell shell = window.getShell();
shell.getDisplay().addFilter(SWT.KeyDown, new Listener()
{
public void handleEvent(Event event)
{
IWorkbenchPage page = window.getActivePage();
IWorkbenchPart part = page.getActivePart();
IEditorPart editor = page.getActiveEditor();
if(part.equals(editor))
{
System.out.println("" + event.character);
}
}
});
Here is hoping that this helps someone else have an easier time than I had finding the solution!
This feature has been realized as of Kepler M4, for a detailed information on the usage see my blog
I want to realize a fully dynamic menu contribution to the menu of a handler located in a view toolbar. In Eclipse 3 it was possible to add "dynamic" as org.eclipse.ui.menus contribution to a Menu!
I already found out about www.vogella.com/blog/2010/10/26/processors-e4-model explaining on how to dynamically contribute to menus by means of processor model extensions but I am talking about a completely dynamic menu implementation which changes on every call of the resp. submenu. As mentioned this was no problem to realize in Eclipse 3.x via the dynamic menu contribution and the set of isDynamic() to true.
I already tried several approaches:
Registering a processor hooking to a menu => no dynamic add possible (new elements are simply not shown, also discussed in Eclipse Forum - Cannot replace menu items at runtime)
Listening to the UIEventTopic for the event of creating the menu, getting the widget for Modification => modifications to the swt.Menu gathered are simply ignored (every listener, element etc.) (for info RCP Event Model
Open, untried solutions
Inserting a ToolControl to try an SWT approach -> quite complicated but may work
I've been banging my head for some time now, but can't seem to understand the correct implementation of this problem within E4.
-- This question was also asked in Eclipse Forum - Dynamic menu contributions
----- UPDATE
I tried a different approach up to now:
I added a HandledToolItem to the Menu (please see the following image)
and with the following code I am trying to interfere with the menus way to build, where the code is called by the resp. command handleer as referenced in the image.
#CanExecute
public boolean canExecute(#Optional MApplication application) {
System.out.println("CanExecute Counter="+counter);
// --- 1 ---
// Find the required MMenu Entry in the Application Model
if(application == null) return true;
EModelService modelService = (EModelService) application.getContext().get(EModelService.class.getName());
MPart part = (MPart) modelService.find("at.medevit.emr.contacts.ui.contactselector", application);
List<MToolBarElement> lmte = part.getToolbar().getChildren();
HandledToolItemImpl htil = null;
for (MToolBarElement mToolBarElement : lmte) {
if(mToolBarElement.getElementId().equals("at.medevit.emr.contacts.ui.contactselector.toolbar.handledtoolitem.filter")) htil = (HandledToolItemImpl) mToolBarElement;
}
if(htil != null) {
MMenu elemMenu = htil.getMenu();
// --- 2 ---
// Found it hopefully, let's start the real work, simply add a new item
MDirectMenuItem mdi = MMenuFactory.INSTANCE.createDirectMenuItem();
mdi.setLabel("Counter "+counter);
counter++;
// --- 3 ---
elemMenu.getChildren().add(mdi); // ConcurrentModificationException
}
As one can see, this code is queried once the menu is created, to determine whether the command is executable or not. All the code from 1 - 2 is to find the correct MMenu element to work on. The code from 2 - 3 creates a MenuItem and increments a counter in the field.
BUT at 3 I face a java.util.ConcurrentModificationException the first time the menu is opened! I assume that at this very point the menu is iterating over elemMenu.getChildren() and I am not allowed to enable!
So whats all the fuzz about the entire e4 model being changeable all the time ;) (just kiddin' I know this is a baaaad hack!!!)
Thing is: I really think that the possibility to add fully dynamic menu parts is one of the best usability tools, and if it is not possible to realize it in E4 as it was in E3 this is a very serious degradation of possibilities!!!
-- UPDATE
An Eclipse Bug has been filed for this https://bugs.eclipse.org/bugs/show_bug.cgi?id=389063
Proper dynamic model updates should be handled in the bug you've opened. As a workaround in Eclipse4 in Juno, a MRenderedMenuItem can be created in Eclipse4 to provide the equivalent functionality to the dynamic element (although if you are using 4.2, you would just use org.eclipse.ui.menus).
ex:
ContextFunction generator = new ContextFunction() {
#Override
public Object compute(IEclipseContext context) {
return new MyCompoundContributionItem(context);
}
};
MRenderedMenuItem menuItem = MenuFactoryImpl.eINSTANCE.createRenderedMenuItem();
menuItem.setElementId(id);
menuItem.setContributionItem(generator);
container.getChildren().add(menuItem);
This effectively provides a CompoundContributionItem directly to the Eclipse4 menu renderer.
I love eclipse auto formatting, but there's one feature that's driving me raging mad:
Since I use wrap-lines in my auto-formmatter, code like this:
private static Location _location = null; // this is a comment
turns into horrible, horrible code like this:
private static Location _location = null; // this
// is
// a
// comment
this is not only painful to watch, but not at all convenient to change back...
Is there any way to remove line-wrapping for comments, or at least fix so it doesn't look like an absolute mess?
Thanks
I think that the thing you are specifically asking about you can achieve by editing your formatter:
Window -> Preferences -> Java -> Code Style -> Formatter. There edit you click on Edit...
If you are using the default Eclipse formatter you will need to edit the profile name (you cna not edit built in profile).
Go to comments
Deselect line comment formatting.
That way no formatting of comments of the type // will be done.
This annoys me also. To fix the wrapped comments you can use the keyboard shortcut CTL+ALT+J to join the comments onto one line. The comment-indicator characters (// or *) will still be there but at least it will save you some steps. Then you can just run a find and replace for the comment-indicators.
The CollapsiblePanelExtender seems primarily designed to collapse/expand things in response to user mouse events. Is there also a good way to get the extender to collapse/expand things in response to client-side javascript?
In my particular case, I have a number of CollapsiblePanelExtenders (and their corresponding Panels) on a page, and I'm wondering if I could implement an "expand all panels" button by doing something like this strictly on the client side:
for each CollapsiblePanelExtender on this page, call somethingOrOther(extender)
I can implement this logic server-side instead if I did a full postback, but my page takes a long time to load, and so this doesn't seem like it would provide a very slick user experience. Thus I am interested in doing expand/collapse client-side.
It seems like this isn't a use case the AJAX Control Toolkit people had in mind, but I thought I'd check.
Write the following code in the OnClick event of Image/button
<asp:Image ID="img1" runat="server" OnClick="ExpandCollapse()"/>
function ExpandCollapse() {
$find("collapsibleBehavior1").set_Collapsed(true);
$find("collapsibleBehavior2").set_Collapsed(true);
}
Hope this helps!
I have a partly working solution now.
I followed Ian's suggestion and looked through the toolkit source. In CollapsiblePanelBehavior.debug.js, you can that expandPanel() is apparently intended as part of the public interface for the behavior. There's also a get_Collapsed(). The key to accessing these behaviors in javascript seems to be setting the BehaviorID property on your CollapsiblePanelExtender tags in ASP.NET.
I modified the repeater on my page so that the BehaviorIDs are predictible, along these lines:
<ajaxToolkit:CollapsiblePanelExtender
BehaviorID="<%#'collapsebehavior'+DataBinder.Eval(Container.DataItem,'id')%>"
ID="CollapsiblePanelExtender" runat="server" />
This results with behaviors named collapsebehavior1, collapsebehavior2, collapsebehavior3, etc..
With this done, I'm able to expand all the collapsible panels on the client as follows:
function expandAll() {
var i = 0;
while (true) {
i++;
var name = 'collapsebehavior' + i;
var theBehavior = $find(name);
if (theBehavior) {
var isCollapsed = theBehavior.get_Collapsed();
if (isCollapsed) {
theBehavior.expandPanel();
}
} else {
// No more more panels to examine
break;
}
}
}
I'm sure using $find in a loop like that is really inefficient, but that's what I have so far.
Also, it doesn't work on Firefox for some reason. (On FF only the first element expands, and then there's a Javascript error inside the Control Toolkit code.)
This will all seem extremely ugly to all you javascript pros. Maybe I'll clean things up later, or you can help me out.
You can also just toggle the panels to switch between collapsed/expanded states:
function toggle() {
var MenuCollapser = $find("name");
MenuCollapser.togglePanel();
}