Wednesday, May 23rd 2018, 10:58am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

hbarta

Beginner

Date of registration: Jan 2nd 2015

Posts: 21

1

Monday, April 20th 2015, 3:42pm

WM_MakeModal() and touch input

Hi folks,
I am using a dialog (Window rooted with various widgets rooted in a Framewin) as a popup and want the dialog to be modal. However when I do this, the widgets in the modal dialog do not receive WM_NOTIFICATION_RELEASED events. This is awkward as some of them cannot then be pressed twice since they remain 'pressed' until another widget is touched.

I can work around this by not making the popup modal and instead disabling widgets in the parent dialog but this requires more code and logic than the single "WM_MakeModal()" call.

Is there a way to get WM_NOTIFICATION_RELEASED messages in a modal dialog?


Thanks!

Date of registration: May 26th 2009

Posts: 1,022

2

Tuesday, April 21st 2015, 11:53am

Hello,

Please note that you will have to provide "unpressed" touch events to emWin. Otherwise release events are never sent to a widget.

Best regards,
Adrian

hbarta

Beginner

Date of registration: Jan 2nd 2015

Posts: 21

3

Tuesday, April 21st 2015, 5:07pm

Hi Adrain,
The touch driver provides 'pen down' and 'pen up' events to the WM via:

Source code

1
      GUI_TOUCH_StoreStateEx(&TS_State);


and with TS_State.TouchDetected set appropriately.

This works fine if the dialog is not modal but when I add the call to WM_MakeModal(dialogHandle); e.g.:

Source code

1
2
3
4
5
WM_HWIN CreateFramewin(void);WM_HWIN CreateFramewin(void) {  WM_HWIN hWin;
  hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0);  return hWin;}
// USER START (Optionally insert additional public code)
void CreateUserNameDialog(void){  dialogHandle = CreateFramewin();  WM_MakeModal(dialogHandle);}
// USER END



WM_NOTIFICATION_RELEASED events are not then received. Without WM_MakeModal(dialogHandle); they are.

hbarta

Beginner

Date of registration: Jan 2nd 2015

Posts: 21

4

Tuesday, April 21st 2015, 5:09pm

And my code w/out 'code' (re)formatting:



static WM_HWIN CreateFramewin(void);
static WM_HWIN CreateFramewin(void) {
WM_HWIN hWin;

hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0);
return hWin;
}

// USER START (Optionally insert additional public code)

void CreateUserNameDialog(void)
{
dialogHandle = CreateFramewin();
// WM_MakeModal(dialogHandle);
}

// USER END

Date of registration: May 26th 2009

Posts: 1,022

5

Tuesday, April 28th 2015, 10:32am

Hello,

I am afraid I was not able to reproduce this behavior. The message WM_NOTIFICATION_RELEASED is sent correctly regardless the modal state.

Best regards,
Adrian

hbarta

Beginner

Date of registration: Jan 2nd 2015

Posts: 21

6

Wednesday, April 29th 2015, 4:05pm

Hi Adrian,
Thank you for looking into that. Can you suggest anything I might investigate to resolve this? It seems odd that the single call (WM_MakeModal(dialogHandle))
would interfere with touch handling for the case of pen up events and I suspect some other configuration option may trigger this behavior.

Thanks!

ntfreak

Beginner

Date of registration: Dec 11th 2008

Posts: 9

Location: UK

Occupation: Senior Embedded Engineer

7

Tuesday, June 9th 2015, 11:58am

I was seeing exactly the same behaviour, receiving no WM_NOTIFICATION_RELEASED events when WM_MakeModal was being used.
All was ok when testing under the simulator.

I am using STemwin and traced the issue down to ST's not so good touch driver.
You call BSP_TS_GetState to read the touch driver info, however x and y info is only written if a touch is detected.

The ST code was actually using x and y even if the data was not valid.

C/C++ Source code

1
2
3
4
5
BSP_TS_GetState(&ts);
TS_State.Pressed = ts.TouchDetected;

uint16_t xDiff = (prev_state.x > ts.x) ? (prev_state.x - ts.x) : (ts.x - prev_state.x);
uint16_t yDiff = (prev_state.y > ts.y) ? (prev_state.y - ts.y) : (ts.y - prev_state.y);


My solution was to make sure the parameter was always initialised to zero, eg.

C/C++ Source code

1
2
TS_StateTypeDef ts = {0};
BSP_TS_GetState(&ts);

Date of registration: May 26th 2009

Posts: 1,022

8

Wednesday, June 10th 2015, 9:12am

Hello,

Could you please tell me which ST package includes this touch driver? I would like to contact ST regarding this issue. Thank you.

Best regards,
Adrian

ntfreak

Beginner

Date of registration: Dec 11th 2008

Posts: 9

Location: UK

Occupation: Senior Embedded Engineer

9

Wednesday, June 10th 2015, 9:16am

I am using STM32CubeF4 (v1.5.0) - http://www.st.com/web/en/catalog/tools/PF259243

Date of registration: May 26th 2009

Posts: 1,022

10

Wednesday, June 10th 2015, 9:48am

Hello,

Thank you for providing the details. I see that the latest version is v1.6.0. Could you please tell me if this version fixes the problem? Thank you.

Best regards,
Adrian

ntfreak

Beginner

Date of registration: Dec 11th 2008

Posts: 9

Location: UK

Occupation: Senior Embedded Engineer

11

Wednesday, June 10th 2015, 11:56am

Have not got time to test, but a version diff suggests the file has not changed.

Date of registration: May 26th 2009

Posts: 1,022

12

Friday, June 19th 2015, 3:12pm

Hello,

I am afraid I did not get an answer from ST by now. So the problem will likely still exist.

Best regards,
Adrian

Pmjagtap

Beginner

Date of registration: May 5th 2016

Posts: 11

Location: UK

Occupation: electronic eng

13

Friday, May 6th 2016, 11:44am

Hello,

I am afraid I did not get an answer from ST by now. So the problem will likely still exist.

Best regards,
Adrian
Hello

I have come across same issue I don't receive WM_NOTIFICATION_RELEASED events when WM_MakeModal() is used. On contrary I do get WM_NOTIFICATION_RELEASED notification without use of WM_MakeModal() property.

I am using "STemWin_Library_V1.1.2" version from ST and it has "STemWinLibrary522"(Segger 5.22) version of Segger.

Current wayaround 8) I am using is when using GUI_CreateDialogBox for creating dialog/pop up window is to use correct parent window handle. By default(if using GUI builder) it uses WM_HBKWIN macro to get background window.

hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, hParentWin, 0, 0); // 4th Arg"WM_HBKWIN" replace with your current window handle "hParentWin" on top of wthich you want to create pop up win

This way even if I touch window in background my pop up does not get behind it floats on top, which is serving me for now well..

Regards

Pmjagtap

Beginner

Date of registration: May 5th 2016

Posts: 11

Location: UK

Occupation: electronic eng

14

Friday, May 13th 2016, 4:57pm

WM_HWIN CreateFramewin(void);
WM_HWIN CreateFramewin(void)
{ WM_HWIN hWin; hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0); return hWin;
}
// USER START (Optionally insert additional public code)
void CreateUserNameDialog(void)
{
dialogHandle = CreateFramewin();
WM_MakeModal(dialogHandle);
}
dialogHandle = CreateFramewin(); Return window handle/handle of frame window
In call back routine I was using pMsg->hWin; handle .. which would be same as returned by CreateFramewin();

WM_MakeModal(); Needs hParent and not window handle.

following code inserted in initialisation of dialog works..
_cbDialog(WM_MESSAGE * pMsg) {
WM_HWIN hItem;

switch (pMsg->MsgId)
{
case WM_INIT_DIALOG:
hItem = WM_GetDialogItem(pMsg->hWin, ID_LISTVIEW_0); // ID_LISTVIEW_0 is ID of child on created window
hItem = WM_GetParent(hItem);
WM_MakeModal(hItem);


break;
}

}

//-------------------------------------------------------------------------------------
This brings to question on user manual.. ?( Should it be Parent handle and not Window handle?

WM_MakeModal()
Description
This function makes the window work in ’modal’ mode. This means pointer device
input will only be sent to the ’modal’ window or a child window of it if the input position
is within the rectangle of the modal window.
Prototype
void WM_MakeModal(WM_HWIN hWin);

Parameter Description
hWin Window handle.

This post has been edited 6 times, last edit by "Pmjagtap" (May 13th 2016, 5:20pm)


Pmjagtap

Beginner

Date of registration: May 5th 2016

Posts: 11

Location: UK

Occupation: electronic eng

15

Thursday, November 24th 2016, 12:02pm

Just recheked today code behaviour but I am getting WM_NOTIFICATION_RELEASED notification in both cases with and without use of WM_MakeModal();

I do not recall what change made it to work it right !
Hello,

I am afraid I did not get an answer from ST by now. So the problem will likely still exist.

Best regards,
Adrian
Hello

I have come across same issue I don't receive WM_NOTIFICATION_RELEASED events when WM_MakeModal() is used. On contrary I do get WM_NOTIFICATION_RELEASED notification without use of WM_MakeModal() property.

I am using "STemWin_Library_V1.1.2" version from ST and it has "STemWinLibrary522"(Segger 5.22) version of Segger.

Current wayaround 8) I am using is when using GUI_CreateDialogBox for creating dialog/pop up window is to use correct parent window handle. By default(if using GUI builder) it uses WM_HBKWIN macro to get background window.

hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, hParentWin, 0, 0); // 4th Arg"WM_HBKWIN" replace with your current window handle "hParentWin" on top of wthich you want to create pop up win

This way even if I touch window in background my pop up does not get behind it floats on top, which is serving me for now well..

Regards