Search Results

Search results 1-20 of 962.

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

  • Hi, Attached is a short example. The reason on side is most likely related to the GIF. Try to open the GIF with GIMP (or any other image editor tool) and un-optimize the GIF. Most GIFs are saved optimzed which means they store only the difference to the previous image. Unfortunately, this results in a strange output when only a sub image gets drawn. Regards, Sven

  • Hi, Per default the WINDOW widget and the simple WM-window do not manage IDs. Add the following to your window callback: C Source Code (3 lines)Regards, Sven

  • Hi, thanks, I*ll give it a try. Quote from Andy_AN2: “Unfortunately I am unable to provide you a demo example. What hardware should I use? ” I meant something like a single-file-example which show how you serialize the screen and save it. Not a complete project. Anyhow, I think the information you have provided are sufficient. Regards, Sven

  • Hi, this can have multiple reasons. It looks like the GUI memory gets overwritten at some point. Or the SDRAM is not working correctly. Can you post the rest of the dialog? Do get into the case WM_INIT_DIALOG within _cbDialog()? Regards, Sven

  • Hi, can you send me an example which shos how to reproduce the behavior? Also your configuration file (LCDConf.c/.h GUIConf.c/.h) would be interesting. Regards, Sven

  • Hi, Indeed, without the source code this gets pretty hard to debug. Unfortunately, I have not a real idea why it stops working. Does the client still sends framebuffer update requests? The server sends data only on request. Which client are you using? Regards, Sven

  • Hi, I gave it a try and it is working fine. Which version of emWin are you using? It might be that there was bug in an older version and is fixed now. Try to get access to a more recent version. Regards, Sven

  • Hi, Unfortunately, the GUIDRV_BitPlains driver doesn't support this function. We will add this in a future version of emWin. For now you have to store the framebuffer addresse on your own and write a little function to access it from somewhere in your application. Regards, Sven

  • Hi, The first choice on a STM32F7 should be GUIDRV_LIN_32. With this driver you will experience the best performance. The reason is that with 32bpp no conversion is required from the internal format emWin works with (32bpp) and the framebuffer format. Of course, the framebuffer needs to be configured for 32bpp and it will require more RAM. I wouldn't expect a rotated driver faster than one with default orientation. What kind of bitmap are you displaying? Can you send me the bitmap? Is the hardwa…

  • Hi, the GUIBuilder should wrap color values with a macro like: GUI_MAKE_COLOR(0x000000FF) // Red This macor converts the given ABGR value into the proper byte order. Regards, Sven

  • Hi, I think this is related to GUI_EnableAlpha(). Between V5.44 and V5.50 where some changes regarding the alpha module and this behavior should be fixed. Unfortunately, there is not much you can do about it, except of using a memory device or a bitmap for the background. Regarding GUI_USE_ARGB, I highly recommend to use a library compiled with GUI_USE_ARGB 1. This has the best performance on STM32 devices. Regards, Sven

  • WM_SetUntouchable

    SEGGER - Schoenen - - emWin related

    Post

    Hi, OK, now I got it, I guess. Try this: C Source Code (151 lines) In WM_INIT_DIALOG of _cbDerivedDialog() I create another window which is transparent. This window will catch the input outside _cbDerivedDialog() and do nothing with it. After creating this window make sure that all dialogs which should still receive input are on top (at least over the transparent window). Regards, Sven

  • Hi, I changed the line for setting the color in _LISTWHEEL_Draw() into C Source Code (1 line)and it is working. Depending on the color format emWin uses internally, the alpha bits can be 0x00 or 0xFF for opaque. If the library is compiled with GUI_USE_ARGB 1 an alpha channel with 0xFF means opaque. If it is compiled with GUI_USE_ARGB 0 the bits are inverted (0x00 is opaque). When GUI_USE_ARGB is set to 1 GUI_GREEN is defined as 0xFF00FF00. 0xFF00FF00 ORed with 0x80000000 is still 0xFF00FF00 resu…

  • Hi, I can't say if this is related to the font. I don't have the font. Is it possible to send me the font? If this is a free font, where can I download it? Regards, Sven

  • Hi, please don't open threads with the same topic/question multiple times. Regards, Sven

  • WM_SetUntouchable

    SEGGER - Schoenen - - emWin related

    Post

    Hi, If I get you right you want to make sure that the initial dialog (the one with _cbDialog) don't receive input when the derived dialog is created (_cbDerivedDialog), right? To achieve that you can simply make the derived dialog modal: C Source Code (27 lines)Regards, Sven

  • Hi, I can't reproduce the behavior. With the code below I can display the string with a red background ending pretty much directly with the last character. I had to adapt the GUI_RECT because it didn't fit on my screen. C Source Code (16 lines)Are you using a stock font of emWin or a font created with the Font Converter? Regards, Sven

  • Hi, Unfortunately, there is no way to reduce it. The information is required to distinguish between the different types of characters. Since we cover the UC ranges from 0x0000 to 0xFFFF this table gets quite large. Regards, Sven

  • Hi, Yes, when enabling BIDI support emWin needs more ROM because the BIDI algorithm needs some sort of conversion table. So, no mistake from your side. Regards, Sven

  • Hi, Unfortunately, it is not possible to rotate images directly with emWin. But, you can rotate memory devices. You need two memory devices. One which holds the image to be rotated and another one as destination which will contain the rotated image. Just refer to the API description of the GUI_MEMDEV_Rotate() functions in the user manual. Please note that the devices used for rotation have to be created with 32bpp color depths. Regards, Sven