Part of this article and inspiration from the Eclipse.org website, this statement. For more information, please refer to:
Http://eclipse.org/articles/article-swt-design 1/swt-design-1.html
As we all know, SWT and SWING's largest difference is that it directly uses the ready-made local graphical interface provided by the operating system, which has localized Look & FEEL. But how did it do this? Of course it passes through JNI. Let's take an example, assume that we use the Win32 API.
We now have a text box text, through the following code, we give it a string and let it choose / Highlight from 3 to 5 ([3,5]) characters.
Text.Settext ("Abcdefgh"); Text.setSelection
3
,
6
);
Under Windows, how is this setSelection method implemented? We can take a look at the source code:
public
Void
SetSelection
int
Start,
int
END)
{... Os.sendMessage (Handle, Os.em_setsel, Start, End); Os.sendMessage (Handle, Os.EM_Scrollcaret, 0, 0);}
Friends who have done Windows programming may recognize this SendMessage at once. Isn't it the function to send messages to the form in Win32 API? Oh, yes, let's take a look at the prototype of this SendMessage method:
public
Static
Final
int
SendMessage
int
HWnd,
int
MSG,
int
WPARAM,
int
lparam)
{IF (isunicode) Return SendMessagew (HWND, MSG, WPARAM, LPARAM); Return SendMessagea (HWND, MSG, WPARAM, LPARAM);
public
Static
Final native
int
SendMessagew
int
HWnd,
int
MSG,
int
WPARAM,
int
lparam;
public
Static
Final native
int
SendMessagea (
int
HWnd,
int
MSG,
int
WPARAM,
int
lparam;
We saw two versions, a version for Unicode, another version for ASCII, just Win32 API, what we see is Native method, which means that there is also a set of JNI C code to direct and operation The system's function depends:
#ifndef no_sendMessagew__iiiijniexport jint jnicall os_native (SendMessagew__iiii) (Jnienv
*
ENV, JCLASS THAT, JINT ARG0, JINT ARG1, JINT ARG2, JINT ARG3)
{Jint rc; OS_NATIVE_ENTER (env, that, SendMessageW__IIII_FUNC); rc = (jint) SendMessageW ((HWND) arg0, arg1, (WPARAM) arg2, (LPARAM) arg3); OS_NATIVE_EXIT (env, that, SendMessageW__IIII_FUNC); return rc; } #ENDIF
#ifndef no_sendMessagea__iiiijniexport Jint Jnicall OS_Native (SendMessagea__iiii) (Jnienv
*
ENV, JCLASS THAT, JINT ARG0, JINT ARG1, JINT ARG2, JINT ARG3)
{Jint rc; OS_NATIVE_ENTER (env, that, SendMessageA__IIII_FUNC); rc = (jint) SendMessageA ((HWND) arg0, arg1, (WPARAM) arg2, (LPARAM) arg3); OS_NATIVE_EXIT (env, that, SendMessageA__IIII_FUNC); return rc; }
#ENDIF
Seeing this, you may have suddenly realized that SWT did nothing wrong with the Win32's API simple pack, we call the way in SWT, the parameters pass the parameters to the Win32 layer. This is the core idea of SWT. SWT has a very important design principle, that is, SWT API one-to-one package OS API, fully faithful to the API implementation of the operating system, if there is bug, that is also the BUG of OS, it will not try to go "Correct" operating system, because it will undermine some of the localized behavior. Faithful to OS also makes the caller do not have to have the heart of the SWT program that will be inconsistent with the local GUI of the OS. If necessary, please refer to MSDN. SWT is actually such a Thin Wrapper, we can easily access the Win32 graphics API, providing our app to the Native Look & Feel.
Here is a complete SWT example:
package sean.test.swt; import org.eclipse.swt.SWT; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; import Org.eclipse.swt.widgets.text;
public
Class
Dummyswt
