Search Results

Hello Jan, The driver is not part of the STemWin library. In this case you would have to buy the driver directly from SEGGER. Regards, Sven

Hi, With the default skin of the BUTTON widget the functions BUTTON_SetBkColor() and BUTTON_SetTextColor() are not working. Either set the classic skin or use SKINFLEX properties to change properties like colors. If you overwrite the callback function of a widget you can call the default callback function (e.g BUTTON_Callback()) and then draw something. Here is a brief example how this could be done: C Source Code (81 lines) Best regards, Sven

Hi, yes, you can set the TEXT object into decimal mode and use a mask to set the position of the decimal point. With a mask of "0.00" you can display values up to 9.99. As it is only possible to set integers you have to set 999 for the value above. Regards, Sven

Hi, Quote from JackO: “Does emWIN work with the GC9A01 Driver? ” Never had one of these controllers on my desk, but according to the data sheet it should work. It seems the commands of the GC9A01 are compatible with GUIDRV_FLEXCOLOR_F66709 and GUIDRV_FLEXCOLOR_F66720. GUIDRV_FLEXCOLOR_M16C1B8 should be correct, too. A cache is required, as there are no read operations possible (you already figured this out). I'm not entirely sure how it behaves with read functions being set. So, maybe you have t…

Hi, You have to link the "GUI-memory" into the SDRAM. How this is done depends our your linker. emWin will allocate memory only from the block set with GUI_ALLOC_AssignMemory(). Here is an example from a GUIConf.c which does it. C Source Code (48 lines) If you are using the GUIDRV_Lin driver you might also want to link the frame buffer to the external memory. This is most likely done the same way as with the "GUI-memory". Regards Sven

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