Part II - Run "Hello Brew" on the simulator before you learn related knowledge points as this article: 1. Microsoft Visual C 6.0® (or later) 2. 1.1 version of Brew SDK. To understand the minimum requirements, and get more detailed information, SDK installation guidance, check the ReadMe file of SDK 1.1. Note that here I assume that you have read an article before this series, "What is Brew" and the previous article "Part 1 - Preliminary knowledge". I further assume that you have created a module information file (Hellobrew.mif) and a BREWX applet resource file (Hellobrew.bar) and copy them to "... YourBrewDir / Examples / MIF / 256Color /" and ". ..YourBrewDir / Examples / EN / 256COLOR / "Two directory. At the same time, in the "... YourBrewDir / Examples / Hellobrew /" directory must have the Hellobrew_res.h file generated by the BREW resource editor (Hellobrew.c) with the BREW Application Wizard. If you need to know more, you can read the first part mentioned above, or read the documentation included with the SDK. In this routine, you need to know that the file name is very important. Special, application directory and module information file (.mif) must be the same as the target .dll file name (the same is the same). Note that you can define the name of the .dll file by opening the Project Settings dialog (Select Project Menu> Settings). If you do it according to the first part, you should have a correct named file in the corresponding directory. Finally, remind it that the two words "applet" and "app" in this article will alternately use the same thing. Set Visual C in the first part, all must be managed by the BREW Application Wizard. But we still need to provide an executable to run the .dll file in the debug phase, but also make sure the BREW can find the application's .dll file. In order to meet the first requirements, we need to provide paths for BREW_EMULATOR.EXE. In order to meet the second request, we must ensure that the linker writes Hellobrew.dll in the root of the project (... / hellobrew /) instead of the default debug directory (... / hellobrew / debug /). Since the simulator is automatically looking for Hellobrew.dll in the directory called Hellobrew. Understanding Source Codes First, we will approach the source code generated by the application wizard in the Hellobrew project. If you haven't made this yet, use Visual C to open the Hellobrew project, then select FileView and expand the Source Files folder. You can see 3 source code files: aeeeppgen.c, aeemodgen.c, and Hellobrew.c. The first two files allow our applications to bind to the BREW's application execution environment (AEE). Aeemodgen.c Management Module, each module (module) basically includes more than one mutually-dependent small program (Applets).
When a terminal user activates an application, AEE creates a module, calling the aeeclscreateInstance () function that each application must provide by this module, and instantiate the application in turn. This allows us to start using the reason for the Application and Application (relatively loose). why? Because the applet can be understood as a container, he accommodates only the functions that the developer is interactive with the AEE and run on the device. For example, such a container can provide an interface to the Shell service and an interface to the device display. This way we can think that an app is a small program plus the development of any creation. In fact, if we use C principles in this example, hellobrew (the function created by developers) To inherit from BREEApplet structure, from this perspective, an application is a small program (IS A relationship ). AeeeAppgen.c provides a aeeepplet_new () function, Hellobrew will call this function to set the aeeeapplet section of the Hellobrew application. Soon we will discuss AeeClscreateInstance () and aeeeapplet_new () in more detail. Now we have a basic concept for these parts, now let us look at the frame code for the BREW application wizard. As for the header file of the include, you may have guessed, Aeemodgen contains a declaration of Aeemodgen.c, and AeeEappgen.h also declares aeeeappgen.c. Aeeshell.h provides a statement of the Shell interface API. If you want more to learn about this important interface, you can find iShell in the Brew API reference included in Brew SDK. Here we will not be in-depth research, add our own code to Hellobrew.c. Now, we skip the definition of Hellobrew_Handleevent () to see AeeClassCreateInstance () (may also be aeeclscreateinstance (), and translator's note). This function is where hellobrew is in contact with AEE. When the AEE passes a start-up request to the application, aeemodCreateInstance () defined in Aeemodgen.c calls the Applet type AeeClassCreateInstance () function. Because Brew is a single thread, no matter how many small programs in a module, only one applet is activated at the same time. By calling ishell_startapplet (), a small program can be started by another small program. In this case, the current small program is paused, and AeeClassCreateInstance () is called with the Class ID provided by iShell_StartApplet (). Obviously, AeeClassCreateInstance () requires the logical branch of each Class ID in the module. There is only one applet in our module, so AeeClassCreateInstance () only needs to process a Class ID. In the previous article, we remember to generate a Hellobrew's Class ID in the Hellobrew.mif file. The MIF editor creates a Hellobrew.bid file, where #define defines this Class ID as: aeeclsid_hellobrew.
Obviously, this module obtains a Class ID from the module information file (Hellobrew.mif) file and passes it as the first parameter to AeeClScreateInstance (). The second parameter, Pishell is an ISHELL pointer, which is provided by AEE when the module is first loaded. When calling aeeeapplet_new (), the M_Pishell member of the aeeeapplet structure must be set to Pishell. This iShell pointer provides access to all APIs for ISHELL interfaces. The third parameter, Po is a pointer to the Hellobrew module that will initialize the m_pimodule parameter of the AEEApplet structure when calling aeeeapplet_new (). Our code will not involve this pointer. The aeeeappletRelease () function defined in aeeeappgen.c requires this pointer to release the dynamically assigned module when hellobrew. Finally, PPOBJ is a pointer to the general pointer. Here is a void type **, because * PPOBJ can point to two things. Fortunately, we only need to relating to the Iapplet type object. If you are sparsely imposed on the usage of the pointer, you must use dual indirect addressing to ensure that when aeeepplet_new () returns * ppobj points to a valid Iapplet object. If PPOBJ is simply defined as Void * ppobj (ie, a single indirect addressing), PPOBJ will not change when aeeeapplet_new () is returned. The parameter transfer mechanism of the C language will only pass a simple copy of the PPOBJ pointer to the aeeeapplet_new () without changing the original value in the aeeclscreateInstance (). Since we want aeeeapplet_new () to modify the same pointer referenced in aeeclscreateInstance (), we can only transfer value ginseng, not a ginseng. The second parameter passed to the aeeeapplet_new () function is a pointer to our application event handle. This function is called when AEE receives an event to Hellobrew's event. If the last parameter is non-empty, we need to pass the pointer to a function that releases dynamic allocation data when the application is terminated. This pfnfreeappdata is a function pointer, which receives the parameters of the Iapplet * type, returns Void. For demonstration, we will join such a function in Hellobrew. We look at the Hellobrew_HandleEvent () framework code. The first parameter points to the Iapplet instance. In this function, PI will be used to access the M_Pishell and M_PIDisplay data of the applet. When we add your own code to Hellobrew, we will discuss this in more detail. The second parameter, ecode, like its name, refers to event code for discovering what action leads to the Hellobrew_HandleEvent () call. The last two parameters include data of the event type. A complete, detailed event list can be found in the header file aee.h, as well as a description of the data provided by event type parameters WPARAM and DWPARAM. In the SDK User Guide of BREW, you can find more readable event lists, including different button events and key codes, and instructions for WPARAM and DWPARAM events. Adding Source Codes Now let's join our own code in Hellobrew. You can see a simple version of "Hello" in HelloWorld.c under "... YourBrewDir / Examples / HelloWorld /".
In order to prevent repetition and let our example more interesting, we will create our own small program data structure, provide initAppdata () and FreeAppdata () functions, and load strings from resource files (Hellobrew.bar reference first partial preparation knowledge) and use Brew's ISTATIC controller displays them. We need to add aeestdlib.h in the list of Include's header files. This header includes malloc () and free (), as well as the Helper function mentioned in the BREW API reference. Our application needs to be able to access the Class ID in Hellobrew.BID and the string ID in Hellobrew_rew.h. Note that it is very important to have any static (global) data in an application. Therefore, our application data structure is defined as a global data structure (Struct, at least the C program is like this). And we let AeeClscreateInstance () to manage instances in the stack. This further brings another very important point of attention: the stack space on the device is very limited. For example, Kyocera QCP3035E has only 500 bytes of available stack space. Obviously, you need to use the stack as possible, in order to achieve this, you can minimize the levels of the function call, try to assign non-working (divided, translatable) local variables to the pile, and When the data that needs to be transmitted is greater than 4, it is used to use the pointer. The application data structure provides a container for loading everything that programmers need to maintain in the life cycle of the entire application. This includes the application's aeeapplet section where you can access the shell, display, and maintenance module pointers. The aeeeapplet must be the first member of this data structure, which is mandatory. Another member of this data structure is a pointer to the ISTATIC controller for displaying the string we define. The first is also the most important, we modified the first parameter that passed into aeeeappletnew (). In addition to the space required for the Hellobrew's aeeapplet section, we also need to use aeeeapplet_new () to allocate space for the apparatus of the applet. To achieve this, we pass SIZEOF (HB_APP) to aeeeApplet_new () as the first parameter, not the original sizeof (aeeepplet). In the second step, in order to add a FreeAppData () function in Hellobrew, we need to pass a pointer (HB_FreeAppData ()) as the last parameter to aeeeapplet_new (). This function will be registered in AEE and automatically calls when the application terminates. Figure 9 shows the definition of HB_FreeAppData (). As you can see, the basic task of this function is to call iStatic_Release () to release the ISTATIC controller. AeeClscreateInstance () final change is to call HB_initAppdata (), here, iStatic * members in our small program data structure are initialized to NULL.
In HellobrewHandleevent (), the initial code generated by the BREW Application Wizard is a large number of modifications. At the top, we define a pointer to our small program data structure, and assign the first parameter, Iapplet * of this function to this pointer. In the entire event handle, this pointer is used to access the M_Pishell member of the aeeeapplet section in Hellobrew, which also provides access to the M_Pistat pointer to us to represent the iStatic controller. At the beginning of EVT_APP_START, the first local variable we defined is a AeedEviceInfo type variable. This structure includes a member variable that holds the device screen size and color depth. More detailed data Members Introduction can be found in the BREW API reference last data structure (data type, translator's note) chapter. I remember that I will remind us to minimize the use of stack space, we should allocate memory for this structure and define a pointer to monitor it. Since this applet does not need to worry about the risk of stack space, I will define this structure as a local variable for a simple reason. Next, we see a simple rectangular object (AEEREC), we used to determine the size and position of the static controller, and determine several caches to save the title and text of m_pistat, respectively. AECHAR is the type definition of UINT16 (refer to aee.h), and the uint16 is a type definition of unsigned short integer (refer to AeeComDef.h). Such aECHAR can be used to store Unicode or become a wide character set (Wide Characters) type variable. Thus, WBUFTTL and WBUFTXT points to a string that consists of characters in the wide character set. Refer to the Helper function sections in the BREW API to learn the tools for manipulating a wide character set string. After verifying the validity of M_PisHell, we can invoke to Di assignment. Next, the size of the screen is used to set a rectangular object with a static controller, a rectangular object with a static controller. In the screen coordinate system, the origin is the upper left corner of the display, and when we move to the right, the x coordinate is increased, and the y coordinate is increased down. Specify aeeclsid_static to request the Class ID of the request interface when calling iShell_createInstance (). Assumptions are successful, and M_Pistat will point to a valid iStatic when the function call returns. The Class ID of the other interface can be found in aeeClassIDS.H. After creating iStatic, we call iStatic_seTRect () to set its rectangle, pass the pointer to the rectangular structure that is initially initialized to him. After allocating memory for the previously defined buffer (WBUFTTL, WBUFTXT), we call iShell_loadresstring () twice: once is the title for ISTATIC, once is text. These two buffers submitted the title and text to iStatic_setText (). IStatic_SetProperties () is used to define the location of the title and text and call the istatic_redraw () to display a static controller on the screen. Refer to the ISTATIC section in the BREW API Reference You can learn more about these functions. Note that BREW cannot tolerate memory leaks. Therefore, you need to be sure that all calls to free () correspond to the call of malloc (), and the call to i * _Release () corresponds to the call of ISHELL_CREATEINSTANCE (). At the bottom release of EVT_APP_START (Free ()) used two buffers.
