Search Results

Search results 1-20 of 613.

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

  • Hi, You can set a callback for each menu and react on WM_MENU and MENU_ON_OPEN. Now you can move the window (the menu) to any position. You can use this one as a reference: C Source Code (33 lines)Regards, Sven

  • Hi, You could set a callback function for the WM_HBKWIN. Within this callback you can use the standard graphics API (just like in any other callback). Regards, Sven

  • Hi, I gave it a try. I experienced the same as you did, but only a few times. Most of the time it was working. We will inverstigate what might causes this. Please try to create a different font first (just within the FontConverter, no need to save it) and then create the desired font. Regards, Sven

  • Hi, I have no issue drawing a bitmap on button. No matter if a window gets on top of or not. Try the example attached. Regards, Sven

  • Hi, This is a pretty short example on how to switch between dialogs using WM_HideWindow() and WM_ShowWindow(). Olease give it a try and let it run on your hardware or in the simulation: C Source Code (182 lines)Regards, Sven

  • Hi, First you should know what color conversion is used in your LCDConf.c. Just search for GUICC_. This tells you what the best bitmap format is in regards of performance. GUICC_M8888I - Most common color conversion for 32bit per pixel, best image format is true color with alpha, r/b swapped, alpha inverted. GUICC_8888 - Pretty uncommon nowadays, best format is True color with alpha. GUICC_M565 - swappes r and b channel, depends on the LCD controller, best format is high color[565], red and blue…

  • Hi, Please try calling GUI_PreserveTrans(1) after selecting the device and GUI_PreserveTrans(0) before de-selecting the device. This should fix the behavior. Here is a changed version of your code: C Source Code (64 lines)Regards, Sven

  • Hi, The EDIT doesn't react on GUI_KEY_BACKSPACE in decimal mode per default. But you can catch the WM_KEY message in the EDIT callback function. Try this: C Source Code (100 lines)Regards, Sven

  • Hi, Please give the example attached a try. A PNG gets drawn with white as back ground color and a window on top. The window gets hidden and shown again each second. Regards, Sven

  • Hi, Do you create each 200ms a new dialog? Are these dialogs getting deleted at some point? But for now I can't say why it's getting slower. I would expect that you run out of memory at some point if these dialogs are not getting deleted. Regards, Sven

  • Hi, Try to call GUI_SelectLayer(LayerIndex) before creating the dialog. Regards, Sven

  • Hi, Try to change the following in GUI_FontDeltaa_CharInfo: C Source Code (4 lines)If first and last character are 0xFFFF emWin will never find the character placed on 0x0394. Don't wonder why there is a frame around the Delta. This is becasue you are using the demo version of the FontConverter. Regards, Sven

  • Hi, If the background is just plain black you could remove the transaprency flag of the button and fill it with black. Then draw the bitmap. If the mode switches from dark to bright simply fill the background window with white and in the callback of the button call GUI_InvertRect() (but still fill the button with black, it will get white). Take a look into the example attached. Regards, Sven

  • Hi, On the STM32F429 Discovery board the SDRAM starts at 0xD0000000. I'm not sure what exactly you should add to your .ld file. You could try out our eval package for this board, it includes a lot of our middleware and is configured ready to use. segger.com/downloads/eval/Segg…ry_CortexM_EmbeddedStudio All you need is Embedded Studio which can also be downloaded for free. segger.com/downloads/embedded-studio/ Regards, Sven

  • Hi, For modifying a font the FontConverter is required. With the FontConverter you can create a font in (almost) any size. It is not possible to reduce the size of the font on runtime. You also might refer to the TrueType fonts: segger.com/downloads/emwin/emWin_FreeType You could create an emWin-font from a TTF font on runtime which allows you to choose a different size. Regards, Sven

  • Hi, Unfortunately, there is no such function for the MULTIEDIT widget. But you can use the function below: GUI_WrapGetNumLines(pText, xSize, WrapMode); Pass this function the text to be displayed in the MULTIEDIT, the xSize of the area the text gets displayed and the wrap mode. Also, you should set the same font as using for the MULTIEDIT widget before calling this function. Regards, Sven

  • Hi, I gave it a try and was able to scale down the device by using the function GUI_MEMDEV_WriteExAt(). Unfortunately, we have found an issue when using a color depth if 1bpp for the LCD and configured emWin for ARGB mode (#define GUI_USE_ARGB 1 in GUIConf.h). This is fixed now and will be released with the next emWin version (V5.48). If you are using 1bpp color depths and the define is set to 1, try to get a precompiled library which was not build with GUI_USE_ARGB set to 1. With a color conver…

  • Hi, Yes, you are right. If two window use the same callback, a static device is not a good idea. Your solution with user data sounds good. But I don't see any problem if only one window uses this callback. If you create, fill, and draw the device within the paint event, I don't really see any benefits from using it. Why don't you draw directly into the window? It doesn't has such a big impact on the performance, but as said I don't really see a reason why drawing into a memory device instead of …

  • Hi, There are several issues you should try to avoid or get rid of. 1. As you already assumed, memory device coordinates are relative to the top left of the screen. This is because they are independent of the Window Manager and you have to add the screen coordinate of the window to position the memory device should be drawn. WM_GetWindowOrgX() and WM_GetWindowOrgY() will do the trick. 2. You create the memory device in WM_PAINT and fill it with white. The problem here is related to clipping and …

  • Hi, Do you have enough memory available for drawing PNG/JPEG file? The RAM requirement for PNG is: (xSize + 1) * ySize * 4 + 54 Kbytes For JPEG the RAM requirement is: xSize * 80 bytes + 33 Kbytes The memory gets allocated from the GUI_MEMORY which gets set by GUI_ALLOC_AssignMemory(). egards, Sven