Joel Bodenmann

You don't need a pixmap in this case. You can simply cache the image using gdispImageCache(). A cached image is stored as a decompressed bitmap just like it would in the pixmap with the simple benefit that in some cases, some really basic RLE will be applied that decreases the image size without having a real impact on the rendering performance. To answer your question anyway: You render to a pixmap like you would to any other display. A pixmap is nothing but a virtual display. You use all the normal GDISP rendering calls. Therefore, you can render an image to a pixmap using the regular gdispGImageDraw() function. The wiki demonstrates rendering to a pixmap: https://wiki.ugfx.io/index.php/Pixmaps

Great! Thank you for sharing that with the community!

You have to enable unicode support in your configuration file. Of course, also make sure that your source file(s) are unicode encoded as well when you hard-code your strings. Furthermore, make sure that the Chinese glyphs are not being filtered-out by the default filter range of the online converter.

You can either use the flashing property provided by GWIN (gwinSetFlashing()) or you can implement a custom widget that uses a GTIMER internally to render if you need more control. Do not simply call gwinHide() and gwinShow() periodically. While that has visually the same effect you'll not get what you want as your button will not receive any events while not being visible (meaning you can't click it).

Can you please show us pictures of both pages (eg. the previous page as well)?

gdispFillString() does only fill the bounding rectangle of the string. The bounding rectangle depends on the string you are rendering - although you use the same font you'll have different rectangles based on the string. gdispFillStringBox() allows you to specify the size of the box. Hence that is the correct one to use in this case.

I'm pretty sure that you're using gdispDrawString() instead of gdispFillString() or gdispFillStringBox(). The gdispDrawString() only renders (changes) the pixel of the actual new string. Everything else remains the same. gdispFillString() and gdispFillStringBox() will clear the pixels not occupied by the string with the corresponding background color. Use those.

I'm sorry, this is not a code::blocks support forum.

Hello and welcome to the µGFX community! You can use the µGFX library with any IDE. There's a generic guide here: https://wiki.ugfx.io/index.php/Getting_Started#Integrate_uGFX and there are more IDE specific guides listed on the front page: https://wiki.ugfx.io/index.php/Main_Page

Can you please provide a ZIP containing your entire ChibiOS project so we can have a go on it ourselves? We haven't had any problems at all with using µGFX with ChibiOS and neither did anybody else - this has to be something very small in the build setup

Hello @Stewels and welcome to the µGFX community! I took a look at your makefile and this is wrong: # GFX files. include $(GFXLIB)/tools/gmake_scripts/library_ugfx.mk include $(GFXLIB)/tools/gmake_scripts/os_chibios_git.mk Please follow this guide to add µGFX to your existing ChibiOS project: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT

Thank you for your feedback, we appreciate it a lot! I'm not really sure what you'd expect. Usually you need to debug your application, not the library you're using. So simply using fprintf() as suggested by @inmarket should get the job done.

@inmarket I already have his project with the corresponding changes in uGFX.

Glad to hear that you got it working! I was somehow under the impression that you don't get anything on the display - this definitely makes sense. I assume the errors you're getting are due to the fact that there's not enough RAM to fit the uGFX heap during linking time.

Did you properly set GFX_CPU, GFX_OS_HEAP_SIZE and GFX_COMPILER? The latter is very important when using Keil. When using the Raw32 (baremetal) port with Keil you want to make sure taht GFX_OS_HEAP_SIZE is a non-zero value. It's the heap size that µGFX will use in bytes. Give it something like 20k or 40k to get started.

Whether that is okay or not is something you need to decide yourself. You have to implement the widget the way you like it The GTimer should definitely only run while you're editing the numbers. I'd add API for that, something like: mywidgetHoursSet(GHandle gh, uint8_t value); mywidgetMinutesSet(GHandle gh, uint8_t value); mywidgetHoursFlash(GHandle gh, bool_t enabled); mywidgetMinutesFlash(GHandle gh, bool_t enabled); So when you want to start changing the hours, you'd do this: // Start flashing the hours digits mywidgetHoursFlash(ghWidget, TRUE); // Some code that allows the user to modify the hours while (...) { // ... mywidgetHoursSet(ghWidget, <newValue>); // ... } // Done changing the hours - stop flashing mywidgetHoursFlash(ghWidget, FALSE);

Hello Fabien, There are no built-in mechanisms for this. However, it's extremely easy to implement this yourself as all of the things you need for that are exposed as high-level API. The most challenging thing will be the handling of overlapping containers but as @Steffan showed that is no biggie either:

Hello Alan, Using a GTimer inside the custom widget to make the digits flash is definitely the (only) right approach. You can either separate the gdispFillStringBox() into multiple ones or (and this should be fast), simply use gdispFillArea() to render a rectangle over the portion of the string you want to hide momentarily (to make it look like it flashes). You can use gdispGetStringWidth() to find the correct width of the rectangle.

Hi @Oshel, There's not really much going on in _gosInit() for RAW32. I'm afraid there's not much that comes to mind. Unfortunately you have to get out the debugger and dive into it One thing though: Did you try this with disabling all modules so that gfxInit() really just invokes the GOS module? Please don't hesitate to ask if you have any specific questions - happy to help wherever we can!

Great! Thanks a lot for sharing this with the community

I'm not really sure whether I understand what you want to achieve, but in general: Use a GTimer inside your custom widget to implement things like animations, flashing and stuff like that. But keep in mind that you are only allowed to draw in the one drawing/rendering function. So use the GTimer only to change an internal flag and draw based on the state of the flag.

Hello nathan, Are you sure that you downloaded the latest version of the µGFX library? I just checked the changelog.txt file and it clearly lists the changes under the Release 2.8 line. If in doubt, the changelog is also listed at the bottom of the download page file description:

Glad to hear that everything is working now. We released v2.8 of the µGFX library which comes with a vastly reworked STM32LTDC driver. A couple of issues have been fixed. Additionally, it's now possible to use the second layer of the LTDC.

Can you please show us the implementation of auto_Demo() and updateModeItem()? Also, what's the value of UPDATE_ITEM_INTERVAL?

Hello Tobi, Thank you for your feedback - we appreciate it a lot! There's nothing wrong in your code. This must be an issue in the SDL driver itself (the one in /drivers/multiple/SDL). I haven't written the SDL driver myself so this is primarily wild guessing but I assume the in the SDL initialization there is some configuration flag that lets you choose whether touchscreen events are being processed as mouse events (in case of SDL can distinguish the two). There's definitely no other magic involved in other parts of µGFX. I don't have time to dive into this right now - could you take a look?