Styling error with HTML2COLOR

[MobileWill]

I am trying to use a custom color with the studio. gdisp_colors.h gets the following error when compiled.

.\ugfx/src/gdisp/gdisp_colors.h:313:28: error: expected declaration specifiers or '...' before '(' token
   #define HTML2COLOR_R(h)  (((h) & ((0xFFL & ~((1<<(8-COLOR_BITS_R))-1))<<16)) >> (24-(COLOR_BITS_R+COLOR_SHIFT_R)))

Anyone come across this? It looks okay to me. All the () line up.

[inmarket]

Looks ok to me too.

[Joel Bodenmann]

This seems to be a very odd problem. Those color macros are very well tested and no issues are known to exist. I expect the issue to be somewhere in the code generated by the uGFX-Studio. Most likely you have some invalid characters in your color name (eg. spaces or special characters) that don't get filtered properly.

Can you please attach your uGFX-Studio project directory as a ZIP archive to your forum post so we can have a look? Can you also give information about the version of the studio, your operating system and which compiler throws this error?

~ Tectu

[MobileWill]

I am on Win10x64 with Embitz. Studio is latest 0.12. I changed the name of the color without the underscore and that seemed to work.

[Joel Bodenmann]

Interesting, underscores shouldn't have an effect as long as the name starts with a letter (specified by the C standard).

I pulled your project before you edited your post so I will have a look anyway to figure out what needs to be fixed. The upcoming 0.13 release already contains a lot of fixes to prevent generating invalid variable and function names.

A general comment: Use the Background property of the WidgetStyle to change the background color. Drawing a huge rectangle in the background designer is the wrong approach and will not only have worse performance but will also lead to unexpected problems as some parts of de GWIN module need to know the background color.

~ Tectu

[MobileWill]

Thanks for the help. I will redo the backgrounds. It was before I saw the widgetstyles.

[MobileWill]

A general comment: Use the Background property of the WidgetStyle to change the background color. Drawing a huge rectangle in the background designer is the wrong approach and will not only have worse performance but will also lead to unexpected problems as some parts of de GWIN module need to know the background color.

Do I use a container to apply the style to the entire page?

What is the difference of putting an image in the background vs imagebox on the page?

[Joel Bodenmann]

A background is nothing else but a container that spans the whole display area. The background designer just generates a custom rendering routine for that container.

Let's have a look at some generated code. The following is the custom rendering code that will be applied to the page container. The background is called MyBackground:

static void containerDraw_MyBackground(GWidgetObject* gw, void* param)
{
	(void)param;

	// Clear container area
	gdispGFillArea(gw->g.display, gw->g.x, gw->g.y, gw->g.width, gw->g.height, gw->pstyle->background);

	// Draw the elements
	gdispImageDraw(&companyLogo, 500, 10, 121, 60, 0, 0);
}

As you can see the first thing that happens is that the entire container area gets cleared with the background color specified in the widget style. That is always the first thing that happens. When you make your own background by adding a huge rectangle in the background designer it will add another gdispFillArea() call to the rendering function. This means that the container area gets cleared twice which doesn't only waste a lot of performance, but will also lead to render artifacts when the two colors are not exactly the same.

In the background we added an image (companyLogo). As you can see that is a bare GDISP image that gets rendered directly. Not an imagebox widget (as you couldn't use them in a rendering routine anyway).

The difference between putting an image in the background instead of an imagebox is, that the imagebox adds overhead. It it's a widget, this means that it has to maintain position, styles, fonts, text and so on. The image added to the background is a simple gdispImage object without any overhead at all.

Another advantage of putting an image into the background is that you can use the same background on multiple display pages. If you want to show your company logo on all display pages using imagebox widgets you'd have to place individual imageboxes on each display page. This multiplies the overhead mentioned above by the number of display pages. Having the image in the background means that all display pages that use that background use the same rendering function and therefore the same image object. Not only no overhead but also no additional overhead for additional pages.

Regarding your question about using a container to apply a style to an entire page: No, the proper way is to use the 'GWIN default style' property in the settings or to assign a style to each widget individually.

As per the reason(s) above, never put a container that covers the entire display area. This means that you are doing something wrong (as in not following the intended usage).

I hope that helps.

~ Tectu

[MobileWill]

Thank you the clears things up a lot. I do notice that it is drawing the pages much faster now.

Is the default white supposed to be straight white? It does't look white to me. But actually looks okay.

(off topic)

And one more thing, will the studio eventually get frame and graph support?

[Joel Bodenmann]

Is the default white supposed to be straight white? It does't look white to me. But actually looks okay.

Yes, the background color of the built-in WhiteWidgetStyle is supposed to be straight white. You can see that the generated code uses HTML2COLOR(0xFFFFFF) for that. It doesn't get more white than that

And one more thing, will the studio eventually get frame and graph support?

Eventually, yes. We will release v0.13 on the 15th of February. Right now we are working on adding the possibility to add custom fonts. If we have enough time we will also add support to provide a temporary cure solution to use custom widgets in the studio (just dummy place-holders).

We'll see what we can do. I can imagine that adding graph support should be very easy and that we can get some preliminary version going for 0.13. Frame support can be done quite easily too as it's the same code as the container widget - just with a different rendering.

However, the question about the frame widget is how to treat that in the studio. This will usually be used as a pop-up dialog menu. Therefore, the user must be able to define that outside of the actual display page. Adding indirect items is currently not supported at all (but obviously will be) and therefore requires some major changes. I am pretty confident that the frame will be there at least as soon as v0.14 rolls out.

If you have any questions, feedback, bug reports or feature requests please do not hesitate to let us know in the corresponding uGFX-Studio section on this forum. We are happy to hear all about them!

~ Tectu

[sp9fkp]

I have the same problem as MobileWill from first post. EmBitz, Windows XP. I try to compile uGFX for STM32F746Disco. What can I to do?

[Joel Bodenmann]

Hello and welcome to the community!

Did you check whether the issues was the one discussed in this thread?
If the issue remains, please provide additional information such as the compiler that you are using, the compiler version, the compiler output log and so on.

[sp9fkp]

Hello to all,

GCC 4.8.4 Bare Metal from EmBitz

Log in attachment

log.txt

[Joel Bodenmann]

Are you using files generated by the µGFX-Studio? If so, can you please tell us which version (make sure that you use the latest one!) and upload a ZIP archive containing your project as well as the generated files.
Otherwise, please show us the code that you are trying to compile.

Are you using the make build system? Are you using single-file inclusion? Manually added all required files? ... 
Please provide as many information as possible.

[sp9fkp]

No. Project is compiled under EmBitz who have internal script for compilation. Files added manually. I want today make a new template project with files generated in uGFX-Studio. Be try...

Here is archive with testing project.

GPDSC.7z

I forgot add: project is placed in C:\Repository where also are located files from ST library and partially ilnked to project.

Edited March 17, 2016 by sp9fkp

[stucknewbie]

@sp9fkpDid you manage to solve/workaround the problem?

I am also using STM32F7 Discovery and ran into the same problem. If you know of any workarounds/solutions/fixes/patches, please do share.

Thanks!

[sp9fkp]

Sorry, but this is too complicated for my and now I have no time to investigations....

[inmarket]

Have a look at this post...

 

[Joel Bodenmann]

Our community member @Fleck tried this fix yesterday on his brand new STM32F7-Discovery and he can confirm that the fix that @inmarket pushed to the repository works well.