Get a first impression Embedded Wizard studio provides a powerful integrated development environment permitting you to simply design test and customize your GUI application. The workflow is based on the idea of visually aided programming where software entities are arranged and connected with a mouse by dragging and dropping them. From our point of view it was self-evident to combine visual programming and the GUI application development.
Both concepts complement each other in this manner you compose bigger perience of an application and implement its complete functionality no further development hoods are needed. So let's continue with the quick tour. In the middle area of embedded wizard you see the so-called composer.
This is the main editor of Embedded Wizard. Within the composer you see many grey rectangles; the small rectangles are called 'Bricks'; every brick represents an individual member within the project. The shape of the brick, its icon, and the text at its upper edge describes the exact function of this brick.
For example, the brick named Win32 represents the profile number - a number needed to configure general project and target-specific parameters. The large gray rectangles are called 'annotations', they have no real function in the application. They exist only to leave comments or to group bricks together visually - so don't worry about them too much.
Depending on the type, the bricks contain diverse attributes and properties, these appear in the inspector window on the right-hand side of the composer after the affected brick has been selected. For this purpose, just single-click on the brick Win32 to select it. Now you can see its attributes in the inspector.
The profile brick Win32 exposes the attributes Platform package, screen size and others as you see the attribute Platform package is actually configured with a value tara Win32 RGBA 8 8 8 8. This means that by using this profile the embedded Wizard studio will generate a code optimized for Microsoft Windows operating systems with RGBA 8 8 8 8 as a native Color format for all images. Selecting other value on this attribute will allow you to generate code for other target systems or color formats.
The attribute's screen size -as it implies- determines the desired target display resolution, in our example 480 by to 72 pixels. In the case of Windows as a target system this gives a hint about the dimension of the window when the application is running. If you intend to create an application for example for RSP PI you will configure this attribute to correspond to the native resolution of the display of your target system.
Depending on the type of project member, the corresponding brick may contain further embedded members. You can show them by simply double-clicking on the member - similarly to how you would open a folder in the Windows File Explorer. Please take a look at the brick named application.
Bricks of this type represent the so-called units. A unit is a container where you put your dedicated implementation - it's similar to a namespace in C++. Now double-click on the brick application to show its content that's the content enclosed within the unit application is shown in a new composer page.
During the work with Embedded Wizard, you will often switch between various composer pages. All open pages are listed as tabs in the Navigation bar of the upper edge of the composer. Now you can see that a presenting the main composer of the project and another associated to the just opened application unit.
Within the unit all enclosed members are similarly represented by bricks. As you can see many of them have different icons and names. Please note the bricks with pointed edges.
Such bricks represent data entities - they store information. For example, the brick BackgroundBeans serves as a bitmap resource. It contains an image.
The brick BackgroundBeans. Thereupon the Inspector shows its associated attributes. Among the various attributes of the just selected brick please also note the attribute FileName.
This attribute addresses the image file to associate with this bitmap resource. When generating source code, Embedded Wizard converts this image file into a format that is appropriate for your target system. This usually includes the color reduction and compression.
Later, when you want to display the image you simply refer to the member BackgroundBeans. Now, click on the brick SmallFont to select it. It represents a font resource as you see in the Inspector, the font resource is configured with the font name "Asap Condensed Medium" and the font size of 29 pixels.
So, when generating source code Embedded Wizard will automatically convert the specified font in a format that is appropriate for your target system. This usually includes the rasterization and compression of all effected font glyphs. Later, when you want to display text with this font you can simply refer to the member SmallFont.
Besides, the above-mentioned bitmap and font resources, you can see the unit containing of you ever bricks. Let's take a look at the three bricks group together below the annotation Configuration objects. These bricks represent the so-called autoobjects.
Such global objects contain various settings that are important for the GUI application. Because an object is a data entity, the bricks are also shown with pointed edges now as I like the brick push-button conflict the inspector shows the properties of the object in the upper text row of the selected brick you see the expression "WidgetsSet::PushButtonConfig" This expression identifies a class from which this object is instantiated. The particular origin of the object is also reflected in its icon, here you see a small button with an associated gearwheel as a symbol for configuration.
Embedded Wizard follows an object-oriented approach to structure and implement GUI applications - this implies that when developing a Geo hire application you need to create and implement classes. Objects are instances of the corresponding classes. The just mentioned autoobjects are nothing else than global instance you can access from everywhere in your project a class in turn can implement either visual GUI component (like the push button) or a non-visual component (like the configuration object).
The class widgets set push button config implements such non-visual configuration component please note the four properties "FaceActive", "FaceDefault", "FaceDisabled" and "FaceFocused". They determine the bitmap resources to be displayed in push buttons using this configuration object; in other words when you connect a push-button with a configuration object "PushButtonConfig", the push button will use the specified bitmap resources for its appearance. Now, you might want to know where the class "WidgetsSet::PushButtonConfig" comes from.
And where the push button components are implemented? Well, all these classes are part of the so-called "Mosaic" framework - a component library which serves as a basement for every GUI application created with Embedded Wizard. If you recall the content of the first Composer just as we started, there you will find an annotation "Mosaic Framework" grouping 7 unit bricks.
These units contain the implementation of the mosaic framework. In particular, the unit "WidgetSet" implement all widgets (including the push button component) as well as the associated configuration objects. Every unit, by the way, serves as a namespace for its enclosed members.
This helps to avoid eventually name conflicts with members existing in other units. For example, the class name "WidgetsSet::PushButtonConfig" addresses the class push button config within the unit "WidgetSet". As such, it does not interfere with the identically named autoobject "PushButtonConfig" existing within the unit "Application".
Both coexist within the same project. Next to that, you see within the unit "Application" many other bricks. The bricks here, for example, contain the implementation of the interface between the GUI and the real device.
In other words, the bricks take care of the communication with the device. In our Quick Tour project, the interface is limited to start and stop the device and to query its actual status. The exact implementation of these bricks is not important at this moment.
We will learn more about it later. Much more interesting at this moment are the bricks grouped together below the annotation GUI component. These three bricks are classes which implement visual "GUI components", for example, the brick "SelectionDialog" implements a screen (we call it "dialog") where the user can select the desired strength of the coffee.
The brick "BrewingDialog" and turn implements a dialog showing the progress of the brewing process. Usually, when developing a new GUI application, you will first identify the components needed to assemble it. You will list all the dialogs or screens, the user may interact with, as well as any other sub ordinated widgets the application should contain (for example a push-button, slider or a progress bar).
Then, in the second step, you will implement every identified component as an individual class. Click on the brick "SelectionDialog". As in previous cases, the attributes of the selected bricks are shown in the Inspector window.
Most especially, take note of the attribute "SuperClass" of the just selected brick. It is actually initialized with the expression "Core::Group" By the way, the same value is also displayed in the upper text row of the brick. This expression indicates of the class "SelectionDialog" is derived from another class "Core::Group".
This "super class" in turn, is implemented in the Mosaic framework which we have explained just before. The class "Core::Group" implements a lot of common functionality needed by almost every GUI component. It takes care of screen updates and dispatches, incoming user input events, received for example from a touch screen or keyboard.
By deriving from it, the class "SelectionDialog" inherits all this functionality implicitly. it is not necessary to re-implement this functionality again. In the derived class, you just add new contents specific to this component.
This is one of the advantages of the object- oriented approach. Now let's double click on the brick "SelectionDialog" to show its contents: the content of the class "SelectionDialog" appears in a new Composer page. This Composer, however, is different.
In the top left corner, you see an area surrounded by a thick blue border. This area is called "Canvas". What you see within this area will also be visible on the display of your target device.
The Canvas area is available only on the currently edited class represents a visual GUI component. In our tutorial example, this GUI component permits the user to select the desired coffee strength and to start the brewing process. Typically, a complex UI projects will consist of many different GUI components which - depending on the user interaction - appear and disappear on the display.
The "SelectionDialog" component implements just one of the GUI components. Now please take a look at the Inspector window. In its upper area, you see a list of members.
Ass you have probably noticed this list always corresponds to what you see in the composer. When working with Embedded Wizard you can select the members either in Composer or in the Inspector. Both work coupled together.
Within this list, you can also rename the members or rearrange their order, if necessary. Here, however, the Inspector lists much more members than shown in a Composer. In the Composer you only see some visual members within the Canvas area and a few bricks, nothing else.
The Inspector, in turn, lists 100 members. You can see this here in the Inspector's column order. The difference roots in the object-oriented character of Embedded Wizard.
In this particular case the actually edited class derives from the superclass "Core::Group". As explained before, the derived class inherits all the functionality of its parent class and also of all higher super classes. Displaying all those inherit members in the Composer would quickly become confusing.
Therefore, when you edit a class, the Composer conceals implicitly the bricks for members which are defined in the ancestor classes but not overridden in the actual class. In other words, the Composer shows only those bricks which are added or modified in the actual class and hides all other inherited and not overridden bricks. The Inspector, in turn, always displays all members - those which are inherited appear in the Inspector and gray color.
New members added to the actually edited class appear black. In this manner, you can easily recognise the origin of a member.
