Search Results

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

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

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

Hi, I'm not sure if I get you right. You have a dialog with LISTVIEW and a BUTTON. When pressing the BUTTON you create another window ("A") which is the child of the dialog. After creating "A" you want to get the handle of the LISTVIEW from within the callback function of "A". To do that you have to get the handle of the parent of "A" by calling hParent = WM_GetParent(pMsg->hWin) in the callback function of "A". With the handle of the parent you can retreive the handle of the LISTVIEW with: hIte…

Hi, Not sure what is going wrong. I gave it a try and everthing is fine. To rotate the display use the following: GUIDRV_LIN_OSY_24 - Rotate counter clockwise GUIDRV_LIN_OSX_24 - Rotate clockwise GUIDRV_LIN_OXY_24 - Rotate 180 Which device are you using? Regards, Sven