Search Results
Search results 1-20 of 38.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Hello, what MCU are you using? I faced the same problem with STM32H7 MCU using precompiled object library v6.46. LISTBOX and LISTVIEW AppWizard controls (as well as those legacy widgets) are processing the motion perfectly in simulation but not on real hardware (sort of invalidation problem when redrawing after swipe). I even disabled on-chip 2D-accelerator to ensure the problem is not the hardware. At the same time WHEEL object (and also WHEEL widget) processing the motion in right way (both ho…
-
Hello, Quote from BramPeeters: “Sidenote: I am using stemwin, so I don't have access to the latest versions anymore I am afraid. ” The latest versions are compiled by SEGGER. You can find it here: emWin: STM32 microcontrollers. If your rectangles are not constant, the first that comes to mind is using Memory Devices option. But you need a good enough high-performance MCU for fast rotating and enough memory space, depending on the size of your rectangles and how often do you need to rotate them. …
-
Hello, one of the boards I'm using is nearly with the same MCU (STM32H745) and the same library but "-OS0". Just checked in GUI_ConfDefaults.h that library compiled with GUI_NUM_LAYERS set to 1 (at least in v6.46). That means there is no Multilayer support. I'm afraid you can't change things. As alternative maybe you can try to use Softlayers feature, but of course it would work slower. Also it is not clear from the manual whether Softlayers work without Multilayer support...
-
Hello, GUI_TOUCH_SetOrientation() is intended to be used with pure analog touchscreen without a controller connected to your MCU. In this case you should just pass some info for the analog touchscreen driver using dedicated APIs so emWin could calculate the conversion factors from ADC data into the touch coordinates. But if you are using a touch controller that is providing a digital data using dedicated bus, and you are calculating the coordinates and passing it directly using GUI_PID_StoreStat…
-
Yes, I'm using STM32 and just checked WM_NOTIFY_VIS_CHANGED is not working cause it is precompiled library with WM_SUPPORT_NOTIFY_VIS_CHANGED set to 0. If you're using emWin sources you can just rebuild it with WM_SUPPORT_NOTIFY_VIS_CHANGED set to 1. If you're using binary precompiled library and you see this defined as 0 you can't change things. Then just use WM_INIT_DIALOG.
-
Hello, just checked WM_INIT_DIALOG is called every time SHOWSCREEN job working even the screen is in persistent mode. It's a little strange as if you're using just emWin without APPWizard engine WM_INIT_DIALOG logically sent to a dialog only once when the dialog is created until it's been deleted. So you can use an approach you're using. But why not use interactions mechanism since you're into APPWizard? More elegant solution, it seems to me... upd: check the message WM_NOTIFY_VIS_CHANGED. I've …
-
Hello, yes, seems that APPW_JOB_SETBKCOLOR is not working when called from the code for the button object. But it is working within APPWizard interactions. So just create a variable in APPWizard (for ex. ID_VAR_BKCOL), then create an interaction with SETBKCOLOR job at your button on changing the value of ID_VAR_BKCOL. Then in your code just do APPW_SetVarData(ID_VAR_BKCOL, YOUR_COLOR), here you go.
-
Hello, seems to be setting a font for an items in a WHEEL object is working only in APPWizard simulation. Font you see in the WHEEL object is small cause it uses default font. So if you do not use default font in the other places of your code then simply call GUI_SetDefaultFont() when handling WM_INIT_DIALOG message in the callback of a parent dialog. If you're using default font that is different from the one in the WHEEL object then you can overload default callback for the WHEEL object. When …
-
Hello, just let me simply add another way to realize this. The mentioned external flash is a NOR-flash which can operate in memory-mapped mode. So we can just configure linker files and enable memory-mapped mode at the start of MCU code. Then we can deal with usual "C-code-style" fonts in Font Converter without adding an extra code for getting XBF-data.
-
Hello, you can change the color of the BOX object from your code with the AppWizard engine using variables and jobs. The jobs and conditions can be various depending on your code. Just for ex.: EMITTER: ID_VAR_BOX_COLOR SIGNAL: VALUE_CHANGED JOB: SETCOLOR RECEIVER: ID_YOUR_BOX Interaction parameters: attach variable ID_VAR_BOX_COLOR as a color of the BOX. Then you can set this variable within your code using APPW_SetVarData(), here you go.
-
Hello, I think this question goes beyond the scope of emWin like that. It is more about making appropriate drivers which will work with external flash (storing, reading data...) and making options in your linker files for placing data at corresponding sections within the flash. Since you use LPC you better should contact NXP forum.
-
Hello, I think the morph mode involves complete disappearance of a one bitmap and appearance from zero of another bitmap just because these bitmaps are assumed to be different not necessarily identical and differ only in size like in your case. Attached is just a piece of code in which motion and bitmap scaling are used.
-
Hello, then put it in this way: how to change the display orientation. There are several ways to do it. The fastest way is to implement this within your display driver. The code depends on your hardware and display driver you are using. The latest versions of emWin add the possibility to link drivers with desired orientations and switch between them (LCD_ROTATE_...() functions). Another way is to convert a video buffer by software using functions GUI_SetOrientation()/GUI_SetOrientationEx(). This…