I implemented a Properties View in my own editor in eclipse and I start this view using the code:
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().showView("org.eclipse.ui.views.PropertySheet");
1) Are there listeners that are fired when properties view became visible or invisible, gain ou lost focus?
2) What code I use to know if properties view is closed?
3) What code I use to know if the properties view is opened but not visible? Like this image:
Figure 1
4) How can I know if it is visible and have focus? Like image:
Figure 2
5) And if it is visible and DONT have focus, like:
Figure 3
Use IPartListener2 to listen for all part events.
IPartService partService = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getPartService();
partService.addPartListener(listener);
You will get events for all parts so you will have to check the event is for your part. The listener gets events for all the state changes of a part (open, closed, activated, brought to top, ....)
There is also a very similar IPartListener but IPartListener2 should be used if possible.
Related
In my Vaadin 8 application, I have a TabSheet, that contains several views. When I override the enter method in the first view of my TabSheet, and then I proceed to enter the view on my application, the method doesn't get called.
Do you have a Navigator, and have you registered the views for it? Navigator's navigateTo is what calls the enter. Registering views happens along these lines:
navigator.addView("", new InitialView());
navigator.addView("second", new SecondView());
Navigation also updates the URI fragment in your browser, and makes it possible to bookmark specific views and enter them via direct URL. See e.g. https://vaadin.com/docs/v8/framework/advanced/advanced-navigator for more information about Navigator.
TabSheet isn't the most trivial thing to use with Navigator and I'm afraid I don't have a ready-made example at hand, but I think it should be doable with a custom ViewDisplay and maybe SelectedTabChangeListener.
If you aren't interested in the Navigator approach, I suppose you could replace the View+enter with something along these lines, although if you need to know the previously selected tab you'll need to keep track of it yourself since this particular event isn't very informative:
tabSheet.addSelectedTabChangeListener(e -> {
((MyClass) tabSheet.getSelectedTab()).myMethod());
});
Consider this hypothetical hierarchy...
LinearLayoutA <-- I want to handle the touches here...
|
+-SomeViewX
+-SomeOtherViewY
+-LinearLayoutB
|
+-CustomView1 <-- for these three CustomView objects
+-CustomView2
+-CustomView3
What I would like to do is know which (grand)child view was touched and handle it from within LinearLayoutA. Also, I don't control those views so I can't simply make them handle the touch internally and delegate to their parent(s).
Currently I'm manually adding touch listeners to CustomViews 1-3 but that requires a lot of 'boilerplate' work and also means I won't get notified if someone clicks on SomeViewX or SomeOtherViewY, only the specific ones I've attached the listener to.
Now in other languages such as C# with WPF, if you handle the event at the equivalent of LinearLayoutA, part of the event payload is a source, which is the view that initiated the touch, but I'm not aware of any such thing in Android.
All the examples I've seen require looping through the children and hit-testing them, then disambiguating by z-order if there's an overlap, and when you've identified the one child, then you have to go through its children and repeat.
So, is there a built-in, or 'Androidy' way to know which child in a ViewGroup was touched without manually iterating and hit-testing, or manually attaching listeners to all its children?
The OnTouchListener for ViewGroups passes in the ViewGroup as its View argument and not the child within that View that was actually touched. Since you don't have control over the source of the Views in the layout, you'll have to add the OnTouchListener manually from outside of them.
As mentioned in my comments, you can reuse the same listener for all the Views by attaching it to each of the Views you want to listen on. If you're adding these Views dynamically, it should be trivial to also call setOnTouchListener() on them as you create them.
For more on the subject, check out Android's guide to managing touch events in a ViewGroup which provides a way for the parent to intercept touch events on the child, but not vice versa.
So I have read a lot about MVC online and have learned about it in class, but I am still lost on one aspect - changing and showing Views. I know Views are GUI, they pass user input to the Controller, but I'm having a hard time wrapping my mind around how the following would work:
View A displayed
user clicks button on View A
Controller notified, tells Model
Model tells Controller to display View B
Controller displays View B?!?
The last 2 lines here is what I don't understand how to implement. If the View did not change to another View, I know to use the Observer/Observable interface to update the View. But in my case there is a Home Screen and a Game Screen and when the user clicks Play button on the Home Screen, I want the "view" and the GUI to change to the GameScreen. I want to use 2 distinct Views (I think).
I'm having trouble structuring my code to achieve this, and I don't know where to put the ActionEventListeners
Assuming you're just switching the view, this is the sequence.
View A displayed
User clicks button on View A
Button controller tells view to display View B
View displays View B
The model is not involved at all. Other controllers can change the model.
When coding a Java Swing application, here's what I do.
The view may read values from the model.
The view may not update the model.
The controller(s) will update the model.
The controller(s) may revalidate / repaint the view.
To see an example of the model / view / controller pattern in a realistic Swing application, take a look at my article, Retro Snake Game.
Whenever I have an EditText field in my android application, it is highlighted with the blinking cursor for input as soon as the activity is started (though the keyboard doesn't pop up). How can I disable this?
EditText and ListView are focusable in touch mode so when you launch your application by tapping on its icon (putting you into touch mode) the first one in your application will likely get focus. Had you entered your application by using the D-pad (moving you out of touch mode) the first Button, Spinner, EditText, or ListView would get the focus since they are all focusable.
I wouldn't get too hung up on the a View being in focus when your application starts but if you really can't stand the default way of handling focus, you could try giving focus to a TextView since it doesn't look different when it is in focus. Keep in mind that it isn't normally focusable in touch mode so you will need to enable it prior to requesting focus. Since this is a bit hacky, others (myself included) will caution you against going down this route and likely encourage you to accept the normal behavior.
View tv = findViewById(R.id.MyTextView);
tv.setFocusableInTouchMode(true);
tv.requestFocus();
PS: You may also want to check out this other SO question as it is nearly identical to yours.
You could call setFocusable(false) to avoid this. But if it should become focus later then maybe you have to call setFocusable(true) again later.
Is there anyway to create a dialog that is modal to a view and not the entire shell (application)? So if say, I have one view called A that is overlaying another view called B, I want to open a dialog that is only modal to view A, so when I switch to view B, the dialog and the view A will be covered by view B. Is there anyway I can do this, even if it is not the normal practice to do?
Thanks!
I think it won't be so easy to implement. One possibility is that instead of using a modal dialog in View A, you use a TabFolder. Then, you can open the contents of the dialog in a new Tab instead and force this tab to stay on top until you dismiss it. This is a similar behavior to the one you need.
This will also allow you to drag and drop something from View B into View A.
The whole idea of workbench restore is to put the workbench back into the state it was in before. It does not have to restore every little detail but if you don't want to leave the view blank then you should restore it to its original state. That means view B should be restored with the same input that it had when you closed the workbench. If view B and its input continue to exist after view A is closed then view B and its input can be restored, regardless of whether view A exists or not. You certainly should not be opening dialog boxes during workbench restore. That would not be good UI design. Eclipse provides a very easy to use memento framework that can save a view's input. Use it.
If you are not familiar with mementos, see for example http://wiki.eclipse.org/FAQ_How_does_a_view_persist_its_state_between_sessions%3F.