Search Results

Hi, it seems the bug was introduced with V6.12. My fault, better call the WM_NotifyParent() after setting the new text. Regards, Sven

Hi, You are right, there was a bug related to setting a new string with the same length as the old string. If that's the case the widget wasn't invalidated. Your working is almost good. Instead of setting an empty string I would simply mark the window as invalid and tell its parent about the changed text (if required). C Source Code (10 lines)Regards, Sven

Hi, You can set a hook function with GUI_SetControlHook() to react on the three cache commands, LCD_CC_LOCK, LCD_CC_FLUSH and LCD_CC_UNLOCK. This hook function is called right before emWin performs the desired operation. You might try to react on LCD_CC_FLUSH and wait for your VSYNC signal before letting emWin continue and update the screen. Something like this: C Source Code (25 lines)Regards, Sven

Hi, sorry for the late reply. There were several fixes regarding BMP files in version 5.48 and 5.46. I could imagine this fixes the issue you are reporting. If possible try to get hands on a more recent version of emWin. Regards, Sven

Hi, I have noticed too late that you also provided your BMP files. I have checked it with your 8bpp BMP as well but it is also working. Regards, Sven

Hi Krzysztof, I have given it a try but on my end it is working fine. Which version of emWin are you using (check out GUI_Version.h)? Attached is my test application and the BMP I have used. Best regards, Sven

Hi, Unfortunately, this is not possible. Just imagine the rectangle to be send to the display has not the width of the display. Although we have a pointer to the start address we can not send it as one complete block as the memory is interrupted by pixel data not belonging to the rectangle (see attached). You might try to use the window create flag WM_C_MEMDEV when creating a window. This will result in automatic usage of memory devices. Every drawing operation into a window will be performed in…

Hi, If you are using the AppWizard which is provided by Renesas you can select a BSP for the RX65N from within the AppWizard. Go to Project -> Edit Options In the upcoming dialog you can select a BSP for the RX65N Envision Kit. The BSP will be located in the AppWizard project directory in the "Target" folder: c:\AppWizard\<ProjectName>\Target\ This can be opened with e²Studio. Regards, Sven

Hi, If you are referring to a WINDOW (ID_WINDOW_00) added with the AppWizard you could do the following: C Source Code (35 lines)Now the DROPDOWN is a child widget of the window (ID_WINDOW_00) and the DROPDOWN notifications are getting send to _cbWin. If you mean a "normal" WM-window you might want to refer to this example. Quote from alpe: “but other interaction overlap other windows and should hide the dropdown ” Not sure what you mean with that. Regards, Sven

Hi, The handle "pMsg->hWin" refers to is always the handle of the window where the callback function belongs to. In the AppWizard output files (e.g. ID_SCREEN_00_Slots.c) you will find the callback function as shown below. Here the handle "pMsg->hWin" refers to the screen with the Id ID_SCREEN_00 (most likely the main screen). C Source Code (3 lines) So, if you like add a normal emWin widget to this screen you could something like: C Source Code (8 lines) Now, the dropdown widget is a child wind…

Hi, Yes, you can do that. Maybe like this: C Source Code (5 lines)But without a loop you can not do things like animations ore create timer with emWin. Also, do not call GUI_Exec() from a callback function of a window. BTW, the following three calls shouldn't be required: C Source Code (3 lines) Multibuffering is not available when using the GUIDRV_FlexColor driver. The layer specific calls are not required if using only one layer. Anyway, since you have only one layer you had to call these func…

Hi, you can simply create another window over the existing one to draw over the rest. Try this: C Source Code (93 lines)Please note that any underlaying windows/widget will no longer receive touch input with the window in the foreground. Regards, Sven

Hi Tanaka, The reason for the slow drawing performance might be the following. Strings are getting drawn as bitmaps. These are getting drawing most likely line wise causing quite some traffic on the bus. Depending on the drawing mode emWin also has to read back pixel data from the display causing even more traffic. To reduce the traffic you can use a buffer, either a cache or a memory device. Instead of writing line wise to the display emWin will complete the drawing operation in the buffer and,…

Hi, yes, this is a known issue and is already addressed. The reason is the clipping rectangle clipping the drawing into the memory device. With the latest emWin version we have introduced a function to get around this. You might try to temporarily increase the window size to the size of the memory device before drawing into the device. After filling the device restore the window to its intended size. Try this before writing to the memory device: C Source Code (24 lines) Depending on the library …

Hi, Something like this (attached)? I create one window with a button. On button release I create a second window and delete the first. The second window has also a button. On press I create the first one again and delete the second one. Regards, Sven

Hi, Every time GUI_Exec1() has done something it returns 1. If there is nothing left to do it returns with 0 but has done something. Therefore a second call of APPW_Exec() is required. Quote from TechGUI: “When will such situation occur? ” As long as there is something to do you will stay in the loop. This can be keeping the touch screen pressed or constantly redrawing something. Regards, Sven

Hi, It seems that the GUIDRV_FlexColor driver is already compatible to this controller. We have two GUIDRV_FlexColor variants which are mostlikely compatible. These variant are GUIDRV_FLEXCOLOR_F66720 and GUIDRV_FLEXCOLOR_F66709. I would try the GUIDRV_FLEXCOLOR_F66709 first, this one supports already a lot of controllers. The only thing I'm wondering about is that the data sheet of the GC9A01A does not say anything about reading the display data RAM (DDRAM). If it is not possible to read out th…

Hi, you can set your own copy-buffer-function. In this function you simply do nothing. C Source Code (7 lines) You can call the LCD_SetDevFunc() at the end of LCD_X_Config(). Regards, Sven

Hi, The AppWizard automatically tries to enable multibuffering although it is not available. This causes automatic cache operations being disabled and the cache on driver side has no effect. We will double check this and change the behavior if necessary. Try to deactivate multibuffering by calling WM_MULTIBUF_Enable(0); after calling APPW_Init(). Regards, Sven

Hi, Quote from Andy_AN2: “1) _acExplosion_200x150 This video is making the problems. In his callback it does: case GUI_MOVIE_NOTIFICATION_PREDRAW: GUI_MULTIBUF_Begin(); break; case GUI_MOVIE_NOTIFICATION_POSTDRAW: GUI_MULTIBUF_End(); break; ” As you already discovered, simply replace the multibuffering calls by the LCDControlCache() stuff. Quote from Andy_AN2: “However in MOVIE_ShowFeatures.c there is no WM_MULTIBUF_Enable() instruction. So maybe these GUI_MULTIBUF_Begin/_End(); are some remaini…