Search Results

Search results 1-20 of 318.

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

  • GIF drawing performance

    SEGGER - Florian - - emWin related

    Post

    Hi, The following call was sufficient to run the animation: C Source Code (1 line) The "Period" parameter is 200 instead of 0. The parameter can be used for a fixed period between the images, but it has to be 0 when you pass a pointer to an array of periods, as you did with aDelayFlameSprite7. Best regards, Florian

  • Hi, Depending on the size of your GIFs, the timing could become inaccurate if decoding of the GIFs takes too much time. To boost performance, you could convert your GIFs into animated sprites which do not have to be decoded during runtime. They are essentially an array of bitmaps and time stamps and therefore much faster than GIFs. Select "File --> Create animated sprite from GIF" in the Bitmap Converter to convert your GIF into a sprite. GUI_SPRITE_CreateAnim() can be called to run the animatio…

  • Hi, The Spanish characters are within the ISO 8859-1 Western Latin character set, which are the characters 0xA0 up until 0xFF. Since the ANSI-C standard doesn't allow characters above 0x7F in the source code, you should rather use hex values for these characters. You can find a full table of the ISO 8859-1 Western Latin character set in the manual. To display these characters with emWin, add the hexademical value of the character to a string, like so: C Source Code (1 line) For the string "10°C"…

  • Hi, We have tried reproducing the issue with your command and the 6.10 NXP version of Bitmap Converter, but were not able to reproduce this issue. Maybe the issue is caused by the image you open in the Bitmap Converter. Can you send me an image to reproduce this issue? Thanks and best regards, Florian

  • Hi, You can add the "-hide" command to hide the window of the Bitmap Converter. This also works with the NXP version of Bitmap Converter. The "-exit" command simply closes the window, instead of hiding it. Below an example statement: Source Code (1 line) Best regards, Florian

  • Hi, There is no built-in function for this feature yet, but we will consider adding it in the future, because it is often requested and definitely makes sense. So for now, you would have to implement this behavior manually to the LISTBOX. You can do the text scrolling with an animation that "animates" an offset value to move the text. You also have to do the drawing yourself using this offset value in an OwnerDraw routine. I have attached a sample that does this and you can take it as a referenc…

  • Emwin_keyboard

    SEGGER - Florian - - emWin related

    Post

    Hi Saeed, Long press characters are defined in the keyboard's layout. You can remove the long press characters from the layout you are using. I am assuming you are using the predefined layout "KEYBOARD_ENG", you can copy the layout to another file to create your own custom layout. I have attached the layout KEYBOARD_ENG.c, in case you need it. You can remove the long press characters for a line of keys by passing "NULL" as the last argument for the KEYDEF_LINE structure (see "Pointer to longpres…

  • Arabic Keyboard

    SEGGER - Florian - - emWin related

    Post

    Hi Saeed, the default font does not contain Arabic letters. You have to change the keyboard's fonts to a font, that contains Arabic letters, otherwise they won't be displayed. Using the Font Converter, you can create an emWin font from a font that contains Arabic letters (e.g. Arial). The keyboard has two fonts, one for the keys and one for the small letters that are longpress keys. Refer to KEYBOARD_SetFont() and the keyboard widget chapter in the manual for more information. Best regards, Flor…

  • 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 …