Recently, due to the heavy laboratory task, there has been no continuing to study GEF. Some things that have been mastered are like a lot, really helpless, it seems to be often touched. Most of the friends who have just contacted Gef will have this impression: GEF is too much, more thanks, some functions that can be implemented directly, and many kinds of names are very similar, plus I don't know their role, I feel like a mess. I think this is determined by the complexity of the graphical user interface (GUI), and the GUI seems to be simple. It actually contains considerable logic, especially the graphic editing method of GEF processing, can be said to be the most complex One. Every class in Gef should say that there is a reason it exists, we have to understand the author's intentions, which requires more documents and good examples.
Viewing documents and code in Eclipse is quite convenient, such as our use of a class is unclear, usually look for its annotations (select Class or Method Press F2), followed by other local usage (select class or method Ctrl Shift G), you can also find its source code (Ctrl mouse left button or F3), and Ctrl Shift T can look up a class according to the name. Learning GEF is less than the code, of course, time and patience.
Ok, gossip less, enter the topic below. This post will continue the content, mainly discuss how to implement DirecTedit, property pages, and outline views, all of which are the basic functions required to provide by the GEF application.
Realize Directedit
The so-called DirecTedit (also known as in-plane-edit) is to allow the user to modify the content directly in places originally displayed, such as selecting a file in the Windows Explorer, and then pressing the F2 key to start modifying the file name. The principle of DirecTedit is directly: When the user issues a modification request (REQ_DIRECT_EDIT), it is overwriting a text box in the location of the text content (or pull the box. We only discuss the case of the text) as the editor, after the editing, Then apply the contents of the editor to the model. (As a similar function, please refer to: Add the editing function to the cell)
Figure 1 DIRECT Edit
In GEF, this pop-up editor is managed by the DirecTeditManager class, in our NodePart class, by overwriting the PerformRequest () method to respond to the user's DirecTedit request, in this method, in this method, a DirecTeditManager class instance (in the example) NodeDirecteditManager, incorporate the necessary parameters, including acceptable editpart (which is yourself, this), editor type (using textCelleditor), and CelleditorLocator (NodeCelleditorLoCator) used to locate the editor, then use the show () method to make the editor Displayed, and the content shown in the editor has been obtained in the constructor. Simply look at the NodeCelleditorLocator class, and its key method is in Relocate (). This method is called when the content in the editor changes, so that the editor is always in the correct coordinate position. DirecTeditManager has an important initcelleditor () method, which is the main role to set the initial value of the editor. In our example, the initial value is set to the NAME attribute value of the Edit NodePart Correspondence Model; and there is also a function of setting the editor font and the selection of all text (selectall), because this is more in line with general usage habits. In NodePart, add a role to Direct_Edit_Role's editpolic, which should inherit from DirecTeditPolicy, two methods need to implement: getdirecteditcommand (), and showcurrenteditvalue (), although not encountered, but the role of the former should not feel unfamiliar - Generate a Command object to the model to modify the results to the model at the end of the editor; the latter's purpose is to update the display in Figure, although our editor covers the text in Figure, it does not require the display of Figure Figure, but Keeping the two texts at the time of editing, there is no "can't stay", such as when the text in the editor is short.
Implement the property page
Like the property pages and ordinary applications in GEF, for example, we hope to display and edit the properties of each node through the property view (PropertyView), you can make the Node class to implement the iPropertySource interface, and through a member of an iPropertyDescriptor [] type Variables describe those properties that are displayed in the properties view. If you have a friend, you should change what place to add a property in the property page, mainly three places: first to increase the corresponding description in your iPropertyDescriptor [] variable, including the attribute name and property editing method (such as text or Drop the box, if the latter also wants the list of options, followed by increasing the read property value and the code written in getpropertyValue () and the code written, which is generally like the following structure ( Previously, as an example):
Public Object GetPropertyValue (Object ID) {
IF
(Prop_name.equals (ID))
Return
GetName ();
IF
(Prop_visible.equals (ID))
Return
isvisible ()
?
New
Integer
0
):
New
Integer
1
);
Return
NULL
}
That is, do different operations according to the attribute name to be processed. It should be noted that the editor of the drop-down box type is selected by the INTEGER type data, not int or string, such as the above code returns a zerror or first item according to the Visible property, otherwise ClassCastexception will appear.
Figure 2 Property page
Implementation
In Eclipse, when the editor is activated, the master view automatically looks for the outline it provides through this editor (the outline implementation IconToutOutLinePagePagePage). GEF provides the ContentoutLinePage class to implement a chart, we have to do it is to implement a subclass of it, and focus on implementing the createControl () method. ContentoutLinePage is a subclass of org.eclipse.ui.part.page, the large-scale view is the subclass of pagebookView, in the outline view, contains a lot of Page and can switch between them, the basis for switching is current Editor of the event. Therefore, we have to do this in the CreateControl () method is to construct this page, the simplified code is as follows:
Private control outline; public output () {super
New
TreeViewer ());} PUBLIC
Void
CreateControl (Composite Parent) {OUTLINE
=
GetViewer (). CreateControl (PARENT); getSelectionsysynchronizer (). addviewer ()); getViewer (). setEtDomain (GetItDomain ()); getViewer (). setEditPartFactory
New
TreePartFactory ()); getViewer (). SetContents (getDiagram ());
Since we specified the use of the tree structure in the construction of the tree structure, the first sentence in CreateControl () got the Outline variable to a tree (see Org.eclipse.Gef.ui.Parts.TreeViewer code), the second The TreeViewer is added to the selection synchronizer so that the other party can automatically make the same choice, regardless of the EDITPART in the outline or editing area; the last three lines have been introduced in the previous post, overall The purpose is to link the model of the outline view with the model of the editing area, so that we have two views for the same model, you will experience the benefits of MVC.
The most important task of achieving outline view is basically these, but it has not yet finished, we have to bind the undo / redo / delete command to the Eclipse main window in the init () method, otherwise the main project is in the active state, the main toolbar These commands will become unavailable; in the getControl () method to return our Outline member variable, that is, specify that this control appears in the outline view; this TreeViewer should be selected from the Dispose () method Remove in the synchronizer; Finally, you must override the getAdapter () method in PracticeEditor, which is said before the Editor is activated, so you must use our implementation OutlinePage to return to the main program. The code is as follows: public object getadapter (class type) {
IF
(Type
==
IcontentoutLinePage.class)
Return
New
OutlinePage ();
Return
Super.getadapter (Type);
In this way, the tree outline view is complete, see the figure below. Many GEF applications have both tree and thumbnails, and the basic idea of implementation is the same, but the code will be slightly more complicated, because these two outlines are generally switched through a PageBook, thumbnail is generally made from Org.eclipse .draw2d.parts.scrollablethumbnail is responsible for implementation, here is not tailored here (maybe in detail later), you can also understand the code of LogicEditor in Logic example.
Figure 3 Outline View
When PS wrote this post, I made some modifications for examples, all related to this post, so if you have downloaded, I will find that the code is now slightly different (function) Still exactly the same, download). In addition, this example is not perfect. When you delete a node, its connection does not delete at the same time, and some keyboard shortcuts do not work, and there are many codes that are annotated. If you are interested, you can modify them, it is also a good learning way.