Problem With Automatic Style Change using version 9.00

Question

Hello Everyone,

I’m making a modification to a device developed with Version 9.0.0 of Embedded Wizard, and I have the following problem:
The modification requires me to add several styles to the interface, and these styles must be “fixed”, meaning they won’t be selectable by the user, but predefined during the manufacturing process

I am required to keep the device's Firmware "unique", meaning I can’t use the mechanism that allows me to associate a graphic style with a Profile Configuration and manage it statically — I must necessarily handle styles dynamically, so the device must be able to recognize its own version via software and draw the GUI accordingly, using the correct colors, icons and fonts.

The solution I tried to implement is as follows:
In the “Init” method of Application::Application, the first thing I do is call a method that asks the Middleware which style to use for the GUI, and based on the value returned, I set the GUI style by changing the "styles" variable.
However, since the function ApplicationApplication__Init has already been executed, this call seems to have no effect until I interact with a component. After the interaction ends, the component takes on the correct appearance.
If I navigate to a different page of the GUI, that page is in the correct style, but when I return to the Main Menu, the problem persists.

I tried using the InvalidateViewState() method, but at best I end up with a situation where some components are redrawn correctly and others are not. I’m attaching some screenshots to explain better.

I also tried following the instructions I found in some questions on this forum and in the documentation, but with no luck.
I’m aware that in Embedded Wizard 9.00 changing the style dynamically has no effect on components that have already been initialized, and I’d like to know if there is a way to force the reinitialization of the components that I’m unaware of.

These are the articles I found here:
https://ask.embedded-wizard.de/7077/handleevent-missed-during-style-handling
https://ask.embedded-wizard.de/143/changing-the-style-during-runtime?show=143#q143
https://ask.embedded-wizard.de/10233/about-refreshing-language-and-style?show=10235#a10235

Here are some screenshots : 

Normal Look :

Desired Look

"In Between" look, here the style is set correctly but the Gui shows changes only after having touched the buttons

 

Thank you for reading
Dario.

Answer 1

Hello Dario,

try following: instead of setting the global variable styles in the Init method (which is too late), execute the following code just before the application object is instantiated. That means before the C function EwInitObjectIndirect( EwApplicationClass, 0 ) is called during the startup time of the application (see also Initialization of the GUI Application):

EwSetStyles( YourStyleName );

I hope it works.

Best regards

Paul Banach

Comments

Hi Paul,
Thank you for your answer, in the end I was able to solve the problem in a different way.

I declare the view classes that I need as plain variables in the composer window, and then I create them in the Init function after asking the middleware the correct style, using a "new" statement.
Is the method you proposed safer / more reliable or efficient in any way? I Don't mind changing the approach if it's better.

That saind, I'll take the opportunity to ask you another question :
In this project we are still using version 9.00 because that was the latest version when the project started development, and until now we preferred to maintain that instead of updating to the latest version. Now we have to add some things like styles and different fonts and languages but the device is running short of flash memory and not all the changes we need to make will fit in what's left.
Would there be some significant memory advantages if we switch to version 14.06?

Thank you again,
Best Regards,

Dario

---

Hello Dario,

Is the method you proposed safer / more reliable or efficient in any way? I Don't mind changing the approach if it's better.

your approach is correct. If it is working, you don't ned to change it.

Would there be some significant memory advantages if we switch to version 14.06?

As you can see in Release Notes, we have continuously optimized the Code Generators to eliminate as much as possible unnecessary project members and expressions. This also had the effect of less RAM needed by the application. Also diverse optimizations and possibility for slimming the Graphics Engine have been added. Nevertheless, I don't know your project and your device memory configuration. It is thus difficult to give you a clear YES or NO answer.

If the problem is caused by many large resources (fonts, bitmaps,...) and these are already compressed, then there are not many options to save memory. If you have external ROM you could eventually relocated the resources there.

If you want to explore this question further and provide more details to your device configuration I would recommend starting a separate thread in this forum. Then my colleagues with more hardware-related competence can address it and eventually help you.

Best regards

Paul Banach