Dialog closes

46 views
asked Jan 6 in Embedded Wizard Studio by ezed413

I am displaying a menu dialog from the main application when a hardware button is pressed. This happens, but the dialog closses after a period of time. Here is a code snippet. 

 

/* The template just returns the given argument... */
var Application::MenuScreen menu = new Application::MenuScreen;

if( showMenu == true ) {
  SwitchToDialog( menu, null, null, null, null, null, null, null, null, null, false );
}
 
return aArg1;

 

commented Jan 7 by ezed413
Thanks, this was helpful.

1 Answer

0 votes
answered Jan 6 by Paul Banach

Hello,

I'm not sure whether I understand your question... are you wondering why your dialogs close automatically?

If this is the case please note that there is no automatism to hide any GUI components. If the dialog disappears, then there is some code executed to do this. Please verify your implementation of the splash screen (thread Implementing a splash screen). It contains a timer to close the current dialog. Have you followed the step 1 to ensure that the timer fires only once? I suppose, the timer fires periodically and so closes the actually shown dialog.

Best regards

Paul Banach

commented Jan 8 by Paul Banach

Hello,

one idea: in your actual implementation you invoke the function DriveKeyboardHitting() with 1 in its last parameter. This indicates the 'press' event. In practice, however, you should also signal the event when the button is released again. The simplest would be following adaptation: 

if ( EwBspGetButton1Level() == 1 )
{
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser1, 0, 1 );
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser1, 0, 0 );
}
if ( EwBspGetButton2Level() == 1 )
{
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser2, 0, 1 );
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser2, 0, 0 );
}
if ( EwBspGetButton3Level() == 1 )
{
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser3, 0, 1 );
  events |= CoreRoot__DriveKeyboardHitting( RootObject, CoreKeyCodeUser3, 0, 0 );
}

Without this adaptation, when you press the same harwdare button twice, the GUI framework will interpret the second press event as repeatition event. This repetition event will then be delivered to the Key Press Handler which has received the initial press event. This could explain why you don't get the event in the second screen.

Does it solve the issue?

The above adaptation is sufficient for most cases as long as you are not interested in processing events when the user presses and holds a key. In such case it would be reasonable to adapt the interface to the hardware buttons  so that it can detect the press and release events and report these individually.

Best regards

Paul Banach

 

commented Jan 8 by ezed413
Hello,

I haven't tried this yet, but will later this evening as I don't have the development board with me. But I have been prototyping other parts of the project. I have discovered the wonderful OOP feacture of EW! Our interface will probably have 13 - 15 screens. And there are certain aspects of each screen that will be the same. For instance the soft button icons and the keyboard event handler with the slot method. Well I created another bare minimum screen, and discovered that I could use the browser to find that component and just drop it on the unit and have another exact screen with the same functionality. It's well thought out. I commend you guys on a wonderful app!
commented Jan 9 by ezed413
Yes, this solved the issue, thank you. I did have to implement software debounce using the HAL_Delay method when checking the push buttons, but my app is working as it should!

On another note, I used a vertical list as my main menu. I am trying to make it look 3D like some of the examples. I see how it is done, by making the item rectangle color white and the BL and BR colors a shade of gray. But as soon as I go back to the screen with the vertical list, it's all white! Really don't understand why it does that. I am not doing something right.
commented Jan 9 by Paul Banach

Hello,

the color of a rectangle can be configured by 5 properties. The properties ColorTL .. ColorBR specify the colors for the particular corners. The property Color, in turn, overrides the corner properties permitting you to change the rectangle color at once:

Usually you use either the four properties (e.g. ColorTL) to specify the colors individiually for each corner or you use the property Color to specify the color for the entire rectangle. If you mix the both approaches, the property Color overrides the setting of the other properties. Please verify whether the property Color is modified (it appears bold in Inspector). If this is the case, restore the original value of the property Color.

Does it solve the issue?

Best regards

Paul Banach

commented Jan 9 by ezed413
The issue is solved, thanks!

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...