UI implementation solution of the WINCE Application

I. MFC hard Injury

Before taking over the current project, I was still an idiot for UI development on WINDOWS platform. Apart from MFC, I only knew about GDI. In addition, MFC can only draw gray dialog boxes and buttons. HoweverEmbeddedI will not use MFC for such cost-sensitive projects. In extreme cases, the customized system is 31.8 M. I put an MFC DLL on ARMV4I, which is about 500 K, so there are only two options, either change the 32 m flash to 64 m flash -- my boss will cut me down, or rewrite all the UI code at the application layer -- my subordinates will give me a crash. On the other hand, I have seen a lot of applications on WINCE.Open SourceCode, but also some external software, I have never seen anyone using MFC. When you use MFC on the Internet, the program portability on different platforms will be reduced, because you cannot expect other platforms to prepare luxury MFC for you. On the other hand, most experts are not willing to use it. I am not a master, but I can learn how to set the spectrum, so "Don't use" becomes "disdain to use" ^_^

Ii. Difficulties of GDI

Writing the entire UI from CreateWindow is really tiring. I wrote more than 500 lines to barely implement the BUTTON class, and another colleague used about 500 lines to implement the TRACK BAR class.TestAnd there is no formal code review. If IndustryDesignThe center adds several more patterns, so we need to add several base classes and then compensate for the code review time, test time, and bug fix time. It's not painful ~.

3. Exploring the path of GWES, I am not a pioneer

The wisdom of the masses is infinite. When my colleagues in this group were constrained by my GDI solution, the software engineer from the communication department helped complete the project to capture the DialogBox function from an application sample code of WINCE500. In my opinion, one thing that fails in the UI implementation solution is to habitually create a dialog resource from eVC, and then click Class Wizard immediately, and then associate the MFC Class. After the DialogBox and BUTTON are drawn, the UI is created from the DialogBox function with the resouce id. I also habitually think that DialogBox is not in STANDARD SDK 500, but he does use DialogBox and BUTTON without referencing other LIB and DLL from STANDARDSDK_500, then, let's talk to me about how to overlay the image on the DIALOG and BUTTON. One hundred miles ~ I should try to find a piece of tofu and hit it to death ~

Iv. Final Research: Can gwes api be a solid foundation we need?
Can GWES APIs implement all the UI functions we need? No one knows. You need to evaluate it. I wrote these in the same article when I started the draft. I think it is better to separate the articles. After all, the topics are different. Please refer to the previous article: how to solve the technical difficulties in the GWES Solution

The so-called technical difficulties mentioned here are not worth mentioning. ButMicrosoftWe have set a set of game rules. We do not know this set of game rules, so it takes time to explore them.

1. animation effect of the BUTTON

We use the BUTTON class provided in GWES. the position in the wince product document is
Ms-help: // MS. WindowsCE.500/wceshellui5/html/wce50grfButtonReference.htm
The message WM_CTLCOLORBTN is mentioned in the Button Messages, but it is not as effective as expected after a simple trial. When I rummaging the image, I noticed that when eVC is drawing, right-click the BUTTON and open Properties. The Styles page in the box has a check box "Owner draw ", I grabbed the straw and GOOGLE, and the method came out.

When the Owner draw attribute is checked, the program will not run DefDlgProc to draw a gray highlighted effect and write the BUTTON name. Instead, it will give the BUTTON a parent window, that is, the PROC of DIALOG sends a message WM_DRAWITEM, And the lParam contains everything we need. Forced conversion
LPDRAWITEMSTRUCT lpDIS = (LPDRAWITEMSTRUCT) lParam;
Then, based on lpDIS-> itemAction and lpDIS-> itemState, determine the current status of the BUTTON to determine which image to load.

For more information about DRAWITEMSTRUCT, see ms-help: // MS. WindowsCE.500/wceshellui5/html/wce50lrfdrawitemstruct.htm.

I just tried it,
(1) During Initialization
ItemAction = 1; // ODA_DRAWENTIRE
ItemState = 16; // ODS_FOCUS
(2) When a BUTTON is pressed
ItemAction = 2; // ODA_Select
ItemState = 17; // ODS_FOCUS | ODS_SelectED
(3) When a BUTTON is clicked and released
ItemAction = 2; // ODA_Select
ItemState = 16; // ODS_FOCUS

ODA and ODS macro-defined values
/*** From Winuser. h ***/
# Define ODT_MENU 1
# Define ODT_LISTBOX 2
# Define ODT_COMBOBOX 3
# Define ODT_BUTTON 4
// Action
# Define ODA_DRAWENTIRE 0x0001
# Define ODA_Select 0x0002
# Define ODA_FOCUS 0x0004
// State
# Define ODS_SelectED 0x0001
# Define ODS_GRAYED 0x0002
# Define ODS_DISABLED 0x0004
# Define ODS_CHECKED 0x0008
# Define ODS_FOCUS 0x0010

Pay special attention to the following two items in WM_DRAWITEM:
(1) InvalidateRect (lpDIS-> hwndItem, lpDIS-> rcItem, NULL) cannot be used in it. This will immediately send a WM_DRAWITEM message, and then call InvalidateRect, enters the endless loop until the memory on the device is exhausted, causing the device to crash.
(2) When judging itemAction and itemState, You must judge both of them to determine the CLICK state. It is not enough to judge action or state separately, this will cause the re-painting to take effect when it is not desired. In addition, the bitwise AND judgment such as itemAction & ODA_Select must be exclusive. I simply use the = sign.

The reference code is as follows:

1 bool callback DialogProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
2 {
3 switch (uMsg)
4 {
5 case WM_DRAWITEM:
6 {
7 LPDRAWITEMSTRUCT lpDIS = (LPDRAWITEMSTRUCT) lParam;
8
9 if (lpDIS-> CtlID = IDC_BTN_1)
10 {
11
12 if (lpDIS-> itemAction & ODA_DRAWENTIRE) // This is the case during initialization
13 | (lpDIS-> itemAction = ODA_Select) & (lpDIS-> itemState = ODS_FOCUS) // This is the case when you release the SDK after pressing it.
14 {
15 // draw the image when it is not pressed
16}
17 else if (lpDIS-> itemAction & ODA_Select) & (lpDIS-> itemState = (ODS_FOCUS | ODS_SelectED) // when the data is pressed
18 {
19 // draw the image when it is pressed
20 MessageBeep (MB_ OK); // By The Way, it feels better
21}
22}
23 return TRUE;
24}
25 default:
26 // STUB
27 break;
28}
29
30 return FALSE;
31}

2. unit conversion between DLU and PIXEL

I thought it was OVER after the BUTTON effect was completed. As a result, this evening I encountered a very annoying problem. The XX * XX Unit shown in the lower right corner of the IDE is DLU (Dialog Unit ), this is changed based on the font size of the dialog box you set. This practice is understandable. If the font is changed to a larger value, the DIALOG and BUTTON are naturally "supported", which is more flexible. However, the image I added is calculated by PIXEL. Finally, there are two methods. According to international practice, it is of course the first stupid method, as is the style on MSDN.

(1) Method 1: I checked the Conversion Relationship Between DLU and PIXEL, there is a more comprehensive web page is http://support.microsoft.com/default.aspx? Scid = kb; en-us; 145994 (How to caculate dialog box units based on the current font in Visual C ++) according to the Method Two in this article, a simple test is performed.

1 bool callback DialogProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
2 {
3 switch (uMsg)
4 {
5 case WM_INITDIALOG:
6 {
7 RECT rc = {0, 0, 4, 8 };
8
9 MapDialogRect (hDlg, & rc );
10 printf ("baseUnitX = % ld \ n", rc. right );
11 printf ("baseUnitY = % ld \ n", rc. bottom );
12
13 // DLU_Weight = pixel_weight * 4/baseunitX;
14 // DLU_Height = pixel_height * 8/baseunitY;
15
16 return TRUE;
17}
18}
19
20 return FALSE;
21}

For the Courier New 10pt font set in my DIALOG,
Step 1: Obtain baseUnitX = 7, baseUnitY = 16 from the code,
Step 2: apply the formula
Weight_DLU = weight_pixel * 4/baseUnitX
Height_DLU = height_pixel * 8/baseUnitY
For example, if I want to create a 320*240 PIXEL dialog box
Weight_DLU = 320*4/7 = 182.86, rounded to 183
Height_DLU = 240*8/16 = 120
Step 3: drag the border of the dialog box to VC and draw a dialog box of 183*120. After the code runs, run GetClientRect to check it, indeed, the 320*240 pixel dialog box is displayed.

However, this method has a fatal disadvantage. For example, if I want to draw a 60*70 button and convert it to 34.28*35 According to baseUnitX and baseUnitY above, but when I draw 34*35 DLU, run to get 59*70 PIXEL windows; when 35*35 DLU is drawn, run to get 61*70 PIXEL windows, which cannot be exactly the right, resulting in a 60*70 pixel image stacked up, the button edge may contain discontinuous black spots. Therefore, this text can only be used as the Conversion Relationship Between DLU and PIXEL, without any practical application value.

(2) Method 2: the correct method
In fact, it is also very simple. After dinner, I suddenly thought of using SetWindowPos to forcibly set the length of the window and the coordinates in the upper left corner. I tried it in WM_DRAWITEM message processing:
SetWindowPos (lpDIS-> hwndItem, NULL, 10, 10, 60, 70, SWP_NOZORDER );
The button is 59*70 before the setting, and the button is 60*70 after the setting, and there is no problem in adding images. OK. The entire GWES-based UI solution has been developed. There seems to be no major technical barriers behind.

So far, I have not found any obstacles in the GWES solution. I can use this solution on the board. Compared with writing the UI with only GDI, the workload of software development has been reduced by about 30%. Of course, this process has not ended yet. This plan has a profound significance for my project team. Please refer to the following article: a small step in the code, project progressManagementA huge step forward

When I tried SetWindowPos successfully, I felt that this was a revolution for my application development team. Project Progress revolution.

According to the current schedule, the working status of each department after the business department releases the design requirements is as follows:
(1) for software development, first determine the underlying interfaces, such as which DeviceIoControl of BSP should be called, which protocol stacks should be used, which registry key values should be agreed, and inter-process communication between applications should be agreed.
(2) Industrial Design Center: design the UI image synchronously.
(3) test group. Start writing test cases synchronously.

Among the three, the industrial design center is the slowest, the interface style needs to be reviewed and modified multiple times, and the subjective factors are very strong. If the leader says it is hard to understand it, he must continue to change it, just adjust it for a day or two. Based on my experiences in several projects, it is often the first step for software developers and testers to complete the test. The industrial design center has not yet issued a cut chart, and then everyone will wait for resources. After the industrial design center officially released the cutting chart, software R & D began to work hard. At this time, the test group continued to be idle and the ALPHA edition began testing.

Taking my current project as an example, industrial design took two people a full month to complete the first-level interface and second-level interface, therefore, the application group also took a month to study and determine the underlying interface, and read the document slowly. In fact, if they are skilled in this field and the efficiency is high enough, these things can be done in at most two weeks.

If you use GWES APIs and SetWindowPos, the project progress advantages are obvious:
(1) Software Development: After determining the underlying interface, you can immediately create controls such as DIALOG, buttons, and EDITOR without worrying about the final design of the UI. Focus on the data structure and logic of the upper layer, and write code to call and test the underlying interface. The UI will no longer become a bottleneck, as long as you drag a few controls out, the coordinates and length and width are also random, as long as the function is done correctly.
(2) Industrial Design Center: images can be made slowly and reviewed in a round. Since the method of overlapping images is clear, andProgrammerWhen writing the drawing code, you can specify the coordinates and length and width at the same time to directly correct the messy interface during prototype development. Therefore, the cut chart can be released two or three days before beta release.
(3) test group: because software R & D can quickly release the ALPHA Edition program with ugly interfaces but good functions, the test group can start manual testing in advance. And start BUG feedback as soon as possible. Several bugs can be changed even before the UI image is displayed. The ALPHA version was completed before the UI image was taken out, and several rounds of bugs were changed. This was never imagined before. The Application Engineer would say: there are no images yet. How do I write code? If you write it in white, you need to change it anyway.
(4) After an image is published, each application can overlay the image for at most two days, and the code originally written does not need to be changed in the image overlay.
(2) because the code segment implemented by the function is not changed due to image superposition, all bugs tested earlier are still valid, and the possibility of high-level bugs caused by image superposition is very small.

OHYE, it's amazing.
Is it because I have never been so ignorant that other companies have already developed applications? The new words I created today are very suitable for describing the current mood: One hundred miles of tears. Go on ~ Hmm ~ Hmm ~ One hundred million ah one hundred million ~