According to https://www.zkoss.org/wiki/ZK_Component_Reference/Essential_Components/Button#Autodisable, I have customized our ZK app to enable autodisable for all buttons by specifying the following in the custom language addon:
<language-addon>
<component>
<component-name>button</component-name>
<extends>button</extends>
<property>
<property-name>autodisable</property-name>
<property-value>self</property-value>
</property>
</component>
It works fine for buttons defined in ZUL files but not for buttons defined in Java, for example when I have to display a button in each row of a table (listbox), and so I define the buttons in the renderer class.
I could also set the necessary functioning individually for a button:
myButton.setAutodisable("self");
but it would be nice to arrange it in a similar central way as for the normal buttons. How to achieve it?
Since you have access to the button class in Java, the simplest solution would be to create a ButtonExt (or any class name that makes sense in your project's name patterns), generate constructors based on the super class and add this.setAutodisable("self"); in the constructors (after super(...);)
This is basically what the zul parser does. The component config described in your post is just an instruction to tell the parser to always call newComponent.setAutodisable("self"); every time that it instantiate a button.
Since your ButtonExt will be extending the default button class, you can then just instantiate it in Java:
Button myButton = new ButtonExt();
and it will act as a standard button, with your extra initialization code.
Related
I have splitted my application into two main areas.
Part(A)
PartStashContainer(B)
The content of A should be set based on what user wants.
So basically i can have 1..N classes which could be used in Class URI of Part in application model.
I don't know if i should replace the whole Part(A) with new dynamically created Part(C) which has content i want, or i should somehow to modify the existing Part (call setContributionURI, or setObject methods on Part object?).
It does make more sense to me to modify the existing Part, because it is defined in Application model and therefore already describing the location where the content should be.
Possible solutions:
Modify the Part object so it "reload" its content based on new setup (But how? Can setContributionURI or setObject methods help?)
Remove the old Part and add dynamically on same place in Application model the new Part (using EModelService and EPartService).
other solution??
If you want to reuse the Part then do something like:
MPart part = find or inject your part
MyClass myClass = (MyClass)part.getObject();
... call a method of MyClass to change the contents
MyClass is the class you specify for the object in the application model. You should add a method to that to let you change the contents.
Don't try to call setObject, this is really only for use by Eclipse. I don't think setContributionURI would do anything after the part is created (but I am not sure).
If you want to use different classes for the different data then you really should use different Parts.
I want to create a rectangle button field (using list).
The "cells" in this field are basically buttons, the only thing I need to change is the OnClick event handler (I want it to check some button properties and take some action according to them).
I did something like this before in MSVS 2013, using C++/CLR, I just wrote the method I wanted to work as an event handler, added event handler variable to the "cell" constructor, and assigned it as a new event handler while "filling" the list.
It looked something like this:
.h
cell(<...>, System::EventHandler^ eh) : {
<...>;
Click += eh;
}
.cpp
List^ list = gcnew List(<...>, gcnew System::EventHandler(^Form1, &Form1::cell_Click));
Mr. Google told me that in C++ Builder inheritance of managed objects is not just writing a colon after the class declaration, it's a process called "Creating component".
Since I don't need to re-use this little piece of code, I don't want to create any packages or use existing. So I create a unit.
The questions are:
Where to write event handler declaration in header?
Where to write event handler implementation in .cpp file?
How do I actually use the written unit in the project I added it to? I mean, can I just declare a variable of the custom inherited type in the project files?
C++Builder uses C++ as its language, not "Managed C++". there is no ^ pointer types and no gcnew, or "managed objects".
To make an event handler easily, select the control in the form editor and press F11. That will bring up the Object Inspector. Select the "Events" tab and then double-click the handler you want to create. This will create the code you need, you just have to fill in the function body.
If you double-click on the control, it's a shortcut to create the most common event handler for that object (which is actually OnClick for a button, so you could just double-click your button).
(In older versions of C++Builder, if you saved your project before typing anything in the function body, it would very kindly delete the handler, which was pretty annoying -- XE5 no longer does that).
I don't quite understand what you are talking about in some of your post - why do you want to inherit from the button? I figured from your opening paragraph that you just want to create a bunch of buttons at runtime, and implement the OnClick handler.
If you mean that you just want to create a lot of buttons at runtime, then you can do it like this:
TButton *b = new TButton(this); // 'this' will be responsible for deleting the button
b->Parent = this; // `this` will be responsible for displaying the button
b->Caption = "hello";
b->OnClick = Button1->OnClick;
// set other properties
AFAIK there is no easy way to clone a button. You have to make a new button like this, and then copy the values you want from another button. Properties you don't set will have their default values.
If you use this method (i.e. make Button1 in the form editor and then copy its OnClick to your other buttons) it is nice and easy. You could actually delete your Button1 after you have used it to auto-generate the OnClick handler and give you the right function signature.
You could also store the pointers to each button in a list , e.g. std::list<TButton *>. Be mindful of button lifetimes when doing this: the fact that the button's Owner is the form means that the form will delete them during the form destruction. You should not try to delete these pointers yourself, and you should not use them during or after the form destruction.
Inside the OnClick handler, you can get a pointer to its Button by doing:
TButton *b = dynamic_cast<TButton *>(Sender);
Then you can use b->Tag or some other property of the button to identify which button was clicked.
Is there any idea wich allows me using layouts declared in MyApplication.java from other classes and functions.
I tried put them in parameters it works but it becomes very complicated
For example xhen callin a function named Y in function X I have to pass all layouts on parameters like this:
X(layout1,layout2,layout3,layout4)
{
Y(a,b,c,layout1,layout2,layout3,layout4)
}
I tried to use a class named uiHelper but it didn't works
You can take a look at Blackboard addon for vaadin.
https://vaadin.com/addon/blackboard
From that page:
Sometimes, having a deep component hierarchy poses a problem, when you need to inform a component high up in the tree that something happened deep down below. You normally have one of two choices - either pass the listener all the way down the hierarchy, leading to more coupled code, or let each component in between be a listener/notifier, passing the event all the way back up. With the Blackboard, you can register any listener to listen for any event, and when that event is fired, all the listeners for that event are triggered. This keeps your components clean and rid of unnecessary boilerplate code.
For your example, you can create a LayoutChangeListener and LayoutChangeEvent.
MyApplication can then implements LayoutChangeListener and when a LayoutChangeEvent is fired, you can change your layout without passing it around.
I am currently implementing an Eclipse-Plugin which is using the standard properties view, connected to a Navigator. It also features a textual editor, which is able to connect regions within its' document to certain objects that can supply properties to the PropertiesView (i.e. the same objects, that are displayed in the Navigator).
However, the Tuturials I found only dealt with Views that used a pre-implemented Viewer, which already supported passing on the selected element to the Properties View.
The TextEditor does not do that (I am using jface and a subclass of the AbstractTextEditor class), because it's SelectionProvider returns informations about the offset and the length of the selection only.
How do I have to modify the SelectionProvider of my TextEditor, such that it provides information usable to the Properties View?
Thank you in advance
Okay, I have managed to find the solution myself.
First of all, I had to implement the getAdapter() method in my subclass of TextEditor such that it returns an Adapter for IPropertySourceProvider, that can deal with the type of elements that are selected in my AbstractTextEditor.
Then, I implemented an ISelection that extended TextSelection, in order to not interfere with any selection-specific mechanism supplied by the AbstractTextEditor, and implements the interface IStructuredSelection, because the Properties View works with this interface of ISelection only.
An IStructuredSelection features basic methods of an array, however, in my case it is only possible to ever select only a single element, so implementation of these methods were trivial.
The last step was to get my ISelection to the right place. Overwriting the getSelection()-method of the ISelectionProvider of the AbstractTextEditor did not suffice, because obviously, the methods of firing SelectionChangedEvents does not use this method.
Thus, instead of using a standard SourceViewer, I used my own implementation in which I basically overrid the methods fireSelectionChanged(int offset, int length) and firePostSelectionChanged(int offset, int lenght), such that they use events containing my ISelection.
The rest is implementing the handling of my Objects in the Adapter for IPropertySourceProvider in a way that it returns an IPropertySource for the given Object, as it is shown in various tutorials.
Looks like the class that is generated for PlaceHistoryMapper is hard-coded to use AbstractPlaceHistoryMapper as the super class.
So, I am trying to work around this by trying to replace this AbstractPlaceHistoryMapper with a custom mapper of mine using deferred binding . I am using the following rule in my *.gwt.xml:
<replace-with class="com.google.gwt.place.impl.AbstractPlaceHistoryMapper">
<when-type-is class="com.test.sampleapp.CustomPlaceHistoryMapper" />
</replace-with>
But for some reason the replace does not seem to be happening. CustomPlaceHistoryMapper is not getting kicked in and the generated class still uses AbstractPlaceHistoryMapper.
Any thoughts/pointers as to what might be resulting this behavior are much appreciated.
Note: I have also posted this on the GWT group but haven't received an answer so far.
To make the deferred binding work a class must be created with GWT.create(). However, AbstractPlaceHistoryMapper is only used as an extended class. So it will never be created via GWT.create, but always by instantiation the subclass. And therefor deferred binding won't work in this case. If you want a complete different implementation you have to implement a custom PlaceHistoryMapper, and manage the known tokens yourself. This also means you can't use the History annotations either.
As a side note the classnames in your rule should be swapped. But for the end result this doesn't matter, since it won't work in the first place.
It is absolutely possible to have custom history tokens (eg. #mail or #mail/bla instead of only #mail:inbox) using the out-of-the-box Place-related classes that GWT (2.0) provides.
Instead of replacing AbstractPlaceHistoryMapper you could instantiate the default PlaceHistoryMapper passing in it's constructor your implementation of PlaceHistoryMapper<T> or PlaceHistoryMapperWithFactory<T>.
eg.:
final PlaceHistoryHandler placeHistoryHandler = new PlaceHistoryHandler(new CustomHistoryMapper());
You will be able then to map tokens as you wish.
I personally recommend you to use an unique PlaceTokenizer in you mapper custom implementation so that I dont have to have an inner PlaceTokenizer class in each of your Places.
Hope that helps. Feel free to ask any doubts.