Bugs or issues (maybe)

[wctltya]

Hi,

1. I set (by accident) a negative value for a Label width. The program crashes, don't dug into, but the uC resets after while. It's not WDT reset, because it's timeout is longer.

2. In a textedit widget I set the value (received by an interface in a buff) with gwinSetText(textedit_handler, buff, TRUE); , then it can be edited by the virtual keyboard. The program crashes on pressing any keyboard button, if the string in the buff is empty (i.e. buff[0] == 0). The pressed button still in depressed state, no char is displayed on the textedit and the uC resets after a while. Again it is not WDT reset. It is enough to have a single char in a buff in order to work properly. Didn't dug into as well. 

[inmarket]

1. That behavior is reasonable. uGFX is designed to be small so does not do a lot of parameter checking. Sending a negative width is actually a user program error and so a resulting crash is definitely possible.

2. We will look into this.

[wctltya]

On 4/2/2017 at 00:09, inmarket said:

2. We will look into this.

Hi inmarket, is there any progress on that issue?

BTW, I found that 

On 4/1/2017 at 13:34, wctltya said:

It is enough to have a single char in a buff in order to work properly

is not 100% true. For example 

....
ghTextedit_1= gwinTexteditCreate(0, &wi, 4);
....
gwinSetText(ghTextedit_1, " ", true);

and "back space" to clear " ", and then I type three chars ( for example '1',  '2' and '3') at 3rd, one or two more chars appears (for example '@' or ' 8'), depends of which textdedit widget is on focus - there are three on the page I'm talking about. For example the results is "123@" or "123 8". If I don't cleat the " ", then the more chars are displayed at 2nd typed char, i.e. third on the field;

Also if I set the text at creation time with 

wi.text = "1234";

then they displays:

first "1234@", second "1234" (correct) and third "1234?". All three textedit widgets are created in a loop for{} if it does matter. 

but If I set them with 

gwinSetText(ghTextedit[i], "1234", TRUE);

then all three works fine.

[wctltya]

@inmarket, any comments on my post above?

[inmarket]

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

[inmarket]

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.

[inmarket]

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.

[wctltya]

Thank you inmarket,

Just FYI - I'm running RAW32. The uC is Cortex-M4 with plenty of resources (Flash, RAM, FPU). The project is under KDS (single file including) with GCC compiler and the relevant gfxconf are: 

#define GFX_USE_OS_RAW32    TRUE
#define GFX_COMPILER        GFX_COMPILER_GCC
#define GFX_CPU             GFX_CPU_CORTEX_M4_FP
#define CORTEX_USE_FPU      TRUE
#define GFX_EMULATE_MALLOC  FALSE

And the heap size is set accordingly. I was wondering if the compiler shall be set to GFX_COMPILER_ARMCC? Please, let me know, if I shall turn on/off some other keys..  

[inmarket]

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?

[wctltya]

Thank you inmarket, 

Actually I've not tested it yet, because I'm very busy. But planed to be done tomorrow, and will let you know immediately. 

Edited August 9, 2017 by wctltya

[inmarket]

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

[wctltya]

And there is one more symptom I forgot to tell you - When the textedit wg text is set to "1234" (or actually 4 spaces in my workaround) and the marker is before the first or between them, typing is not inserting the new char, but replacing the existing one. And that works fine for me.

BTW another guy (one at lest) has been reported that issue before me. Don't have time to find his post right now.

[ronan_rt]

@inmarket can you share this code with me too? Im experiencing some textedit bugs. I made the keyboard appear UP and DOWN. For example: if the textedit is located at the top of the screen, the keyboard appear at the bottom. If the textedit is located at the bottom o the screen, keyboard appears at the top. WHen I am typing into a TOP (for example) textedit, close the keyboard (by clicking outside of the textedit, my routine), and click on a BOTTOM textedit, the keyboard opens and the LAST textedit FOCUS in front of my keyboard. This happen always when I have a previous textedit focused. How can I take this focus away?

[inmarket]

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.

[wctltya]

@inmarket So far so good  . Seems the Textedit widget works fine now. 

Thank you.

[wctltya]

@inmarket Sorry but seems there is another issue which happens when there are more textedit on a page.

I have 3 on a page, but lets assuming there are two (TE1 and TE2), both are limited to 4 chars.

Typing in TE1 up to 4 chars, clearing one or more etc. (I'm using virtual kb) is OK, then just focus the TE2(w/o typing), getting back to TE1, still OK;

But if:

1. I type one char only in TE2 (assuming TE1 is full) 

2. then getting back to TE1 and clear(backspace) one char, suddenly the limit for TE1 becomes 3,

3. then focus on TE2 and I can't type more chars, including replacing of exited.

The order (TE1 then TE2 or TE2 then TE1) doesn't matter. The starting number of chars entered in the first TEx also doesn't matter. Sounds like a "magic" relations between TE widgets.

There are many variations of that bug, hopefully I've described it well. But even I've not, play a bit and will see it.