Search Results

Search results 1-20 of 68.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Hi Sven, Yes, it has. Okay, I see. Thanks for your reply. Regards, Kenmux

  • Hi, These days I try to draw custom 8-bit bitmap with alpha using GUI_DrawBitmap(), but it seems NG. The image (with alpha) is some like: forum.segger.com/index.php/Att…20fdf4f8ea3c9918cc170bb12 To save ROM space, i index the pixel data to 8-bit c file from the one converted by BmpCvt.exe, with the settings: C Source Code (14 lines)Also, I attached the file as "overlay_image_status_26x26x8.zip". Then I draw it using the code: Source Code (3 lines) The screenshot: forum.segger.com/index.php/Att…2…

  • Bad memory access in GUI_Init()

    kenmux - - emWin related

    Post

    Hi Sven, Okay, I see. Thanks for your work though. Regards, Kenmux

  • Bad memory access in GUI_Init()

    kenmux - - emWin related

    Post

    Hi Sven, It's MIMXRT1052. The project is built with Keil μVision5. Attached is the code for config MPU. Thanks, Kenmux

  • Bad memory access in GUI_Init()

    kenmux - - emWin related

    Post

    Hi Sven, I check the project over and over again and still the same story. For I step into this issue using the source codes, so it should not be the library. If I set ITCM read write to MPU, then the code runs well. (Yes, this bad memory access occurred, too.) For the address of ITCM start from 0x00000000, and we decide to put crucial code to it. So this issue makes the code crashing from the very beginning. Attached's the config file & OS specific file. I've removed the file header for the lic…

  • Bad memory access in GUI_Init()

    kenmux - - emWin related

    Post

    Hi Sven, Today I step into the vary functions. First, the values in the struct pointed by GUI_pContext seems okay after first initial: forum.segger.com/index.php/Att…20fdf4f8ea3c9918cc170bb12 But, after calling GUI_LOCK() in the function GUI_SelectLayer() all cleared to 0: forum.segger.com/index.php/Att…20fdf4f8ea3c9918cc170bb12 by this: Source Code (1 line)It seems a context switching occurred. Then this pointer GUI_pContext->LCD_pColorIndex (its value is 0) is dereferenced.

  • Bad memory access in GUI_Init()

    kenmux - - emWin related

    Post

    Hello, Recently, I encountered an annoying issue causing freezing. It seems like dereferencing a null pointer. Please refer to the image below: forum.segger.com/index.php/Att…20fdf4f8ea3c9918cc170bb12 It appears to happen in a call to LCD_INIT->GUI_SelectLayer->GUI_SelectLCD->LCD_UpdateColorIndices->LCD_SetColorIndex. Within that function r1 is loaded from a location with an offset of 0x3C, so probably a structure member. The content is loaded in r1, but is zero. The next instruction (see yellow…

  • Okay, got it. I'm not sure about it. I'll change the macro value as you post. Thanks for your reply, Sven.

  • Okay, I see, thanks for your reply. As our product is shipping soon. It's impossible to upgrade emWin.

  • Hello, Today I work with the issue about MULTIEDIT cannot display the "!" and """. Here's my finding: The MULTIEDIT is told to display "!" or """ from the key buffer after calling GUI_StoreKeyMsg(). There is a conflict, as the ASCII code of "!" is 0x21 (aka 33), which is the same value as the functional key "PGUP"; also, the ASCII code of """ is 0x22 (aka 34), which is the same value as the functional key "PGDOWN": Source Code (2 lines) Now in my project the handling for GUI_KEY_PGUP and GUI_KEY…

  • Hello Sven, Awesome! Thanks for your reply!

  • I implemented list-wrap by myself at last. I cannot find a better way to solve this problem. Appreciate any solutions.

  • Very, very embarrassed, at last I found the point: calling this function before calling GUI_Init()...

  • Hello, The system locks up (Data Abort) after calling GUI_UC_SetEncodeNone(). I checked the source code, and found nothing could be the problem. Anybody ran into this issue? Kindly please share the solution? I use FreeRTOS v9.0.0, and emWin 5.44. Thanks in advance!

  • Update: the error message is gone if not calling LISTBOX_EnableWrapMode(). But actually it is needed. So, what should I do to eliminate this error? My emWin version is: v5.44b, using FreeRTOS.

  • Today I set GUI_DEBUG_LEVEL as 3, and implement the function GUI_X_ErrorOut(). And I found calling WM_DeleteWindow(_hListbox) causes an error message: GUI_Alloc.c:Block to be deleted is already locked in _Free(). Why this came out? Any ideas? By the way, I used LISTBOX_SetOwnerDraw().

  • Hello Sven, Yes, you're right. That can do the job. But, there's no callback for WM_HBKWIN at all. To be honest, there're only lots of functions calling graphic APIs. And they do not need redraw. I tried the steps: 1) GUI_EndDialog() 2) WM_MULTIBUF_Enable(OFF) 3) WM_DisableMemdev(WM_HBKWIN) 4) Make sure iMX 7 eLCDIF using the buffer emWin drawing to 5) Terminate task of main UI 6) Task of test UI running 7) The drawing of first calling of graphic APIs causes error To the point, a simple question…

  • Say, there're two different screens: one use DIALOG, another simply draw in the WM_HBWIN using Graphic APIs only. Then there's a requirement to jump from one screen to another. Currently, I did the job as steps: 1) GUI_EndDialog() 2) GUI_Exit() 3) GUI_Init() But it seems too heavy. Is there a light way to Switch from DIALOG to using Graphic APIs only?

  • Hello Sven, Thanks for your team's great work. Best Regards, Kenmux

  • Yes, that's it. The physical keypad has fewer keys for user to interact with UI. And the virtual keyboard can have several kinds: alpha, digits, ...