Release notes: Embedded Wizard 12
Version 12 contains the following changes and improvements:
Support for blur, mask and tint filter effects
The Graphics Engine has been enhanced by new filter effects supporting blur, mask and color tint operations on bitmaps or screen contents. The following figure demonstrates few application cases for the new filter effects: grayscale, blur, mask an image as well as display a shadow effect based on the opacity information of the original image:
For your convenience the corresponding functionality is exposed through three new Mosaic views:
•The view Filter Image (Mosaic class Views::FilterImage) is a view specialized to perform visual filter operations on an image content provided in a bitmap.
•The class Filter Group (Mosaic class Views::FilterGroup) is a view specialized to perform visual filter operations on an image content of a GUI component.
•The class Filter Screen (Mosaic class Views::FilterScreen) provides a kind of view specialized to perform visual filter operations on the screen contents lying behind this view's area.
All three views implement following filter operations. Multiple filter operations can be combined together to create more sophisticated effects:
•Mask filter: during the filter operation is performed, the pixel found in a mask bitmap are used to modulate the opacity of the pixel involved in or resulting from the filter operation. The mask can thus be used to clip the image contents by any non-rectangular shape. The mask effect can additionally be inverted.
•Blur filter: with blur radius in range 1 .. 64. If Blur is used together with Mask filter, the order in which blur and mask operations are performed is significant. Per default the mask affects the pixel after the preceding blur filter operation is done. This order can be configured explicitly to perform mask before blur operation.
•Color modulation by opacity: The opacity resulting from the image content (and any preceding mask or blur operations) is used to modulate a color value. Then this new color value is used instead of the original color information.
•Color modulation by luminance: The luminance resulting from the image content (and any preceding mask or blur operations) is used to modulate a color value. Then this new color value is used instead of the original color information.
•Converting RGB colors to gray-scale values: The original RGB colors resulting from the image content content (and any preceding mask or blur operations) are converted to gray-scale values according to their luminance. The opacity information is taken over without any modifications. This new color value is mixed then with the original color information by a configurable mix-factor.
•Modulating Opacity: The opacity of the final pixel can additionally be modulated by a configured value. In this way, the final effect of the filter can be faded-in/out.
To add objects of the new classes at the design time of your GUI component, the Gallery folder Views has been enhanced by following new templates:
Support for new bitmap vector graphic objects
The Mosaic framework has been enhanced by two new classes Graphics::FillPath and Graphics::StrokePath. Objects of these classes allow the user to store the results of a vector graphic operation directly within an ALPHA8 bitmap. The objects can thereupon be used as ordinary bitmaps and, for example, act as masks in the above explained filter views. The mask is rendered dynamically at the runtime in such case.
The following figure demonstrates an application case of the Filled Path Bitmap to dynamically render a mask bitmap, which then is used in the above explained Filter Image view:
In order to add objects of the new classes during the design time in Composer window, the Templates Gallery folder Resources has been enhanced by the corresponding templates. For more details see also Filled Path Bitmap and Stroked Path Bitmap.
Integration of Extern Video within Mosaic
The Mosaic framework has been enhanced by a new class Resources::ExternVideo. Analog to Resources::ExternBitmap, this class permits the user the integratation of an external video decoder within the GUI application. Objects of the Resources::ExternVideo class can then be used as any other regular bitmaps. They can, for example, be assigned to an Image view, which then will play back the video.
In order to add a new object of the Resources::ExternVideo class, the Templates Gallery folder Resources has been enhanced by the corresponding template:
Please note, the new extern video class depends on a video decoder implementation which of course is specific for each target and pixel format. It is thus up to you to provide this loader implementation for your particular target system. You will need to implement a set of 'C' functions and link them with the generated GUI application code. For more details see the documentation of the Mosaic class Resources::ExternVideo. Also please note that the support for the extern video decoding is actually not available for the WebGL platforms.
Improvement of Mosaic list views to support flexible items
•The class Core::VerticalList has been enhanced by the properties OnQueryItemHeight and OnQueryItemClass. See also Specify the height of an item within the list and Specify the class of the items within the list.
•The class Core::HorizontalList has been enhanced by the properties OnQueryItemWidth and OnQueryItemClass. See also Specify the width of an item within the list and Specify the class of the items within the list.
By using the new properties, the lists can query the size and the class of each item permitting the user the creation of flexible lists. The previous restriction of lists to allow only equally sized items and all items having the same class is obsolete. Please note, using the new functionality will produce more overhead. For example, the position calculation of an item requires now the list to query the size of all preceding items.
Improvement of Mosaic Text views
•The Mosaic definition Views::TextAlignment has been enhanced by a new item AlignVertCenterBaseline. Using this alignment mode, the text is aligned with its baseline in the center of the Text view.
•The class Views::Text has been adapted to adjust the text position accordingly when AlignVertCenterBaseline is used.
•The class Views::AttrText has been adapted to ignore the new item AlignVertCenterBaseline as well as the already existing AlignHorzJustified which also has no effect in attributed text view.
•The behavior of the property Alignment in the class Views::Text has been reworked. Now the alignment options AlignVertCenter or AlignVertCenterBaseline can be combined with AlignVertTop or AlignVertBottom. As long as the text is small enough to fit within the views boundary area, the text is centered vertically. When the text is too large, the top or bottom alignment will override the center alignment. The text stays then aligned at the top or bottom edges automatically. See also Align the text within the Text view area.
•Similar happens with horizontal alignment. The AlignHorzCenter option can be combined now with AlignHorzLeft, AlignHorzRight or AlignHorzAuto. Again, as long as the text is small enough, the text is horizontally centered. When the text is too large, it will be aligned at the corresponding left or right edge. See also Align the text within the Text view area.
•This changed alignment behavior affects also the behavior of the Ellipsis property. For example, to ensure that the ellipsis does appear at the bottom end of the text, even when the view is configured to vertically center the text, it is just sufficient to enable the AlignVertTop option together with AlignVertCenter option. See also Truncate text with ellipsis.
Improvement of Mosaic Outline Box view
•The class Core::Outline has been enhanced by new property WrapSize to control the row/column wrap. See also Use Outline Box to arrange the views in rows and columns.
•The class Core::Outline has been enhanced by the properties Padding, PaddingLeft, PaddingTop, PaddingRight and PaddingBottom. Configuring the properties with value > 0 (zero), adds a gap at the corresponding edge. In case of the property Padding, the gap is added to all four edges. This gap is taken in account when scrolling the Outline Box content. It is assumed as part of the content. See also Specify padding around the content of the Outline Box.
•If the Outline Box is configured to automatically wrap the views in rows and/or columns, the specified padding reduces the available wrap space unless the space has been specified explicitly in the property WrapSize.
New Chora built-in variable
Chora has been enhanced by a new built-in variable rootthis. This variable represents the application component and its usage is more flexible and convenient than the invocation of the method GetRoot. Following rules are valid:
1.rootthis has the data type Core::Root. To access members implemented in derived classes, explicit type cast is needed.
2.rootthis is null until the root object has finalized the initialization code implemented in Core::Root class.
3.When the root object is about to be disposed, the rootthis is set immediately to null.
4.If there are more root objects created, rootthis refers the recently created one.
5.During prototyping of a class not descending from Core::Root, rootthis represents the prototyper's own root object.
6.During prototyping of a class descending from Core::Root, rootthis represents the just tested object.
7.The keyword rootthis is reserved in Chora. Using it for local variables or project members is not allowed anymore.
New Chora preprocessor test operators
The $if/$elseif directive has been enhanced by following new conditions:
•is_intrinsic<intrinsic-name> : results in true if the given intrinsic does exist. Otherwise it results in false. See also Test operator is_intrinsic().
•is_member<unit> [ ::<unit-member> [ .<member> ]] : results in true if the given project member does exist. Otherwise it results in false. See also Test operator is_member().
General workflow improvements
★In order to avoid version mismatch with projects modified simultanously by a user (when the user opened the project in two Embeded Wizard Studios), new functionality has been added to prevent one and the same project from being opened twice by one and the same user. Multiple, separate users can of course open the same project.
★Automatic recovery backups of project contents instead of the periodic save operation.
•Recent project and unit modifications are stored automatically in so-called recovery files.
•The recovery files are stored in a separate folder below user's AppData\Local\Embedded Wizard directory.
•If several users are working on the same project, the recovery files for all users are managed individually.
•When closing or storing the project regularly, the recovery files are deleted again.
•If Embedded Wizard Studio is crashed or Windows session is terminated, the recovery files are not deleted.
•When opening a project and there are recovery files found, the recovery files can be used. Embedded wizard asks the user how to proceed in such case.
•The recovery files are updated approx. every 60 seconds and at the end of the Windows session.
•The menu Item is removed. It is not necessary to control the auto save operation by the user anymore.
★Improvement of the Open an example project dialog. The dialog has been enhanced by a Search ... edit field. The text entered in the edit field acts as filter for the list containing the examples. To match the filter condition, the text entered in the edit field is searched in the name and description of the example.
★Improvement of the Create new project dialog. The dialog has been enhanced by a Search ... edit field. The text entered in the edit field acts as filter for the list containing the project configurations. To match the filter condition, the text entered in the edit field is searched in the name and description of the configuration.
★Modification of the Create new project dialog to behave more like a project wizard. Now the dialog allows the user the selection of the desired configuration. This can be a configuration optimized for a particular discovery/evaluation board or a generic configuration for user's own custom hardware. Once the configuration is selected the user can adapt the values for the color format, screen size, bitmap/string mode, etc. directly in the dialog. The so created project is already the right starting point for the user's new project.
★Improvement for drag & drop operations. Originally the drag & drop operation accepted *.EWP files within the Composer area only. The implementation has been adapted to support all windows belonging to Embedded Wizard Studio. Additional verification added to prevent reloading the actually opened project when the user drag & drops the same file twice.
★Highlighting of items within the Gallery window Templates when the mouse hovers over the item has been added. Additionally, the Tool-Tip text is modified when the the mouse pointer hovers over an actually not available Gallery item. The text informs the user, why the item is actually not available (grayed-out).
★Better support for multiple developers working on the same project. In order to simplify the merging of project changes in teams of multiple developers working on the same project, the storage of Embedded Wizard unit files has been modified so that:
1.The order of members within the unit file *.EWU and within a class is not changed when the user reorders the members in Studio.
2.New added members are arranged consequently behind the originally loaded project members.
3.The expected order of members is listed explicitly at the end of the *.EWU file or at the end of a class. It is a kind of index.
Support for Microsoft Windows operating system as target
Originally Embedded Wizard was delivered with a Platform Package Tara.Win32. This has been replaced by Windows.Software Platform Package. Additionally, a dedicated Build Environment has been created, permitting the user to create Embedded Wizard GUI applications as Win32 executables for the Microsoft Windows system. For more details see the chapter Getting Started with Win32.
Support for integration with a complex text layout shaping engine
Originally, when rendering text, the Graphics Engine processed the characters isolated one by one. The result of this evaluation was always one glyph-id for one character (Unicode code point). There are however many scripts expecting the processing in clusters (e.g. Devanagari or Thai). In such case several characters are evaluated as an indivisible unit and the result of this evaluation is one or more glyph-ids. The Graphics Engine can thereupon calculate with the size of the glyphs and render them.
To allow the integration of such complex text layout processing, the interface between the Graphics Engine and the Font Engine has been enhanced by functions to process clusters. The functions are invoked with an array of character codes, and after evaluating these codes, the functions return an array of glyph-ids for the corresponding output.
All Graphics Engine functions responsible for processing and calculating with text have been adapted to use the new functions instead of directly processing the glyphs one by one. This new functionality permits the integration of Embedded Wizard's Graphics Engine with an external shaping engine. The interfaces between Graphics Engine and the Font Loader have been adapted to access glyphs by glyph-id and to support conversion from Unicode code point to a glyph-id.
This enhancement has an experimental status.
Communication between threads and tasks
Runtime Environment has been enhanced by new functions EwInvoke and EwInvokeCopy. These functions register user's own implemented C functions to be called in context of GUI thread/task. The functions EwInvoke and EwInvokeCopy themselves are explicitly allowed to be called from any foreign thread or even from interrupt service routines.
The difference between the both functions is: EwInvoke passes the data parameter directly to the invoked user function. The user has to take care that the parameter is still valid when the user functions is invoked later. EwInvokeCopy copies the associated data on the internal queue. The user does not need to take care of the memory management. However, the internal queue has to be large enough.
To configure the queue new macro is available: EW_INVOCATION_QUEUE_SIZE. If you are using one of our prepared Build Environments you can configure this macro conveniently in the file ewconfig.h. The debugging function EwPrintProfilerStatistics has been enhanced to display the recent and the max. usage of the invocation queue.
Multi-Thread, Multi-Task check functionality
All relevant top-level Runtime Environment and Graphics Engine functions perform now a test whether the function is called in context of the original GUI thread/task. For this purpose the test compares the current CPU stack address with the address area known as used for GUI thread/task stack. If the test fails, an error is reported. This helps to detect errors in applications running multiple threads/tasks.
The stack memory area has to be provided to Embedded Wizard application by using the function EwSetStackAddressArea. This function replaces the old EwSetStackBaseAddress function.
The test functionality is per defaults enabled, to disable the functionality, compile Runtime Environment and Graphics Engine with the macro EW_DONT_CHECK_THREAD_CONTEXT. This saves ROM memory and also a little bit the performance. Usually you disable the functionality if there is no operating system in your target device. If you are using one of our prepared Build Environments you can configure this macro conveniently in the file ewconfig.h.
Other improvements
★Assignment between constants. Not multi-lingual nor multi-variant constants can now be used in the initialization expressions of another constants. In case of the constant initialization expression being a multi-lingual or multi-variant constant, a more descriptive error message is reported now.
★Enhancement of the Graphics Engine to allow the creation of bitmaps from externally existing surface (e.g. textures). Graphics Engine has been enhanced by the possibility to manage bitmaps wrapping image contents created externally. This is especially intended for textures created in an OpenGL target system by a foreign code (e.g. video decoder) and used within the EmWi application.
★Change of the original ScreenSize attribute limitation. The profile attribute ScreenSize was limited to be at least 128x64 pixel. This might prevent users from being able to create GUI projects for very small LCDs. The restriction has been changed to 32x32 pixel.
★New warning when the size of the original image file used by a multi-frame bitmap resource is not exactly a multiple of a single frame. If bitmap resource is configured as multi-frame, the conversion calculates with a multiple of a single frame size. It divides the original image in tiles accordingly to the specified FrameSize attribute. Was the size of the original image not a multiple of a tile, the not fitting areas were ignored. To avoid this situation a new warning has been added which is reported when the size of an image is not a multiple of the specified frame size.
★Avoid full screen update in WebGL. When running a GUI application in the WebGL capable browser the entire screen was completely redrawn during the screen update. Now, only the affected area is redrawn, which results in much better performance. The original behavior existed for compatibility reasons with older browsers. If necessary, the user can enforce the full screen update again. For this purpose the generated *.html file has been enhanced by setting parameter FullScreenUpdate. See the inline description in the generated *.html file.
★Default color channel order in compressed bitmap resources. Originally bitmap resources, when they were stored in compressed format, followed the channel order ABGR. Since most common order is ARGB, the conversion and the loading (decompression) of the bitmap resources have been modified to avoid thechannel reordering.
★Graphics Engine has been enhanced by the function EwGetGraphicsEngineInfo and the corresponding data structure XGraphicsEngineInfo. Runtime Environment has been enhanced by the function EwGetRuntimeEnvironmentInfo and the corresponding XRuntimeEnvironmentInfo data structure. These functions are useful to query most essential parameters of the Graphics Engine and Runtime Environment. For more details see the header files ewgfx.h and ewrte.h. The functions are also available in the Intrinsic Modules. The intrinsic version of ewgfx.h and ewgfx.c has been adapted to use the XGraphicsEngineInfo for Graphics Engine macros to query and handle the color format related parameters, like the position of color channels. The user can so more flexibly implement code for target and intrinsic modules.
★The touch handler classes Core::SimpleTouchHandler, Core::RotateTouchHandler, Core::WipeTouchHandler and Core::SlideTouchHandler have been improved to better detect and redirect single, short taps if the affected touch handler has been configured to process multi-touch gestures. The resolution of the hold timer has been increased to 10 ms. The resolution is essential to better distinguish multi-touch finger gestures. Previously the resolution was 50 ms.
★Following Platform Package names have been adapted:
•The Platform Package Tara.Win32 has been renamed to Windows.Software.
•The Platform Package Tara.WebGL has been renamed to Web.WebGL.
•The Platform Package Apple.iOS has been renamed to iOS.OpenGL.
•The Platform Package Apple.OSX has been renamed to macOS.OpenGL.
★Automatic upload of DUMP files. When Embedded Wizard Studio crashes due to an unrecoverable error, a DUMP file is created. Originally the user had to send the file to us. Now, Embedded Wizard Studio asks the user whether it should take care of sending the file automatically. Siehe auch Upload Dump Files Dialog.
★Automatic setup update notification. Embedded Wizard Studio has been enhanced to automatically notify the user when relevant updates are available. The necessary information is obtained from our download center server. If new version is available, Embedded Wizard Studio displays a dialog window with a link to further release notes. From there the user can download the updated files.
★Better support for users of the CHORAC command line compiler.
•CHORAC.EXE has been enhanced by new parameter -licensekey <key> and -userinfo <info>. These parameter permit the user to specify the license key and user info directly when invoking CHORAC. The license activation via Embedded Wizard Studio can be omitted what is convenient for configurations using CHORAC only. See also: Activate the license for CHORAC command line compiler.
•CHORAC.EXE has been enhanced by new parameter -proxy <server>:<port>. This parameter permits the user to specify the proxy server directly when invoking CHORAC. The proxy configuration via Embedded Wizard Studio can be omitted what is convenient when using CHORAC only. See also: Activate the license for CHORAC command line compiler.
★The size of a font resource when generating code for WebGL platform was limited to 2 MByte for the compressed pixel data. The limitation has been elevated now allowing fonts with up to 2^28 bit compressed data (268 MBit or 32 MByte).
★New version numbering scheme:
•Embedded Wizard Studio: From version 12, the version numbers are composed consequently from two parts: the generation number and the update number: GG.UU. The GG number will increase when a new version with new features is released. The UU version increases as bug fixes, minor improvements, or support for additional platforms are released.
•Build Environments: Starting with version 12, the version numbers are made up of four parts: GG.XX.YY.ZZ. The generation number GG corresponds to Embedded Wizard Studio. The second part XX identifies the version of the Graphics Engine (GFX) and Runtime Environmnet (RTE). The third part YY identifies the libraries or the source code of the Platform Package used. Finally, the fourth part ZZ identifies the version of the Build Environment itself. In case of bug-fixes or SDK updates within a dedicated Build Environment, only the last digits ZZ change.
★Merging all Platform Package setups within Embedded Wizard main setup. Originally the user had to install different setups for each target system. Now to simplify the deployment, all Platform Package files are already contained within the main Embedded Wizard setup. This setup contains thus all actually existing Platform Packages as well as the Embedded Wizard itself. No separate Platform Package setups need to be installed.
★Improvement of the SDK used by Prototyper Intrinsics.
•Intrinsic modules, if they are depending on Graphics Engine functions (e.g. EwCreateBitmap), are difficult to implement. The functions need to be imported one by one from the Graphics Engine Intrinsic module to the user's own Intrinsic module. To simplify this process, the most important and officially documented Graphics Engine functions are now directly available in Intrinsic modules by default.
•Similarly, Runtime Environment functions relevant for the development of Intrinsic modules and officially documented are now available by default in user's own Intrinsic modules.
•All header files and the ewrte.c needed to implement an Intrinsic module are found now in the folder SDK\Intrinsics just below the installtion directory of your Embedded Wizard Studio.
•New file ewgfx.c is available in the folder SDK\Intrinsics.
IMPORTANT
If you have implemented your own Intrinsic modules, you will eventually need to adapt the implementation. In particular adapt the include directories to refer to the folder SDK\Intrinsics and add the files ewrte.c and ewgfx.c from the same folder. See the chapter Create a new Visual Studio project for more details.
★Log window has been modified to according to the content of an error better associate it to the category Main or Debug.
Bug Fixes
★Update component templates. The Vertical Slider component template moved in the opposite direction. This means, the min. value was found at its upper edge instead of the lower edge. The Value Bar component templates had no status variables to store the latest position.
★Review Win32 (Windows) Platform Package ewconfig.h. The config.h file specified in case of Win32 Platform Package per default 100 instruction tasks only. This could lead to runtime errors because of the issue buffer being too small for vector graphic operations.
★Embedded Wizard setup verified to allow Windows 8 or newer only.
★State values FrameSize, NoOfFrames and FrameDelay in Resources::Bitmap are implemented as properties. This had the side effect of the values being listed in Inspector window what could be seen very well on the example of Extern-Bitmap. Similarly the class Resources::Font exposed the properties Ascent, Descent and Leading. The class Core::Group exposed Focus. Embedded Wizard has been modified to hide these properties in Inspector explicitly to no confuse the user.
★The escape sequence \0 within a string literal reported a Chora compiler error. According to the Chora documentation the escape sequence \0 represents a character with code 0x0000. Nevertheless, the escape sequence provoked a Chora compiler error.
★In the Prototyper the touch events were not processed correctly if the preceding touch event has been stopped by a breakpoint. The Prototyper has been enhanced to track key, mouse and touch events. When the application execution was halted (due to a breakpoint, an error or Halt command) and the execution is then resumed again, all recently active key, touch and mouse events are terminated and the corresponding UP events are sent to the application. This is even true if the user is still pressing a key or mouse button. In the praxis this will not happen, since in the moment when the execution is halted, the user has to use mouse/keyboard to resume the execution again. The user will release the mouse and/or keys. Code existing for compatibility with old Mosaic approach to dispatch keyboard events (via Core::Group.DispatchEvent has been removed to allow the above adaptation. This is not problematic since the new interface (Core::Root.DriveKeyboardHitting) exists already for more than 7 years.
★Code Editor assistant windows treated incorrectly enumeration and sets. The Assistant windows showed all items existing within an enumeration or set even if the items were internal Mosaic items. Internal Mosaic members have to be hidden per default. Assistants have been adapted to hide internal members.
★Bug in Simple Touch Handler when deflection is performed during OnHold. If during an OnHold event the corresponding implementation does request the touch interaction to be deflected to other handler, the original handler received two OnRelease events. The problem was caused by the variable Down, which changed to false while processing the OnHold event. The decision to send OnRelease was made after OnHold.
★Problem with deflection when more than two Touch Handler are involved. Following situation:
•there are 3 Touch Handler arranged one above the other.
•The top-most handler is configured to react to 3-finger gestures.
•The middle handler is configured to handle 2-finger gestures.
•The bottom-most react to one finger gestures.
•To fix this issue it was necessary to enhance the methods CursorHitTest, RetargetCursor and RetargetCursorWithReason by an additional parameter aStartView. This parameters, if not null, limits the hit-test operation to the given view aStartView and all views lying behind it. Views in front of it are ignored. This stops the endless ping-pong between the top-most handlers.
•The touch handler classes Core::SimpleTouchHandler, Core::RotateTouchHandler, Core::WipeTouchHandler and Core::SlideTouchHandler have been reworked to use the new parameter.
IMPORTANT
Please note, if your application uses or overrides the above mentioned methods, you will need to enhance your implementation by the new parameter aStartView.
★Undo for Replace all occurrences in Code Editor is not working as expected. If the user after performing the operation in Code Editor did want to undo the replacement, the user had to repeat the command for each individual occurrence. In case of many occurrences, this could take long time. Now affects all occurrences replaced during the preceding operation.
★Elimination of default glyph with virtual fonts. The font conversion eliminates automatically duplicates of the default glyph (.notdef glyph). This worked well if the font resource consisted of a single font only. If a font resource was composed of multiple different, language associated fonts, the default glyph was determined by the last processed font. The elimination failed thereupon because the default glyphs from other fonts might be different. To fix the issue the font conversion has been adapted to perform the default glyph elimination individually for each language variant. If the default glyph .notdef is missing in the original TTF file, a new default glyph is created.
★Code Editor syntax highlighting was not working correctly. Block comments were not highlighted correctly in the Code Editor. In some cases, the editor did not detect the comment. The contents of the comment were then processed and highlighted as Chora syntax.
★Problem with member named after Windows special devices. Several special names are reserved in Windows and can't be used. This includes CON, PRN, COM1..COM9, LPT1..LPT9, NUL, etc. Using such names, however, was legal in Embedded Wizard. This might lead to problems when the name is used to create project file or generated code file. The file creation failed in such case. Embedded Wizard has been adapted to prevent the user from naming units after special Windows file names like CON, PRN, COM1..COM9, LPT1..LPT9, NUL, etc.
★Error in numbering of enum items. If an enum item was configured with the value -1, the next following item had to be configured explicitly with the value 0, otherwise Embedded Wizard reported an error. Now, the strict ordering of items within the enum is not required anymore. Instead, the new implementation compares the values of all items and reports an error if there is a duplicate. The order of items does not play a role anymore. Furthermore: the modification also affects the set member. This means, duplicates are detected. The order of the items within the set does not matter anymore.
★Error with negative enum items. If an enum item was configured with a negative value, the Code Generator generated from this an unsigned value. This caused the C compiler to report an error because C enums have to be signed integer. This problem was caused by a fundamentally different consideration of 'enum' definitions in Chora and C. In ISO C, 'enum' is a signed integer. In Chora, enum items can be initialized with signed or unsigned value. The values are then internally stored as 32-bit unsigned value. The corresponding data type XEnum in the generated code is thus also unsigned int. The enum items, however, were generated as C enum members. This could lead to C compiler errors or warnings because of mixed signed/unsigned integer when a C enum member is assigned to a Chora enum variable. The unique possibility to solve the issue was to abstain from generating enum-items as ISO C enums. Instead the items are generated as #define now. Similar modification has been applied to Chora set members. These are also unsigned and consequently not correctly mapped to ISO C enum. Now, set items are generated as #defines too.
★Usage of JavaScript keywords as member names. Embedded Wizard has been adapted to prevent the user from naming project members after reserved JavaScript keywords (e.g. function). For compatibility purpose old projects containing the names are loaded without errors. During prototyping or code generation, however, the invalid names are reported and the user has to adapt the project accordingly.
★Missing out of memory error handler when loading bitmaps in an Assistant window. Trying to load a very large image file in an Assistant window could raise an out of memory exception and cause Embedded Wizard to exit. An additional error handling has been added to recover from this exception.
★FindViewInDirection is not working as expected in some cases. FindViewInDirection methods in Core::Group and Core::Outline have been modified to perform an additional evaluation with the center position of the view. This suppresses the issue of the center being moved unexpectedly outside of the light cone when the view has an elongate shape. In other words, the evaluation is performed twice: (1) with the original center and (2) with a moved center for elongate views. The better wins.
★EwFlushBitmap was not working for the bitmap representing the viewport (frame-buffer). The XBitmap structure created during EwInitViewport invocation was not initialized correctly. The field Surfaces[0] did not refer any valid surface. It was NULL. Thereupon EwFlushBitmap had no surface to flush and had no effect.
★Ugly looking gradients in OpenGL ES 2.0 target system when performing bitmap warp operation. When displaying a bitmap with the OpenGL low-level function WarpDriver, the bitmap appeared incorrectly if an additional color/opacity gradient was specified for the operation. OpenGL rendered the bitmap in this case by displaying 2 separate triangles. The colors used in each triangle were interpolated individually. This could be seen at the edge connecting the both triangles. The OpenGL, OpenGL ES 2.0 and WebGL PP versions have been enhanced by new shader programs optimized for color interpolation. The new programs are selected when perspective Warp-operation is performed with a gradient or the non-perspective Warp-operation with the complex gradient. In all other cases the old shader programs are used.
★Exception reported when using the dynamically loaded TTF fonts in the Prototyper window. If an application was using the new Resources::ExternFont object during Prototyping and simultaneously in the Composer window, Graphics Engine reported an exception in the EwFreeFont operation. In some cases, no exception was reported. Instead the text rendered by the Resources::ExternFont object appeared incorrectly as if the font were not configured with the right size.
★Incorrectly generated code with nested if-else and for-loop statements. The optimization implemented in version 11.00 had a side effect resulting in incorrectly generated code. Did a method contain a nested if-else and for-loop statements, then the else branches of the nested if-else statements were in the generated code incorrect. The resulting code could be compiled without error in the target system. However, it did not work as expected.
★Incorrect optimization with if-else statement having similar (but not exactly equal) 'true' and 'false' branches. The optimizer in version 11 compared the 'true' and 'false' branches of each if statement. If the branches were equal, the entire if-statement was reduced to its 'true' branch. Due to an error in optimizer algorithm the comparison ignored different type-cast operations in the 'true' and 'false' branches. Accordingly both were considered as identical although a typecast operation used in both branches used different type names.
★Searching for depending DLLs while loading an Intrinsic module ignored Windows PATH environment variable as well as the Windows\System32 directory.
★Crash during Chora code optimization reported by customer's dump file. The comparison of the true/false branches of an if-else statement might cause a crash if the both branches start with equal statements and the true branch contains one additional statement.
★The error message could not post again a signal was incorrect. The error message appeared in the Log window section and the message refered to callstack "displayed below". In the practice the callstack entries, however, are displayed in the Log window section . The sentence "are displayed below" was thus confusing the user.
★Memory Leak in Garbage Collection with surfaces remaining 'used'. In certain cases, a surface could remain referenced from an issue buffer while the original owner bitmap of the surface was already freed. The new version uses a new variable Locked to count the lock/unlock balance.
★Incorrectly generated code for WebGL platform when using variants. Following scenario caused problems in code generated for WebGL target system:
1.There are two classes A and B. Class B descends from Class A.
2.Class A implements method Foo.
3.Class B overrides the method Foo and invokes super() to execute the inherited code of class A.
4.Classes A and B, both, are additionally overridden by a variant, both overriding the method Foo. The variants do no necessarily be active. They can depend on a Style which is never active.
5.An object of the class B is created.
6.Method Foo of the object is invoked.
7.The super() call in class B is directed to the super class A. Since it is overriden by a variant, special variant dispatch method used here.
8.The variant dispatch method determines whether the variant is active. This is not the case.
9.The dispatch method decides to invoke the original implementation of the method Foo from the class A.
10.Because of the dispatch method the original implementation is found in a separate method starting with _ in its name.
11.The method is invoked directly in context of this object.
12.Unfortunately, the class B has also a dispatch variant method for the method Foo and its original implementation is found in the homonymous method starting with _.
13.The implementation from the class B is executed instead of the found in class A.
14.Endless recursion.
★Error with Text Editor component template when the % sign is displayed.
1.The user enters the text 12345%6789 in the Text Editor component.
2.The user moves the caret to the position between 5 and %.
3.The user presses the key DEL.
4.The operations deletes both, the 5 and % signs.
★Performance problem when using FreeType font engine during font conversion. Selecting FreeType in the FontConversion attribute might significantly affect the performance during the code generation if a font resource is configured with Ranges attribute containing many individual code ranges. In such case each range was converted individually. This included the creation of a new FreeType instance. The font converter has been adapted to retain (cache) the latest loaded font until the converter is destroyed again or other font is selected for the conversion.
★Embedded Wizard Studio could lose focus after switching the Composer pages.
1.Click in Inspector some property value so it becomes blue.
2.Click in the Navigation Bar on a tab to switch the Composer page to some unit. It is important that it is a unit.
★Temporarily installed font was not used if there was a homonymous font already available in the Windows system. The temporary installation of fonts did not work as expected if a homonymous font has been installed in advance manually. In such case Windows might select the already available font. If the font versions differ, the results were unpredictable. The exact condition and Microsoft documentation are unclear. The implementation has been adapted to check before temporarily installing a font file whether a homonymous font is already available on the Windows system. There is no possibility to control the font loading behavior of Windows.
★Floating point literals were not generated correctly when the respective value is very small. If floating point value was very small (e.g. 0.000000001), the Code Generators produced 0.0 as result.
★Floating point literals in Chora script were truncated. When evaluating a floating point literal in the decimal notation (e.g. 0.0000001) the part after decimal point was limited to 9 digits. Consequently, a value like 0.0000000001 was evaluated as 0.0. The Chora parser has been adapted to accepts up to 18 digits after the digit point.
★Glyph surface size calculation and not correct RAM usage window outputs. The size of the glyph surface cache is determined by values EW_MAX_GLYPH_SURFACE_WIDTH and EW_MAX_GLYPH_SURFACE_HEIGHT. During initialization the values are re-calculated to estimate an optimal size of the glyph surface cache. In some cases the surface might become bigger than the originally specified MAX values. The surface occupied consequently more RAM. Additionally the Memory (RAM) usage window displayed too much issues.
★Incorrect code optimization and crash during code generation. for statement with an empty condition (for (;;)) caused a crash during optimization. do-while statement tracked incorrectly the modification of variables within the body of the statement. The optimization of do-while statement has been reworked.
★The debug function EwPrint was not working correctly on 64-bit targets. The EwPrint function produced incorrect outputs for values formatted with %d, %u, %x, %X if the application was running on 64-bit CPU.
★Modifying the rect value returned by a method caused a crash instead of reporting an error message. Following code line crashed the prototyper: GetContentArea( Core::ViewState[]).x = 10; Chora compiler has been modified to detect and report an error when an assignment operation is applied on an instant property in scope of a non mutable operand. In case of this concrete issue, the scope was a value returned by a method. The previous implementation ignored the special case of method or intrinsic function. Now the scope is considered as mutable if it is a variable, array-item, parameter, property, local variable or local array-item.
★Incorrectly generated code for WebGL platform. The incorrect code was caused by the optimizer ignoring the enum to int32 type-cast operations with constant operands. The optimizer has been enhanced to handle all possible type-cast operations between enum/set and signed/unsigned integer values as well as the conversion to bool.
★The modification of an *.EWU file was not detected when the attribute Split of the corresponding unit has been changed. After changing the Split attribute the internal directory observer lists were not recreated. Thereupon eventual modifications of files found in the directories were not detected. When the project was closed and re-opened, the notification worked as expected again.
★Crash in target when using 64-bit integer data members. 64-bit data members enforced the alignment of the data structures to next 8-byte border. This might lead to padding gaps between the embedded objects. The garbage collection, however, expects the objects to be stored packed one behind the other. This could cause a crash. The C Code Generator has been enhanced by a new object layout optimization. This version ensures that 8-byte aligned members are always arranged at the beginning of a class. Then follow all embedded objects which also contain 8-byte aligned members. This modification affects thus the order of members how these are stored within the class.
★Error in code optimization with compound assignment operator. The expression foo += 1 was eliminated if foo was preinitialized with 1 and there was no other operation modifying the variable foo.
★Layout error in alphanumeric virtual keyboard component template. The border views used to highlight the shift, caps-shift-lock and space buttons had not the Layout property being properly configured. When the keyboard was resized, the borders were not moved/adjusted as expected. They stayed at their original position.
★Core::Group methods are exposed in Vertical and Horizontal lists. The views Core::VerticalList and Core::HorizontalList descend from Core::Group. Accordingly they inherit a lot of methods from Core::Group. These methods were then exposed in all relevant Assistant windows. The usage of these methods, however, is not possible. The both list components implement own mechanisms affecting updates and view management. To avoid that the inherited methods are used by mistake, the methods are not listed anymore in the Assistant windows.
★Alignment error in the image file used by Resources::KeyIconsSmall. The frame 5 and 6 overlapped by 1 pixel.
★Entries for the built-in variables this and parentthis were missed in the Scope Assistant windows.
★The Outline Box method GetContentArea returned old values if layout update was still pending. If the Outline Box was configured with the property Formation to automatically arrange the embedded views, the invocation GetContentArea returned an old value if the recently requested layout update has not yet been performed by the superior group. Now, when one of the following methods is invoked, the Outline Box verifies whether it needs a formation layout update. Is this the case, the superior group is triggered to perform the update immediately: EnsureVisible, FindViewInDirection, FindViewWithinArea, FindViewAtPosition and GetContentArea.
★Deleting a member within a unit with the following operation caused the member to be arranged at the beginning of the members list.
1.Select within the unit a member which is not the first nor the last one.
2.Delete the member.
3.Undo.
4.The member appears arranged at its original position.
5.Switch in Composer to other page and return back to the unit.
6.The member is now arranged as the first one.
7.Save the project, the member appears also at the beginning of the unit.
★Incorrectly working stroke path vector graphic operations. The Stroke Path view calculates from the original path data a shape to fill with the color. For this purpose the algorithm connects the end positions of adjacent edges by an additional edge. If the end positions are less than 1 pixel away, the existing edges are prolongated (or truncated) in order to find a common join position instead of adding a new edge. This calculation, however, ignored the special case of the edges being semi-parallel. The prolongation produced in this case very large coordinates or even coordinate overflows resulting in display errors. Now the algorithm verifies the calculated position whether it is near of the original position. If this is the case, the optimization is ignored and new edge is added.
★Warnings due to double definition of macros. The macros EW_STRINGIZE and its associated macro EW_STRINGIZE_ARG were defined in multiple files belonging to the Platform Package and Build Environment. This could cause C compiler warnings.
★Handling of not existing glyphs during font conversion. Glyphs not existing in a TTF/OTF file were originally replaced during the conversion by the so-called .notdef glyph. Unfortunately, some TTF/OTF designer do not follow the rules to provide a dedicated .notdef glyph. Often, the .notdef glyph corresponds to the .space glyph or it is not available in the font. This could lead to problems with the space glyph being eliminated (due to being considered as not existing). As consequence the Graphics Engine reports runtime errors when the space glyph is used. Now, the .notdef glyph is handled explicitly. If the .notdef glyph is not existing or it is empty, a dummy glyph is created displaying a simple box.
★Mosaic Group view did not react when new group has been assigned or an existing group has been disconnected from the view. Similarly, when the size of the associated group changed, the view has not performed the full update. This resulted in missing of incomplete screen updates.
★Example Menus reported the error could not post again a signal. To fix the error the component templates Menu and Alert have been reworked to correctly use InvalidateLayout() instead of triggering the slot method autoResize. This avoids the mentioned error message. The Menus example updated to use the modified templates.
IMPORTANT
If in your project you used the template Menu or Alert to create components you will eventually need to review the affected components.
★Exception when using FreeType engine for font conversion and the font resource attributes Bold or Italic were configured with the value true. Therefore unhandled exception was reported during the font conversion.
★Few code modification to suppress MISRA warnings because of floating point literals.
★Few code modification to suppress MISRA warnings because of condition being always true or false.
★Incorrect elimination of conditional expression (ternary operator ?:) if the result of the expression was not used. The optimization implemented in Embedded Wizard 11.00 eliminates expressions if the result of the expression is not used and the expression has no side effects. This optimization ignored the ternary operator resulting in the ternary operator being split in its operands. Incorrect code was generated.
★Incorrect behavior of the string() instant constructor when running on the WebGL target system and formatting a floating point number. The instant constructor returned in this case a string containing 6 digits after the period sign even if the digits were 0 signs. The behavior has been corrected to correspond to how Prototyper and code running on other target systems do behave. Trailing zero signs are trimmed now.
★When generating code, the resulting file names are named after units and unit members. When a unit or member was renamed so that the case was changed only, the names of already generated files were not updated. Now the implementation is case sensitive.
★Originally, when using the Prototyper, the loading and compilation operations cound cause short animations to finish before they were able to start. Now, when project members are loaded into the prototyping environment and Chora code is compiled, the corresponding time is subtracted from the time base. Animations are not affected by the pauses resulting from the loading and compilation operations.
★Native code in the Mosaic class Resources::ExternFont used true as keyword. This could cause compiler errors on diverse C compiler.
★Touch handlers in Slider Item and Toggle Item component templates were configured incorrectly to deflect touch interaction also when the user performs a horizontal wipe gesture.
★Inline comments of diverse component templates as well as the arrangement of bricks in the template Pie Chart were incorrect.
Known Issues
★During code generation the names for created files (e.g. *.h and *.c) are derived from the original names of the corresponding project members. While Embedded Wizard is case sensitive, the MS-Windows file systems are not. This may lead to the problem of two different project members being mapped to one and the same file. The resulting code is incomplete. For example, let's assume you have a unit containing two Bitmap resources named Logo and logo. Since Embedded Wizard is case sensitive, it will distinguish the both resources. During code generation, however, both resources are mapped to one and the same file logo.h.
★During code generation the names for created files (e.g. *.h and *.c) are derived from the original names of the corresponding project members and the superior unit member. Depending on your project contents, two different unit + project-member combinations can produce one and the same file name. The resulting code is incomplete. For example, the member DeviceClass within the unit Test and the member Class within the unit TestDevice will be mapped to one and the same file name _TestDeviceClass.h.
★PostProcess batch jobs stored in format other than ANSI are not processed correctly. The Windows command line processor CMD.exe interprets the batch files and produces outputs according to the actually (user specific) selected code page. Consequently, changing the code page on a customers development machine may cause the CMD.exe to report an error and unreadable outputs are displayed. Also possible, when the user edits the batch file in a text editor and adds some special characters to it, the editor may store the file in UTF8 format. Such batch file will not work anymore if the configured code page is not 65001 (UTF8). Actually there is no option to configure the code page in CMD.exe directly. The unique possibility could be to execute two commands in succession in context of the same command line processor. The first command switches the code page to UTF8 and the second command starts a second command line processor to interpret the batch job:
chcp 65001 && cmd /c job.cmd
★Crash in target when using 64-bit integer data members (e.g. int64 or uint64 variables). 64-bit data members enforce the alignment of the data structures to next 8-byte border. Depending on the surrounding contents, the enforced alignment may lead to padding gaps between embedded objects. The garbage collection, however, expects the objects to be stored packed one behind the other. The correction for this issue introduced in version 12 was incomplete. If you are using version 12 and you still observe the issue, following workaround can be applied:
1.In your Build Environment locate the file ewobject.c.
2.Search in the file for the following implementation:
while (( objs < end ) && ((XObject)objs)->_.GCT )
3.Replace the implementation by following code:
while ((( objs + sizeof( struct _obj_XObject )) <= end ) && ((XObject)objs)->_.GCT )
4.Alternatively, if you have no source code for the ewrte.c file, please search in your Build Environment for the file ewrte.h.
5.Search in this file for the definition of the _obj_XObject data structure. For example:
struct _obj_XObject { struct { const struct _vmt_XObject* VMT; struct _obj_XObject* Mark; struct _obj_XObject* Link; const struct _vmt_XObject* GCT; } _; };
6.Modify the definition of the structure to enforce the alignment for all members to 8 byte. Here an example for the GCC compiler. If you are working with other C compiler, use the adequate syntax:
struct _obj_XObject { struct { const struct _vmt_XObject* VMT; struct _obj_XObject* Mark; struct _obj_XObject* Link; const struct _vmt_XObject* GCT; } _; }__attribute__((aligned(8)));
7.Rebuild your application.
Update version 12.01
A new update version 12.01 is available. This update contains the following changes:
★Support for the Renesas RA chip family added. With the new Embedded Wizard Studio setup, the Platform Packages for Renesas.RA.RGB565, Renesas.RA.LumA44 and Renesas.RA.Index8 are installed. The new Build Environment for Renesas RA6M3G-EvaluationKit requires the new platform support.
Update version 12.02
A new update version 12.02 is available. This update contains the following changes:
★Support for the STM32G0B1 target added. The new Build Environment for STM32G0B1-Nucleo requires this version of Embedded Wizard Studio.
Update version 12.03
A new update version 12.03 is available. This update contains the following changes:
★Project templates for ESP32-S3-BOX and ESP32-WROVER-KIT corrected.
★Project templates for STM32F469-LIZARD added.
Update version 12.04
A new update version 12.04 is available. This update contains the following changes:
★Support for the STM32U5 chip family with NeoChrom graphics acceleration added. With the new Embedded Wizard Studio setup, the Platform Packages for STM.STM32_NeoChrom.RGB565, STM.STM32_NeoChrom.RGB888 and STM.STM32_NeoChrom.RGBA8888 are installed. The new Build Environment for STM32U599 Discovery with NeoChrom requires the new platform support.
Update version 12.05
A new update version 12.05 is available. This update contains the following changes:
★Support for the GigaDevice GD32 chip family added. With the new Embedded Wizard Studio setup, the Platform Packages for GigaDevice.GD32.RGBA8888, GigaDevice.GD32.RGB888, GigaDevice.GD32.RGB565, GigaDevice.GD32.RGBA4444, GigaDevice.GD32.LumA44 and GigaDevice.GD32.Index8 are installed. The new Build Environment for GD32F470-Evalboard requires the new platform support.