inmarket

Thank you. It looks like the GCC bug rears its head again. I will look to see if I can add something to turn off that error/warning on GCC.

gwinImageOpenGFile

It looks like I got that wrong. It appears it always closes the file when the gwin object is destroyed. This is not so nice. While it could be changed to match the behaviour above that is a change in existing behaviour so I am reluctant to do that before the next major version.

The gwin virtual keyboard supports layout's. A layout is a structure that allows you to specify what key you want where. There is a gwin function call that allows you to set the kwyboard to use your custom layout. A numeric keypad should be an easy layout to define.

From memory... If you open the image using the filename in the gwin call it will automatically close the file handle when the gwinOmage object is destroyed. If you pass on already open GFILE to the gwin call I suspect the original file is not closed when you destroy the gwin object. The final reference however is the source code. Once I get time later I will check if my memory is correct but have a check for yourself too.

No, the image is not closed after drawing. You can redraw as many times as you like until either the image or the GFILE is explicitly closed. Have a look at the animated image demo which uses this to display sequential frames from a gif image.

Yes that should be logFile in the if statement.

You still haven't added the test for pe being NULL ie <code>if (pe && pe->type == GEVENT_GWIN_BUTTON)</code> What you have currently may be hard faulting because of the lack of the test for NULL.

Great solution Joel. Yep, that really is the best way to handle it.

Great work on creating your own widget! There are a couple of errors in your allocation of the text buffer. There is already a text edit in the gwin module. See demos/modules/textedit and demos/modules/gwin/virtual_keyboard If you compare the source for the gwin textedit to yours you will see the similarities and the differences.

Problem 1: When you called geventEventWait you passed a timeout patameter of 0. This means it can return immediately with a timeout if there is no event waiting. This makes geventEventWait return NULL. You have not tested for NULL and could hard fault on the next line on some processors. Problem 2: calling geventEventWait with a 0 parameter is not good on many operating systems as it does not allow other threads to run - particularly on co-operative operating systems such as RAW32. While FreeRTOS is not one it is still bad practice. Problem 3: You are calling gwinAttachToggle inside the loop. This call only needs to be called once and should not be inside the loop. The solution to the first two problems is to either specify a (non-zero) timeout and test for NULL, or use TIME_INFINITE for the timeout value. When using TIME_INFINITE geventEventWait will never return NULL. Solve those problems first and test again.

RGBA is not currently officially supported but is actually very easy to do for displays that support it. Just set the uGFX pixel format to RGB888 and define your own macro to define colors with alpha. This works because uGFX uses 32bits for a RGB888 color and doesn't mask the top bits when passing it to the driver. What is not supported is color mixing using the alpha values by uGFX itself. The alpha values can only be directly used in the driver.

uGFX is designed to work with most c compilers even unknown ones. The compiler list is largely to work around problems that particular compilers have. I believe that someone has already had uGFX working on the pic32 - search the forum for more information. In any regard, try it as it should just work. If you set GFX_SHOW_COMPILER to TRUE in your gfxconf.h file it should print out a message showing what compiler it thought it detected.

Time #1: GFILE_NEED_FATFS needs to be TRUE even if you are using GFILE_FATFS_EXTERNAL_LIB. Other than that you need to debug to find where gfxHalt is being called. gfxHalt is only called by uGFX when it detects you (or the hardware) have done something very wrong.

The STM32LTDC gdisp driver by default uses DMA. Perhaps there is a conflict there. Some drivers that use DMA support a config variable or have a setting in the driver config file that specifies whether dma should be turned on. I can't remember off the top of my head if the stm32ltdc driver has such a flag but you can check in the source code. This won't have anything to do with GADC.

The new code is already in the git repository. Interesting with the focus. That sounds like a redraw order problem between controls. I have no idea on that one currently.

PS. The symptom you were seeing previously was likely the maximum size bug I found.

You should not define GFX_COMPILER unless the build complains about not being able to autodetect the compiler type. Similarly anything using the default value (eg GFX_EMULATE_MALLOC) doesn't need to be defined and probably shouldn't be defined in order to be most future compatible. How did the textedit test go with the new code?

The current design to only send an event on button up is intentional. Particularly on touch screens pressing can be inaccurate. One way of handling that is to only send the button event if the button is pressed and released while the touch is over the button. Even desktop environments often to the same. To demonstrate this press over the button and while holding the touch/mouse down slide off the area of the button. You will see that the button remains in the depressed state. When you lift off the touch (release the mouse click) you will get one of two responses; if you were over the button on the release you will get a button event indicating the button was triggered. If you release outside the button area the button returns to its unpressed state and no event is sent ie the button press is effectively cancelled. If you add the extra event send on the button down you will need to either turn off the button cancelling feature or be able to handle sometimes not recieving the release event.

I have made changes to the TextEdit which should fix these problems. I additionally found a strange bug to do with the maximum size. Changes: gwinSetText() can now be used even with static text. It will be converted to dynamic text automatically when the text is actually edited. Setting the maximum length now only affects adding characters using the keyboard. API level calls (eg gwinSetText) or deleting characters ignore the maximum length. If the maximum length is set to zero then there is no restrictions on length. If memory allocation fails while trying to edit the text, the text is left unchanged. This should give safer behaviour in low memory situations. The code has been adjusted and compiled but I have not actually run it to test it (just due to time constraints currently). Can you please test this and let me know if it works correctly in all the situations specified above.

I have finally spent some time looking at it... Whilst I haven't done a full debug yet I can see a problem that can be caused on reallocating of the string buffer (due to an edit) most particularly if you are on ChibiOS. The reason ChibiOS is a particular problem is that its realloc call requires the size of the old buffer (yuck!). Once gwinSetText has been called however we have lost our original buffer size. If you are running ChibiOS it would also explain why you are seeing the problem but others are not and why it didn't appear during our development testing. I will look at coding a solution in the next day or so.

It is running late due to heavy workloads. At this stage there is no update on when the new release will be ready but the latest code is always available in the repository. A new major version (v3.0) is well under way but the changes are quite major internally and it is taking longer than we initially estimated.

Did you do a make clean to remove object files from previous compile attempts?

Sorry. Just short of time currently. I will try and look at it later today.

Please turn on the define as above, do a rebuild all and then tell us what compiler uGFX thinks you are using.