cancel
Showing results for 
Search instead for 
Did you mean: 

Modal Window Enhancement

DSwea.1
Associate III

I'm working on an application that requires user interaction to edit text and number fields using a alphanumeric keyboard, and also to make "menu" selections using the TGFX ScrollWheel.

I've designed data display and entry screens with objects that comprise labels and text fields which, when touched, make visible a popup window containing the editor (keyboard, or scrollwheel). In this manner, a single scrollwheel can be used to set values in different fields.

As part of the design, I wanted the background of the popup window to be partially transparent (alpha of 150) so that the background screen is visible underneath the popup, such as in this image of a popup window for scrollwheel selections:

0693W00000JPxb2QAD.pngNormally, one would use a TGFX ModalWindow for this purpose as it is designed to do basically the same thing. However, the ModalWindow has a requirement that is impossible to fulfill in our project: the foreground content of a ModalWindow must be placed on top of an image, and any spillover becomes subject to the alpha setting of the ModalWindow's background, such as in this example:

0693W00000JPxbbQAD.pngOur problem is that our application is severely constrained by the absence of external Flash, meaning that the image required by a Modal window will take up far too much space in our limited internal Flash. For example, a simple background of a rectangle of a single color is seen to take app. 320kB in ARGB8888 format, and app. 90kB in L8_ARGB8888. 90kB is almost 10% of available internal Flash, an unacceptable amount.

And, to boot, there can be no gaps in the background image. So, in the design I show in the first window above, the gap between the scrollwheel and the "Done"/"Cancel" buttons could not have transparency, reducing the perception of overlay.

However, there is one glaring issue with my design: the partially transparent background (a box widget) does not mask the touch sensitivity of the underlying screen. So, the buttons of that screen can still be activated when the popup is present, a problem not present in the ModalWindow.

I "solved" my issue with a workaround: I placed a full screen flex button behind the popup and in front of the underlying screen, added a text field to the button with a single space as its contents, and removed the default image from the flex button. Now the "invisible" Flex Button serves as a shield to the underlying screen, preventing touch access to its components.

So, finally my point: why not enhance the ModalWindow so that, instead of requiring an image for its center platform, one could simply use a box? This would represent a great savings in Flash storage when availability of that resource is in short supply (in my case, app .5kB kB vs 80kB).

4 REPLIES 4
DSwea.1
Associate III

It occurs to me that there is a simpler approach: why do we need an image("Window Image") in the middle of the ModalWindow at all? Why not just put up an "impermeable" background ("Shade") with user-selected alpha setting, and then allow the user to place any widgets they choose anywhere they wish on top of it? Having to load an image, with the restriction that any user-selected widgets that are used must be placed within its boundaries, seems arbitrary and unnecessary.

MM..1
Chief II

For example you can create own class based on Middlewares\ST\touchgfx\framework\source\touchgfx\containers\ModalWindow.cpp 

place MyModal.cpp and hpp into your code gui folder ...

DSwea.1
Associate III

Thanks for the tip. I didn't realize that the source code for TGFX containers and widgets was present in this directory. This provides additional insight into not only ModalWindow, but many other classes as well.

DSwea.1
Associate III

Based on examination of ModalWindow.cpp, the "secret" to making the semi-transparent background shield the touch sensitivity of underlying widgets is to make the semi-transparent background touchable (SetTouchable(true)).

A quick check reveals that the default for a Box widget (used as my semi-transparent background) is to set its "touchable" property to false, in which state it will allow touching of underlying objects that are partially visible. Setting touchable true prevents this from happening.

Bravo, and thanks again for your suggestion MM.