Joel Bodenmann

The new position (value) is part of the event that you receive: typedef struct GEventGWinSlider { GEventType type; // The type of this event (GEVENT_GWIN_SLIDER) GHandle gwin; // The slider that is returning results #if GWIN_WIDGET_TAGS WidgetTag tag; // The slider tag #endif int position; uint8_t action; #define GSLIDER_EVENT_SET 4 /* Slider position is set. This is the only event returned by default */ #define GSLIDER_EVENT_CANCEL 3 /* Slider position changing has been cancelled */ #define GSLIDER_EVENT_START 2 /* Slider position has started changing */ #define GSLIDER_EVENT_MOVE 1 /* Slider position has been moved */ } GEventGWinSlider; Have a look at the slider demo, it shows exactly how to do that. Here's a simplified section of that (untested): const char* sAction; GEvent* event; GEventGWinSliderEvent* sliderEvent; event = geventEventWait(&gl, TIME_INFINITE); switch(event->type) { // Handle slider events case GEVENT_GWIN_SLIDER: { // Cast to slider event sliderEvent = (GEventGWinSlider*)event; switch(sliderEvent->action) { case GSLIDER_EVENT_SET: sAction = "SET"; break; case GSLIDER_EVENT_CANCEL: sAction = "CANCEL"; break; case GSLIDER_EVENT_MOVE: sAction = "MOVE"; break; case GSLIDER_EVENT_START: sAction = "START"; break; } printf("Slider position = %d %s\n", sliderEvent->position, sAction); break; } default: break; }

Do the same thing that you're doing now but read the value that comes as part of the event that you receive as @inmarket suggested. Then, everything will work exactly the way you want it without any dirty or complex workarounds.

Yep, there are a couple of users here on the forum who are successfully using µGFX in visual studio projects. I also know of two commercial customers who do that.

Thank you for your feedback. We tested the built-in search feature of doxygen once and it's really bad in our opinion. It doesn't help unless you type in a word that exists exactly like that (eg. the proper function name or similar). Other than that, using Google and restricting the search results to api.ugfx.io is the proper & most helpful way.

Assuming that you're using the built-in image button rendering function of the button widget you just pass a different gdispImage* pointer via the custom parameter to the rendering function. The button widget doesn't store the pointer to your image at all, it just takes the custom parameter of the rendering function and casts it to (gdispImage*) that's all. Therefore, changing the image works like this: gwinSetCustomDraw(ghMyButton, gwinButtonDraw_Image, &myNewImage); With the images of the list box widget it's a different story because the image is actually being stored as part of the list item object. Changing the image is simply a matter of using the corresponding high-level API that has been added exactly for this: gwinListItemSetImage(ghMyImage, 0, &myNewListItemImage);

Actually, thinking about this, the proper solution is to create a custom gdisp_lld_control() command implementation that allows re-calling the driver initialization through gdispControl(). You can have a look at other existing drivers that use custom control commands such as the SSD1306 and the AlteraFramereader drivers.

Well, the proper solution is to add proper shielding and taking other measures required to pass the EMC test without the device becoming unusable Yes, gfxDeinit() will call the deinit() function of all modules, sub-modules and similar. It's the same thing as gfxInit() but in reverse. It can only clean-up the mess it created itself, so all the objects you allocated memory for yourself are not managed and you have to take care of those manually (you need an application wide deinit()). Deinitialization is not very well tested because it's not really needed in situations where µGFX is being used in the first place. The need for deinitialization usually shows a bad design (again, not in general but in systems where µGFX is being used in the first place). You can manually re-call the initialization function of the display driver but that's not supported from our side and vastly discouraged.

We implemented the palette support for BMP as part of a commercial product development (paid support). Initially the project called for both BMP and GIF support but at the end everything was realized with just BMP images so there's nothing done on GIF so far and there's nothing on the schedule / ToDo list for that. As we're currently building a huge pile of things we have to do here on the forum I wouldn't expect anything like that to happen any time soon. But please don't hesitate to contact us if you want us to get it done ASAP as part of paid support.

Hi, Can you please explain your question a bit? What do you mean by "monitor data"?

We had no time to dive into this yet, I'm afraid. I can't promise that we'll find time for that this week. If this is of importance due to a deadline of a commercial project or something like that please contact us if you want to get priority support (paid support).

When making a hard-reset of the display controller you have to re-initialize display controller which means that the internal initialization and post-initialization functions of the GDISP module need to be called (as well as the board_init()). This can only be done by calling gfxInit(). Therefore, you'd have to call gfxDeinit() first and then gfxInit() again. There's no way of buffering the existing GUI in between those operations. This doesn't make much sense in general (none at all). Can you please explain your use case or why you think that you need that so we can try to help you finding the proper solution? This sounds like a very bad design.

One solution is to render the image into a pixmap and then access and modify the pixel data through high-level API that is actually available for that. But that would obviously require you to have enough memory to create a pixmap of the required size.

Hi, What information would you like to get? There were a few different things mentioned in this topic. Please don't hesitate to ask specific questions.

font_t myFont; ... gdispGetFontMetric(myFont, fontHeight);

Hi, The built-in rendering function of the text edit doesn't offer that, no. But you can simply create your own custom rendering function that does that. Basically you can just copy the existing one and modify the justification parameter. Theoretically, you could create a custom rendering function that takes the justification via the parameter. The existing label drawing function does that too.

Yes indeed. Otherwise it's just not a wrapper. A C++ wrapper wouldn't do anything other than calling the equivalent C functions.

Note that you can actually use the GINPUT module without the need of having a touchscreen.

Hello Victor, Mixing C++ and C code is not always as trivial as it looks. There are always some nasty things to keep in mind like not including C headers after C++ headers and similar things. Inclusion order matters here. You indeed have to create a C++ file for your FreeRTOS port. In that, you can declare your C functions (the ones required by GOS) and the linker will be able to link them properly. There are other things you have to keep in mind like encapsulating your function prototypes in the extern "C" blocks: #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif I can't have a closer look at your files right now (and I can't try it) but I've attached a GOS port that I wrote some time ago that allows using µGFX inside of a Qt application. The Qt stuff is all C++ as well just like your FreeRTOS C++ wrapper. Have a look at those files. Maybe that helps: gos_qt.h gos_qt.cpp Note that I wrote a simple wrapper class around the QThread class because the QThread class doesn't offer certain things that are required. I assume that the FreeRTOS C++ wrapper won't require that workaround. Please don't hesitate to ask if you have any other questions. We're happy to help where ever we can. Just currently on the road so not much I can do right now.

Hello Victor, If it's a true C++ wrapper then that means that the C interface should still be accessible. Therefore, the current FreeRTOS support should still work perfectly fine for you and you'd probably just encounter a build issue. If the C functions are not accessible then the easiest way would be to create a new GOS port for FreeRTOS C++ (so you'd create gos_freertos_cpp.h/c) and use the FreeRTOS C++ interface in there. Optionally you could keep using the existing gos_freertos.h/c file and just add a macro to the configuration file which is something like GFX_FREERTOS_USE_CPP and in the existing port you'd use #if and #else to add your new FreeRTOS C++ wrapper code along the existing C one. I hope that helps.

Sounds good! Keep in mind that you can develop your entire µGFX application on a desktop computer as you can compile native Windows, Linux, Mac OS X and BSD applications. Those are native applications that only use the µGFX library. We don't use simulators or emulators. This means that every single pixel that you see on your desktop will be exactly the same on your hardware target afterwards.

Thanks for sharing your results. Exactly as expected

There's absolutely no reason to feel dump. You cannot possibly know everything. Please don't hesitate to ask if you have any questions, we're always happy to help. You might consider using GIF instead then. It's a lot easier on the CPU and requires about one fourth of the memory that you need to decode a PNG. Our GIF decoder supports transparency. Other than that the common (and strongly recommended) approach is to use bitmaps (regular BMP formats). The bitmaps that have less than or exactly 8 bits per pixel have color palettes. This way you can simply exchange the background color in the BMP before drawing it to the screen. That is how most GUIs are implemented and that is how we implement the GUIs for our customers whenever possible. BMPs come with almost no overhead at all. They are stored uncompressed but as you're talking about icons the size shouldn't be a problem. We also use the same technique for GUIs where you can change the theme (the color scheme) and when the user can click/press the icon as you can simply adjust the background color again to give it a "pressed" effect. Modifying the palette is a very fast operation as well. In the example here, we use the same bitmap (the same BMP image is only one time in the memory) and we render it with 7 different color schemes. Note that you can use bitmaps with more than just one color as well - You can do the same with "colored" icons:

We'll have a look at this, but that might take a few days. Stay tuned! If you have any questions in the meantime please don't hesitate to ask. We're happy to help wherever we can.

Hello @Grobatt and welcome to the µGFX community! Running µGFX on a CC3200 is no problem at all. After all it's a Cortex-M4 processor and µGFX runs very well on those (probably the best supported platform). You definitely won't have any issues running µGFX on it. When it comes to PNG: Just as with everything else we wrote our PNG decoder completely from scratch ourselves to ensure that everything uses as little resources as anyhow possible. However, due to how the PNG format works you require 32 kB of RAM just for the sliding window for decoding the PNG. In addition to that there's a few more kilobytes requires for the deflation buffer and similar things so all in all you need about 37 kB or RAM to display a PNG image of any size. You can find a very detailed description on the memory requirements for rendering a PNG image here: https://wiki.ugfx.io/index.php/Images#PNG In general you definitely don't want to use PNG images on any smaller embedded platform. Is there a particular reason why you'd like to use PNG images? There are plenty of other options. If you explain your use case we might be able to give you a bit more guidance. Yes, you can just use the GDISP module. The configuration file allows to individually enable and disable every single module, feature and sub-feature. You can just enable the GDISP module and it doesn't have any dependencies at all. The µGFX library is very modular. It is possible to use just the GDISP module with no other dependencies for displaying your PNG image. You have to provide the corresponding gdispImage object (struct instance) and then GDISP can display it - it doesn't bother where it comes from. However, as you mentioned µGFX provides certain mechanisms to vastly simplify this. The GFILE module provides a generic, high-level file system abstraction API. The GFILE module itself is very small and does't do anything besides providing wrapper functions. Once you enabled the GFILE module in your configuration file you can choose which file system(s) you want to be using. We do offer a FatFS wrapper that allows you to display a picture by using just two lines of code: gdispImage myImage; gdispImageOpenFile(&myImage, "/path/to/myImage.png"); gdispImageDraw(&myImage, 0, 0, swidth, sheight, 0, 0); If you prefer using something more lightweight you can have a look at ROMFS. It's a file system we wrote ourselves that allows loading any file from your ROM (eg. your micrcontrollers flash). We provide the corresponding tool called file2c that allows converting any file into a C array so you can easily include it in your microcontroller's flash image by just #including the file instead of screwing around with linker scripts. To answer your question: Yes, you can use just the GDISP module to display your PNG image. You can optionally use the GFILE module if you want to make your life easier (you can either use our built-in FatFS implementation or your own one). The GWIN module optionally offers you a window manager with widgets. There's an imagebox widget that would allow you rendering your PNG image as part of the widgets system maintained by the window manager so you don't have to manually take care of redrawing it but the GWIN system will pull in more dependencies such as the GQUEUE module (and the GINPUT, GEVENT and GTIMER module if you have touch/mouse input). But not to worry: If you really need those features then go for it. The µGFX library has been written to be as modular and as lightweight as possible. Every unused feature (and sub-feature and sub-sub-feature and ...) are excluded before compilation by means of the pre-processor. I hope that answers your questions. Please don't hesitate to ask if you have any further questions. We're happy to help!

Can you please attach your Keil project as a ZIP or RAR archive so we can have a look? Please don't forget to clean the project first (Project -> Clean all targets) to keep unnecessary large binaries out of it.