Posts by cilmagemlu

Hello,

yes, you use the correct version.

Refer to the thread for details:

https://forum.segger.com/index.php/Thre…pack-for-STM32/

Hello,

the commands you listed probably relate to LISTWHEEL legacy widget not to WHEEL widget. The commands for WHEEL widget are not documented at all, and yes, they have undocumented values. Apparently default draw function WHEEL_OwnerDraw...() is not clearly described so you can't see how it does things without emWin sources. The only thing you can do is doing some tricks within WM_PAINT message or may be using WHEEL_SetOverlay()

Hello,

just had such a code based on GUI_MBITMAP_Create() sample under WIN32. For using in WIN32 simulation add opengl32.lib in the linker input.

#include "DIALOG.h"
#include "windows.h"


#define FILE_PATH "C:\\Image.dta"


HANDLE hFile;


GUI_MBITMAP * pMBitmap;


IMAGE_Handle hImage;


int _GetData(void * p, const U8 ** ppData, unsigned NumBytes, U32 Off) {
	HANDLE * phFile;
	DWORD NumBytesRead;
	U8 * pData;
	pData = (U8 *)*ppData;
	phFile = (HANDLE *)p;


	SetFilePointer(*phFile, Off, 0, FILE_BEGIN);


	ReadFile(*phFile, pData, NumBytes, &NumBytesRead, NULL);


	return NumBytesRead;
}


void MainTask(void) {
	GUI_Init();


	WM_MULTIBUF_Enable(1);


	hFile = CreateFile(FILE_PATH, GENERIC_READ, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);


	pMBitmap = GUI_MBITMAP_CreateEx(GUI_MBITMAP_DTA_EX, _GetData, &hFile);


	hImage = IMAGE_CreateEx(10, 10,
		GUI_MBITMAP_2BITMAP(pMBitmap)->XSize,
		GUI_MBITMAP_2BITMAP(pMBitmap)->YSize,
		WM_HBKWIN,
		WM_CF_SHOW,
		0,
		GUI_ID_IMAGE0);


	IMAGE_SetBitmap(hImage, GUI_MBITMAP_2BITMAP(pMBitmap));


	while (1) {
		GUI_Delay(50);
	}
}

Hello,

seems there's nothing wrong with your code, I'm using AppWizard V154_646 and it works fine on my side.

void ID_SCREEN_00__APPW_NOTIFICATION_INITDIALOG(APPW_ACTION_ITEM * pAction, WM_HWIN hScreen, WM_MESSAGE * pMsg, int * pResult) {
  GUI_USE_PARA(pAction);
  GUI_USE_PARA(hScreen);
  GUI_USE_PARA(pMsg);
  GUI_USE_PARA(pResult);


  APPW_SetVarData(ID_VAR_COL, GUI_GREEN);
}

Maybe you should check if you set a color within the properties of the progbar in AppWizard does this shows correct color without adding C-code.

Hello, Andy,

strange but somehow LISTBOX started processing the motion whereas LISTVIEW still not performing right. Maybe there is a problem with memory cache at the frame buffer area. I will deal...

In fact I also prefer to use LISTVIEWs instead of LISTBOXes as it is more flexible in their settings.

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 horizontal and vertical), like this...

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. Just create a memory device, then draw a rectangle into it, then rotate the device using GUI_MEMDEV_Rotate...() functions. There you can choose rotation speed and quality. Then draw the device on the screen. Here you go.

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_StoreState()/GUI_TOUCH_StoreState(), then emWin just doesn’t know about the factors cause you are calculating it by yourself at your driver level. In this case, yes, you should use different factors depending on the screen orientation.

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,

it is not entirely clear what job are you using when switching the screens. In your first message it was about SHOWSCREEN job. Logically the screen was hidden before you show it and the visibility is changed. Otherwise everything can be.

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 never tried it but seems that's what's you're looking for. The only clarification: library that you're using must be compiled with a special #define to support this message. I don't know if NXP version done like this.

Hello,

oh, glad that it worked.

However, as you said, we are waiting for the correct stuff in the next versions to avoid such a workarounds in the software.

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 handling a WM_PAINT message just set a new default font, call default callback function and return back an old default font. Note that the objects in APPWizard are not the legacy widgets and they have different callbacks.

Hello,

the link just has no the last closing bracket symbol ")". It shows the sample code for using an XBF font with GetData() function reading file data under WIN32.

Hello, Florian,

yes, you're right. Since then, I also realized AppWizard already allows to create such a things with an even bigger functionality than SWIPELIST does. So no need to duplicate this

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.