Joel Bodenmann

We'd strongly recommend you using the snprintf provided by the GFILE module. This way you don't pull dependencies from your c standard lib and therefore your program stays as small as possible and your code is portable across any platform. More information can be found here: http://wiki.ugfx.org/index.php/GFILE#String_manipulation_.26_printing Regarding the actual issue: You are using the UI2 font. This is a font that we designed ourselves to both look well at small resolutions and to take up as little memory as possible. Following the second goal, we kept the character set at a minimum. This means that the font only contains alphanumeric characters, numbers and some other special characters. Most likely the degree symbol is not part of the font. @inmarket might confirm this as he's the one who designed the font. Also, the UI2 font isn't an unicode font. It wont help to enable unicode support there. So to get a degree symbol on your display you have to use a font that actually contains the degree symbol.

Hi, Sorry that you have to wait so long. We are currently putting all our time into developing the next version of the µGFX-Studio and handling support requests. We are maintaining this community forum in our spare time. If this is time critical, please consider submitting a support ticket to the Technical Support department where your issue will be handled as quickly as possible. Other than that I can try to make some time to have a look at this tonight or tomorrow evening. For that, please upload a ZIP archive of an entire µGFX-Studio project that allows us to reproduce the problem.

Can you let us know what you had to do in order to resolve the problem? This means that the frame buffer provided by your Linux host is using a 24-Bit pixel format while your µGFX one is configured to a 24-Bit pixel format. You can overwrite the default pixel format by setting GDISP_LLD_PIXELFORMAT in your configuration file. You should be able to figure out which format your Linux host uses first.

According to this topic, this appears to be working very well!

We are very glad to hear that you got it working! Also thank you very much for sharing the steps required to get it working. I am sure this will help many people in the future

Oh, I didn't think of that: You are not supposed to write your widget in C++. You have to write your widget in C and then create a C++ wrapper just as with the already existing widgets.

There is no problem with opening multiple GIF files at once. The only two things that can keep you from successfully opening multiple files at once are: You hit the maximum number of files that can be opened at once. That number is specified with GFILE_MAX_GFILES in the configuration file. Choose the number as low as possible to keep the resource requirements at a minimum. You don't have enough memory left to open more files. As the error return code you get from gdispImageOpenFile() is GDISP_IMAGE_ERR_NOSUCHFILE, you are most likely hitting the first issue. Just increase said number in your configuration file and you should be fine.

This is a long shot, but when listing the files you want to include (the #include lines), can you make sure that all the C++ code files are included BEFORE the µGFX code files?

Try just enabling unicode support in the configuration file and typing the characters directly in the file. Make sure that the file is UTF-8 encoded. That's how we successfully tested unicode support.

As @inmarket mentioned we can't help you without more information. All I can do right now is confirming that µGFX works nice in a C++ application. Currently I am using µGFX in a C++ project and it works very well out of the box.

That sounds like a make clean wound have fixed it Nope, actually I just took that post out of the spinbox widget thread (the first post in this topic was the last one there) and created a new topic out of if because it is in no way related to the spin box widget at all.

If you are using our makefiles you can just use OPT_LINK_OPTIMIZE to no in your top-level makefile to disable LTO.

It is possible (and recommended!) to have all your custom widgets in your project directory rather than inside the library directory. In fact, you never ever want to modify any code inside the library as updating becomes problematic. There's not much we can tell without a test-case that we can reproduce. My guess is that you forgot to add the source file of your widget to the files list in the makefile (or whatever you are using).

Using gwinRedraw() is indeed what should use if you have to force a redraw yourself.

What operating system are you on? We had similar issues before, a simple upgrade to the latest version of the Cygwin toolchain fixed it.

You can have a look at the default drawing routine implementation of the label widget. It allows resizing the widget to fit the text. However, we discourage doing that - really. It goes against the µGFX philosophy. A widget is not supposed to resize itself. The window manager is responsible for the positioning and dimensions of the widgets. To resize, the widget must call the window manager function gwinResize() which will cause a lot of things to happen: It will have to verify the validity of the new dimensions, move the widget if it hits the clipping region, redraw any widget that is now becoming visible and so on. Additionally, it will also issue a redraw of the widget that called gwinResize() and therefore render the widget twice. To overcome some of these problems (including crashes!) we restrict the label widget to only grow larger. If you are writing your own widget you can auto-size it in the gwinCreateXxx() function. The label widget does that too. Note how the auto-sizing happens before _gwidetCreate() is called and therefore before the widget is being submitted to the window manager. @inmarket might have some additional things to say to this but in my opinion you really don't want to mess with things like that. The µGFX library has been written to be as resource friendly as possible to target embedded systems which usually feature static GUIs. It's possible to save a lot of memory and CPU cycles but that imposes these kinds of limitations.

You are not supposed to do that. The window manager is responsible for the positioning and the dimensions of the widgets that it maintains. A widget is not supposed to change its size by itself. May I ask why you would want to do that anyway? The µGFX library has been written to be as small and as fast as possible. The sizes of the images you want to be using for your buttons should be well known at compile time. The µGFX-Studio takes care of that for you and automatically adjust the size of your button to the image size if you select the image rendering routine.

Very nice, great work! Can't wait to see and try the finished implementation of this. When text is being truncated, are you adding some indicator like "..." ?

Thanks for getting this done so quickly! I will have a look at it tomorrow and let you know. If you really hate your life you can enable -pedantic. But the warnings I got I got from regular GCC while compiling on win32. When developing something like a widget you definitely want to use the Windows/Linux/MacOS port, otherwise you have to flash your target each time and debugging is a pain too. Also I got crashes with the spinbox that was supposed to show the days of the week. However, I simply commented it out and didn't investigate due to not having a whole lot of time. I'll try again with the new version tomorrow and let you know how it's looking.

The two most likely issues that cause this error are: Your Linux kernel has not been compiled with framebuffer support or it isn't enabled Your Linux framebuffer is in a non-standard location. Have a look at /boards/base/Linux-Framebuffer/board_framebuffer.h. The board file looks for /dev/fb0 and /dev/fb/0 by default.

I took a closer look at the code. Here are my thoughts: The gtimerInit() function must go into the Create() function. Initialization should only happen once. After that you can use gtimerStart() and gtimerStop() at any time as you are doing now. The callback functions you use with the GTimer don't have the correct signature. They must be of the following signature: void foo(void* param). You are free to cast that void pointer to anything you like inside the function. The drawing function doesn't have the correct signature. It must be the following signature: void foo(GWidgetObject* gw, void* param). Some functions don't use the parameters passed to them. Suppress warnings by using (void)x; the upArrow and downArrow arrays in the drawing function should only be created/declared if GDISP_NEED_CONVEX_POLYGON is set to TRUE. Otherwise you get compiler warnings about unused variables. The configuration macros in the header to set the padding, border width, max. character count etc. should either get a prefix (eg. GSPINBOX_) or should be moved to the C file (recommended!) to avoid naming conflicts. That being said, I'd also like to say that I like your style of commenting things. Well done! If you handle the things listed above we can add your spinbox widget to the library

To further extend what @inmarket said: Until a few days ago, the GWIN module required you to use a mouse (touchscreen). You couldn't just use the toggle inputs alone. This is why you are getting the errors about the missing mouse functions, macros and so on. You need to enable the mouse support by settings GINPUT_NEED_MOUSE to TRUE in your configuration file. However, this limitation has been removed a couple of days ago, it's now possible to use the GWIN module just with the toggle buttons as inputs (without any mouse/touchscreen). To benefit from this behavior you'd have to grab the very latest version of µGFX (newer than the latest stable release 2.5) from the repository. Edit: It wasn't actually the GWIN module that required a mouse input device, it was the widgets module which is a GWIN sub-module. So it has always been possible to use GWIN without a mouse. Just not the widgets.

You are allowed and welcomed to optimize the drawing of your widget

What are you trying to say / ask? @inmarket said exactly that.

Ah, I missed that, sorry. In that case having a row per queue makes sense. Basically this would extend the current list widget with a row option. Sounds good!