I am trying to write a method that will toggle a button from being disabled to being enabled and back using a simple if statement.
I would assume that it would be something like
if (buttonDisable.setEnabled(true) == true){
//do stuff
}
But I haven't had much luck finding my answer via google.
Don't test the display of the model, test the model.
if (buttonDisable.getModel().isEnabled()) {
// do stuff
}
That way if you change the model, you avoid a level of dispatch (view --- updates ---> model --- updates ---> view(s))
A better solution is to make your model changes independent of the view. This way you don't get tied into requiring a specific view to be present to make the model change.
ButtonModel toggle = new ButtonModel();
...
JButton button = new JButton(toggle);
...
// this is clear that we are manipulating the model, not the view
// as new views are added / removed, this toggle will continue to work
toggle.setEnabled(!toggle.isEnabled());
Why not just toggle the state in one shot:
buttonDisable.setEnabled(!buttonDisable.isEnabled())
Related
I'm making a to-do list app and after user presses the button I create a new GridLayout(and all the data about time and name of the task inside of it) and add it into my RelativeLayout. How do I save those GridLayouts in UI so after the activity is destroyed and launched again those layouts are there.
After pressing the button I trigger the Create Activity method
public void CreateActivity(String name,int hours, int minutes,int i)
{
RelativeLayout.LayoutParams relparams= new RelativeLayout.LayoutParams(RelativeLayout.LayoutParams.MATCH_PARENT,RelativeLayout.LayoutParams.WRAP_CONTENT);
relparams.addRule(RelativeLayout.BELOW,i);
relparams.setMargins(0,50,0,100);
Glayouts.add(new GridLayout(this));
Glayouts.get(i+1).setBackgroundColor(Color.GRAY);
Glayouts.get(i+1).setMinimumWidth(relative.getWidth());
Glayouts.get(i+1).setId(i+1);
Glayouts.get(i+1).setPadding(10,0,0,0);
GridLayout.LayoutParams namee = new GridLayout.LayoutParams();
namee.columnSpec = GridLayout.spec(0);
namee.rowSpec = GridLayout.spec(0);
namee.setGravity(Gravity.LEFT);
final TextView Actname = new TextView(this);
Actname.setText(name);
GridLayout.LayoutParams checkbox = new GridLayout.LayoutParams();
checkbox.columnSpec = GridLayout.spec(1);
checkbox.rowSpec = GridLayout.spec(0);
checkbox.setGravity(Gravity.RIGHT);
CheckBox check = new CheckBox(this);
// ADDING TO LAYOUT
Glayouts.get(i+1).addView(Actname,namee);
Glayouts.get(i+1).addView(check,checkbox);
relative.addView(Glayouts.get(i+1),relparams);
Theoretically when you extends View, then you can also override onSaveInstanceState and onRestoreInstanceState methods, where you must provide your own SavedState class that typically extends BaseSavedState. You can find info on that here
In your case, your layout is dynamic, therefore this doesn't really work. To tell you the truth, your layout probably shouldn't be constructed this way, you should be rendering the grid using a RecyclerView based on a "model" that describes this layout, render the items of the grid via the RecyclerView.Adapter, and you should persist either the "model", or the data you use to construct this model along with the user-inputted state so that you can re-construct the model that will be rendered via your RecyclerView.
You can read more about RecyclerView here.
You can read more about data persistence here.
You can read about using onSaveInstanceState to save data in Activities/Fragments across config change and process death (but not finishing then restarting the app) here.
You can’t. The best way to save state is to use some persistence mechanism, for example database (I’d recommend Room as it is officially supported by Google).
After clicking a button, you should put all the needed information (name, hours, minutes) in the database and when Activity is created, you can read all persisted data and - basing on it - create all needed layouts again.
Another option is storing data in SharedPreferences - it is much easier to setup, so you can also start with this solution. Please note, I'm suggesting it as a first step in the world of persistency in Android, not as a preferred solution for storing data.
When I am editing grid inline I can save or cancel my grid row changes. I want to update my database entries after button 'save' will be pushed(Data base mechanism has already done) How can I implement it?
My container:
BeanItemContainer<CategoryOfService> beansContainer;
Editing view:
All what I need it know which listeners I have to use. I found some CommitHandler which I can add by EditorFieldGroup class but I can't implement it properly maybe there is have to be another way to resolve problem.
There's kind of a way to capture inline Save click on the grid.
grid.getEditorFieldGroup().addCommitHandler(new FieldGroup.CommitHandler() {
#Override
public void preCommit(FieldGroup.CommitEvent commitEvent) throws FieldGroup.CommitException {
//...
}
#Override
public void postCommit(FieldGroup.CommitEvent commitEvent) throws FieldGroup.CommitException {
//...
}
});
After clicking Save both methods preCommit and postCommit get called.
Hope it helps :)
Grid does not currently give you any direct way of adding listeners to the save and cancel buttons for the inline editor, although that is something that might change in Vaadin 7.6.
As a workaround before that happens, the CommitHandler approach that you already mentioned is still supposed to work. You can find a basic example here. The contents of your BeanItemContainer should be fully updated in the postCommit phase.
grid.getEditor().addSaveListener((EditorSaveListener<Product>) event -> {
//your stuf
HibernateDataSource.updateProduct(event.getBean());
});
In a CTabFolder, I'd like to check the content for unsaved data before the user can switch from one tab to another. SWT does not provide a PreSelection event, as stated here.
I found a workaround, suggesting to switch back to the old tab when a selection is triggered, validate the data and then perform the desired switch again, if data is valid.
I do understand the general idea of this workaround, however, it is not working for me. oldPageIndex and newPageIndex do always have the same value, though I did not click on the same tab.
this.tabContainer.addSelectionListener(new SelectionAdapter() {
#Override
public void widgetSelected(SelectionEvent event) {
int oldPageIndex = tabContainer.getSelectionIndex();
int newPageIndex = tabContainer.indexOf((CTabItem)event.item);
// Here: oldPageIndex == newPageIndex
...
}
});
Is this workaround still working or is there anything I could possibly be doing wrong? Or maybe, has there been any fix for a real PreSelection event in the meantime? I tried using event.doit, but the SelectionEvent is fired, when the tabs have been switched already.
You can use the selection listener but as you have found the getSelectionIndex() does not give you the old tab. So you will have to maintain the old tab index yourself.
This is the technique used by the Eclipse FormEditor.
All,
I am creating a palette less eclipse plugin where am adding figures to the custom editor through the contextual menu, but am not finding a way to do it. Can anyone please guide me as to how to go about adding figures to editor dynamically through context menu i.e. adding actions/commands.
Since Eclipse GEF plugin development finds so less examples to look at, I am adding my solution so others find it useful. This code helps to render a node to the editor.
Source code for Action class to render figures to the editor:
public class AddNodeAction extends EditorPartAction
{
public static final String ADD_NODE = "ADDNODE";
public AddNodeAction(IEditorPart editor) {
super(editor);
setText("Add a Node");
setId(ADD_NODE); // Important to set ID
}
public void run()
{
<ParentModelClass> parent= (<ParentModelClass>)getEditorPart().getAdapter(<ParentModelClass>.class);
if (parent== null)
return;
CommandStack command = (CommandStack)getEditorPart().getAdapter(CommandStack.class);
if (command != null)
{
CompoundCommand totalCmd = new CompoundCommand();
<ChildModelToRenderFigureCommand>cmd = new <ChildModelToRenderFigureCommand>(parent);
cmd.setParent(parent);
<ChildModelClass> newNode = new <ChildModelClass>();
cmd.setNode(newNode);
cmd.setLocation(getLocation()); // Any location you wish to set to
totalCmd.add(cmd);
command.execute(totalCmd);
}
}
#Override
protected boolean calculateEnabled()
{
return true;
}
}
I think you need multiple different things here. Please remember that GEF would like you to have proper MVC pattern, where you have your own model, Figures as View and EditParts as controllers.
From the top of my head I would say that you need at least these things:
CreateCommand
contains all model level modifications that you need to
perform to add your new data to your
data model (undoable and transactional)
CreateAction
makes that CreateCommand instance, initializes it with current selection and executes that command in editdomain
ContextMenuProvider
Provides that CreateAction to context menu
If you happen to be using GMF the canonical mechanism will generate the editparts for you automatically when you make the model modifications inside a command, but if you are not using GMF, you must make sure that your own models and editparts are handling and refreshing the new item adding properly.
EDIT:
Ok, here is some code suggestion with playing around with requests.
public void run() {
// Fetch viewer from editor part (might not work, if not, try some other way)
EditPartViewer viewer = (EditPartViewer) part.getAdapter(EditPartViewer.class);
// get Target EditPart that is under the mouse
EditPart targetEditPart = viewer.findObjectAt(getLocation());
// If nothing under mouse, set root item as target (just playing safe)
if(targetEditPart == null)
targetEditPart = viewer.getContents();
// Make and initialize create request with proper information
CreateRequest createReq = new CreateRequest();
createReq.setLocation(getLocation());
createReq.setFactory(new OwnFactoryImplementation());
// Ask from target editpart command for this request
Command command = targetEditPart.getCommand(createReq);
// If command is ok, and it can be executed, go and execute it on commandstack
if(command != null && command.canExecute()) {
viewer.getEditDomain().getCommandStack().execute(command);
}
}
Now what happens is that editpart will be requested for creation, so the action itself doesn't know how the command works, what makes it objective agaist the command.
So to make things work, you need to install new EditPolicy to your EditPart. EditPolicies can be installed on EditParts createDefaultEditPolicies() function. This EditPolicy must react and return command when there is CreateRequest. This way any child can provide own kind of command for creating children for itself.
Here is a good image how it works (controller is EditPart):
Please ask if I can help you some more. I know that this looks bit more complex, but this makes your own life much more easier, and after you have done that, you actually understand Command-Request Pattern quite well, and it can be reused in many different places.
I need some help. Is it possible to simulate a drag & drop without registering a component?
E.g. I click the mousekey anywhere on the window and hold the mousekey down, at this moment, I want to create or simulate a DragSourceEvent programmatically with Java.
Is this possible?
Update:
Regarding Bob's reply, at least I got it, I can create a listener for the drag & drop:
DragSource dragSource = new DragSource();
DragGestureListener listener = new DragGestureListener() {
public void dragGestureRecognized(DragGestureEvent event) {
event.startDrag (null, strSel) ;
...
}
}
listener.dragGestureRecognized(new DragGestureEvent(
new DragGestureRecognizer(dragSource, component) {
}, DnDConstants.ACTION_COPY, new Point(0,0), events ));
but unfortunately i get this exception:
java.lang.IllegalArgumentException:
source actions at
java.awt.dnd.DragSourceContext.(DragSourceContext.java:169)
at
java.awt.dnd.DragSource.createDragSourceContext(DragSource.java:454)
at
java.awt.dnd.DragSource.startDrag(DragSource.java:293)
at
java.awt.dnd.DragSource.startDrag(DragSource.java:403)
at
java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:203)
any suggestions?
The question you asked:
I haven't tried it, but in theory you should be able to create the Event object and get a handle on the Swing Event Queue from one of the system classes. However without having a valid component, there may be problems when methods try to work with the event.
What you probably meant:
Registering events for a standard window -- you should be able to set up drag and drop support for an empty JPanel or JFrame, but it'll take some hacking. Drag & Drop is a pain to work with at this level when not built in -- I suggest using something like an invisible component or something instead.