Search Results

Hello, Could you send me a sample to reproduce this behavior and also which emWin version you are using? Best regards, Florian

Hi, You can write the contents of a memory device into a window using GUI_MEMDEV_WriteAt(). You should make sure to delete the memory device when it is not needed anymore using the routine GUI_MEMDEV_Delete(). It makes sense to do this in a WM_DELETE case in your dialog callback routine. Best regards, Florian

Hi, When a button is pressed or released, a WM_NOTIFY_PARENT message is sent to the parent of the button widget. So in this case, the MULTIEDIT would receive this message. You can also read about this in the user manual. To process the message, you have to set a callback routine to the MULTIEDIT that reacts on the WM_NOTIFY_PARENT message: C Source Code (28 lines) To set a callback routine to a widget, use WM_SetCallback(). Best regards, Florian

Hi, Is the button a child window of the MULTIEDIT? In my test moving the scrollbar of a MULTIEDIT did not affect the visibility of the button. C Source Code (8 lines) Can you send me a small example to reproduce this behavior? Thanks and best regards, Florian

Hi WitDai, Currently multiple displays are not supported by AppWizard and we do not plan to add this feature in the near future. Right now setups with multiple displays are only supported by standard emWin. The user manual provides information about how this can be done: segger.com/doc/UM03001_emWin.h…ayer_MultiDisplay_support Best regards, Florian

Hi, The routines LISTWHEEL_MoveToPos() and LISTWHEEL_SetPos() simply change the wheel position, but do not change the selection. LISTWHEEL_SetSel() should be used to set the selection. However, I just noticed that LISTWHEEL_SetSel() does not notify the parent with WM_NOTIFICATION_SEL_CHANGED either, which is definitely not intended. This will be fixed with the next bugfix release. Best regards, Florian

Hi, Quote from giusloq: “Probably the sentence in the manual explains why GUI_ALLOC_GetNumFreeBytes() doesn't return the same number after one WM_CreateWindow() and one WM_DeleteWindow(). This is ok, but the number should be almost the same with the use (opening and closing windows), otherwise a memory leak is really present. ” Have a look at the example below. You will see that the difference between the number of bytes before creating the window and after deleting it is 32 bytes. These are the…

Hi, What you are describing is not a memory leak, but normal behavior of emWin's memory management. You can find a description about emWin's memory management in the manual under "Configuration -> Memory management". I have attached an excerpt regarding block management. Also, from my point of view there is no need to delete the window by sending a message first, since the message would get handled directly after it has been sent. So it would make no difference if you call WM_DeleteWindow() in i…

Hi, BytesPerLine are calculated as follows: ((BitsPerPixel / 8 * XSize). The bits per pixel depend on the bitmap format. GUI_DRAW_BMPM8888I is a 32bpp format, therefore for your bitmap the BytesPerLine would be ((32 / 8 * 18) = 72. But the data in the char array is a streamed bitmap in binary format, instead of a normal bitmap. You also don't have to set up bitmap structures manually. I would advise you to use the Bitmap Converter, you can download a free demo version on our website. You simply …

Hi Josh, A few things are unclear to me. Do you have created the IMAGE widget with the AppWizard? If so, you cannot set a custom callback to that widget, only to widgets created manually with emWin. If the bitmap is just a simple icon, you won't have to pass the IMAGE_CF_MEMDEV flag since a memory device won't be necessary for a small icon. Also, I'm not sure why you are setting a custom callback to the IMAGE widget that has a WM_PAINT case. Note that when you are drawing in WM_PAINT of a window…

Hi BMD, Regarding your first question: I am guessing that a press at the edge of a button results in the touch input being moved out of the BUTTON window. When a button is pressed and the touch input is moved out of the window area, the parent window will not receive a WM_NOTIFICATION_CLICKED message (not even when the touch input is being moved back into the window area and released). When the touch input is being moved out of a window, the parent window receives a WM_NOTIFICATION_MOVED_OUT. Re…

Hi, WM_SET_CALLBACK gets sent immediately to a window after its callback has been changed by WM_SetCallback(). WM_SetCallback() sends a WM_SET_CALLBACK message before returning the previous function pointer. So your application crashes because the function pointer is still NULL and gets called in cb_new. You can fix this by adding a WM_SET_CALLBACK case to cb_new that does not call cb_prev. Reacting on this message can be useful e.g. when setting a custom callback to the background window. In a …

Hi, the last parameter of APPW_GetFont() needs to be a pointer to a GUI_XBF_DATA structure instead of to an array of XBF data. Best regards, Florian

Hi, Quote from jhgorse: “Does this require manually drawing the widgets and their data with GUI_Draw*() calls? ” Yes, pretty much... I know that this can become tedious. An easier way that could work would be to overwrite WM_PAINT, set the alpha value and call the default callback. But note that this would require a lot of performance. C Source Code (5 lines)By the way, you can only set a custom callback to emWin widgets, not AppWizard objects. A better way would be to copy the window to be blen…

Hi, the number of text entries is limited by the signed 32-bit integer limit (2,147,483,647). Best regards, Florian

Hi, I was able to reproduce the steps. Apart from the glitching fade out, the animation looks pretty good! As I mentioned, the FadeIn/FadeOut routines are blocking, that means you cannot execute an animation simultaneously to fading out the button with these routines. Instead, you should fade out the button with an animation. To fade the button out by yourself, you have to draw it manually (set a custom callback). The animation should "animate" a variable for the alpha value from 255 to 0 (0xFF …

Hi, If the dialog window has the focus, you will always land in WM_KEY, when a key message has been stored. So to avoid landing in WM_KEY, no key message should be stored. If there's no other way, you can add a guard to the WM_KEY case to control when the key is handled. Best regards, Florian

Hi, You're right, it doesn't make sense for these routines to activate it globally when it is deactivated for a widget. I have fixed the _EnableMotion... routines so that they only activate motion support when the OnOff parameter is 1. The SWIPELIST automatically activates motion support, since the widget is usually intended as a list, that the user can swipe through (hence the name). Motion support is only enabled upon the creation of the widget. So if you don't need motion support for a SWIPEL…

Hi, are you using the routines GUI_MEMDEV_FadeInWindow()/GUI_MEMDEV_FadeOutWindow()? These routines are blocking, that means emWin cannot continue with an animation while a FadeIn/Out routine is running. Therefore, they are not recommended to be used with animations. Can you send me an example that demonstrates your issue? Best regards, Florian

Hi, yes, that it is intended since there could be other windows/widgets in the application that could still require motion support. Best regards, Florian