Joel Bodenmann

http://api.ugfx.io/group___keyboard.html#gab49f100ac33eed532c18ca8529ab1bfb

Are you absolutely sure that you set the range of the font converter correctly to include those umlauts? Did you ensure that you have your file encoded as UTF8 and that that UTF8 support has been enabled in your config file? If you keep having problems after checking those things above, please attach your converted font file as well as your source font file to your next forum post.

No problem. Glad to hear that you manged to get it working

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: