Posts by SEGGER - Florian

    Hi Sarthak,

    Yes, WHEEL_MoveToPosEx() runs an animation but there is no interface to hook in custom code into this animation.

    My guess is, you want to create a GUI for selecting a date, and based on the month, you want to show a different amount of days?

    I think it would be more elegant to just maintain one wheel for the number of days and dynamically switch out the content list, based on the current month (i.e. based on the amount of required days).

    You can just react on the WM_NOTIFICATION_VALUE_CHANGED notification that is sent by the WHEEL to know when a different month/day has been selected.

    I hope this helps.

    Best regards,
    Florian

    Hi,

    Can you please go more into detail, what exactly you are looking for?

    You can find the entire public emWin API in the emWin manual and all public AppWizard-related API functions in the AppWizard manual.

    Best regards,
    Florian

    Hi,

    until we add such a function to emWin, one way to do this would be by drawing anti-aliased lines and anti-aliased arcs.

    However, the results won't be 100% accurate, as a slight difference in line thickness between the lines and the arc may become visible. High-resolution coordinates would also have to be used, so that the positioning of the lines and arcs is accurate enough.

    If your hardware supports SVG, using the SVG module would render the most accurate result. However, as not many hardware targets offer a vector-based GPU, this is most likely not a viable option for you either.

    Using a memory device to rotate the rectangle as Anthony suggested is memory intensive, but it is the solution that will offer the best results.

    Best regards,
    Florian

    Hi Andi,

    Currently this is not possible. The Bitmap Converter can only generate bitmap EMFs from GIFs. We may add support conversion from video input file formats to bitmap EMFs in the future, but this is not planned yet.

    To work around this, you can convert your videos into a GIF animation (FFMPEG can do this), and then you can convert with the Bitmap Converter into a bitmap EMF.

    Best regards,
    Florian

    Hi aristi,

    as for a file system on your target, I would recommend our own emFile. With the AppWizard installer comes a ready-to-use configuration between emFile and AppWizard, this is the file APPW_X_emFile.c. It is located in the directory C:\ProgramData\Segger\AppWizard...\Sample.

    Currently, it is not documented how to implement the interface to another file system, but if you take a look at the file, it is rather straightforward. You simply need to implement a handful of methods for basic file operations (open file, close file, etc.) as well as initialization of your file system.

    Also, at runtime, the microSD should be plugged in the PC where AppWizard is running, or in the target (RX72N Envision Kit)?

    In AppWizard play mode, you don't need to plug in the SD card to your PC. You only need to plug it in for exporting the external data to the SD card. Then, you can export and program the project onto your target and plug in the SD card to your target. The AppWizard project will load all the extern resources from your SD card.

    Best regards,
    Florian

    Hi TechGUI,

    Please the excuse the long delay.

    For this purpose, font merging has been added to AppWizard. There is an example on this available in AppWizard called HowTo_MergeFonts.

    Since AppWizard 1.52_6.44b, there is also a SETFONT job available that allows to change the font of objects during runtime. There is an example called HowTo_ManageLanguages that shows how to utilize this job to change between languages and fonts.

    In AppWizard, to view and open examples, go to "File -> Open example...".

    Best regards,
    Florian

    Hi Anthony,

    Please excuse the long delay. As of right now, we are not planning to add the SWIPELIST to AppWizard.

    AppWizard already offers swipable lists such as LISTBOX or LISTVIEW. The SWIPELIST also allows the attachment of widgets, but this can already be achieved with windows or screens as parent windows.

    Reacting on the selection of certain elements in the list can be done with LISTVIEWs/LISTBOXes too, so adding the SWIPELIST would not add much value to AppWizard, as it would not really make things easier but rather a bit more complicated to handle.

    The SWIPELIST has its place, but it is more of a widget that makes your life easier when you code a smartphone-like UI manually, not with a WYSIWYG editor such as AppWizard.

    If you really need a SWIPELIST in your project, you can add it manually through user code. I hope this helps.

    Best regards,
    Florian

    Hi aristi,

    My guess is that most likely your target file system is not properly set up yet.

    Which file system are you using on your target and can you confirm that it is correcty setup?
    Did you implement the file system layer between AppWizard and your file system (such as APPW_X_emFile.c)?

    Are you exporting the files correctly to your SD card? In the AppWizard preferences you can setup a media path, this should be the path to your SD card when it's plugged into your PC. You can then mark desired files as extern, and when you click "File -> Export external data", your external files will be written to your SD card with the correct folder hierarchy.

    Best regards,
    Florian

    Hi,

    What you are describing sounds like flickering, which is normal behavior when the display is updated frequently and there is no multi buffering or display cache enabled.

    Which display driver are you using? Some drivers support a caching mode that reduces the flickering.

    Alternatively, there is also caching handled by the window manager based on memory devices. This can be enabled by calling WM_SetCreateFlags(WM_CF_MEMDEV) after GUI_Init() and before creating any windows.

    Best regards,
    Florian

    Hi,

    Currently such a touch screen setup is not handled automatically by emWin. You would have to manually handle the input to these buttons.

    In your PIDConf.c (the touch screen interface), you would send the touch input events normally to emWin if they are inside the boundaries of the display. This is done with GUI_PID_StoreState().

    If they are not inside the boundaries, you can check if one of the buttons is pressed and handle this input however you need to. You could e.g. send a custom message to your main application window to perform certain commands based on the touch button. In an AppWizard project you would do this in user code and e.g. set an AppWizard variable to trigger a VALUE_CHANGED signal if the buttons need to interface with your AppWizard application.

    The emWin simulation also allows to add custom hard keys, where you can simulate these buttons on the PC as well. However, you won't be able to simulate hard keys within AppWizard.

    Best regards,
    Florian

    Hi Ravi,

    There is no such limitation. However, hundreds or even thousands of widgets on the same screen will have a big impact on performance. Because all the widgets that are visible will be drawn, so this will have huge impact on performance. In the PC environment, and on the hardware target this would be even more noticeable.

    Could you go a bit more into detail about what you are trying to do? I'm sure we can find a way that isn't so resource-heavy.

    Best regards,
    Florian

    Hi,

    There is no such limitation to the frame buffer size. Both sizes worked for me in an emWin simulation project.

    Of course, RAM can be a limiting factor. Because the display driver GUIDRV_Lin uses a frame buffer located in RAM and GUIDRV_FlexColor (when used with caching) allocates a cache in the GUI heap.

    Could you go more into detail about your setup (Simulation or target?, which display driver, ...)? It would help if you could provide your GUIConf.c/.h and LCDConf.c/.h files.
    What happens if you select the bigger size? Does emWin stop working or is your application not showing correctly?

    Best regards,
    Florian

    Hi Andreas,

    I'm afraid this is not so easily done.

    Unfortunately, the streamed bitmap header does not contain the USE_ARGB flag. Also, the bitmap created by GUI_CreateBitmapFromStream() references a specific bitmap function table based on the format read from the streamed bitmap header. E.g., if the format M8888I was read from the file, then the function table GUI_DRAW_BMPM8888I is set to the GUI_BITMAP.

    These bitmap functions use the ARGB/ABGR format determined by the preprocessor option GUI_USE_ARGB. In other words, it's either ARGB or ABGR which can only be changed at compile time.

    If you want to keep this generic, you would have to save the ARGB flag coupled with a streamed bitmap. Then, the bitmap data would have to be swapped during runtime, if the GUI_USE_ARGB define is not the same as the ARGB flag the streamed bitmap has.

    But I doubt that this much work would be worth it, especially since ARGB has been the default since V5.48 (more than 5 years old).

    I would recommend to convert the streamed bitmaps to ARGB once, then you would still be able to run your code base with older emWin versions (up to 5.48).

    I hope this helps, if anything is still unclear, just let me know.

    Best regards,
    Florian