Configuration Panel Overlay

[Guardian17]

I've read the Post on "Static Code Modules", and I have a question concerning them....

For a game program, I want to have a static code module that brings up a panel with subpanels, seekbars and labels for user settings, an OK button and a Cancel button. The intent is to invoke this Configuration Panel from the main screen to set the game Process Global parameters as desired, then return to the game -- if the parameters are changed, the game re-starts using the newly-set parameters, otherwise the game continues where it left off. Process Globals handle all Main-Activity-to-Configuration-Panel-Sub "communications".

I currently have this Configuration Panel "activity" set up as its own project (outside of my game program) so I can work out all of the kinks, but I would like this "activity" to work "inside" my main program as a Sub (rather than an Activity) and overlay the Configuration Panel (like a message box) over the main screen until the OK or Cancel button is pressed.

Is it possible to overlay a panel on top of an application as described, then just perform a RemoveView (and/or RemoveAllViews) for that overlaying panel (and its sub-views), to have the original underlying main screen re-appear as it was before the Configuration Panel was invoked (without resorting to Activity_Pause and Activity_Resume)?

Another related question: If this overlaying panel is possible, do I need to be sure that the overlaying panel completely covers any buttons that might exist on the underlying Main Game Screen so that those underlying buttons are not usable?

 

[Guardian17]

Does the "Code modules cannot catch events" statement mean that I can't have Seekbars on my overlaying panel to change game parameters?

 

[margret]

You can design your settings screen in the Layout designer in B4A. Then in your code you can create a Panel and load this layout into the Panel. You will add a Panel click event that will block any clicks from getting to the controls on the main screen. Once you have finished, just call PanelName.RemoveView. These are Activity objects and you can not do this in a code module. You can do it in the Main Activity or in a Class Module.

Sub ShowSettings 
    'Name the main Panel in your Layout to: PanelMain
    'Be sure to Dim pnlSelect, pnlInput & PanelMain as Panels in Globals
   pnlSelect.Initialize("Select")      
   pnlInput.Initialize("")
   pnlInput.LoadLayout("yourlayoutfilename")    
   pnlSelect.Color = Colors.ARGB(150,0,0,0)         
   Activity.AddView(pnlSelect, 0, 0, 100%x, 100%y)   
   mh1=(pnlSelect.Height/2) - (PanelMain.Height/2)
   mw1=pnlSelect.Width/2 - (PanelMain.Width/2)
   mh2=PanelMain.Height
   mw2=PanelMain.Width
   pnlSelect.AddView (pnlInput, mw1, mh1, mw2, mh2)
End Sub

Sub Select_Click 
      'Stop clicks on Select panel getting to panel underneath
End Sub

Sub CloseSettings
      pnlSelect.RemoveView
End Sub

 

[Guardian17]

Margret:

Thank you very much for the response. I will be trying what you suggest ASAP, but I do have a few questions first:

1) Is there any significance to the references to PanelMain, other than computing the size of the newly-added panel?

2) From your example Code, it would seem that these are the following relationships:
a) PanelMain is some panel in my own Main Activity, presumably at or near the full size of the screen area. PanelMain is not related in any way to the new configuration/selection panel I want to use.
b) pnlSelect is the added "overlay" panel which serves as a container for my other configuration/selection panels, and also to act as a Click-Stopper for any underlying Main Activity object clicks. pnlSelect is probably smaller than PanelMain. pnlSelect is a convenient view to allow quick and efficient removal of the overlay configuration panel(s) by using "pnlSelect.RemoveView".
c) pnlInput is my own full panel layout that I have already defined that contains all of my configuration seekbars and labels that the User uses to make his selections. pnlInput resides within pnlSelect.

3) In (2a) above, is it an absolute MUST that PanelMain exists? Is it a common practice to always have a panel in the Main Activity into which all other objects/views reside?

4) Does pnlSelect have to fully overlay all of the Main Activity area to intercept any/all Clicks?

5) Assuming I'm correct about what I said about PanelMain being a panel in the underlying Main Activity that probably covers most of the screen area, and therefore should be larger in comparison to pnlSelect, wouldn't the mw1 and mh1 calculations you show evaluate to negative numbers?

6) Does the "Select" in the "Select_Click" Sub's name specifically refer to the name "pnlSelect", or to the name in quotes in "pnlSelect.Initialize("Select")", or is it some keyword similar to "Button_Click" for a button?

Sorry for all of the questions. Please correct me if I have stated anything incorrectly in my assumptions.

 

[margret]

PanelMain has to be the main panel in your layout file that contains all your views that you wish to popup over your main screen. It has nothing to do with the activity. pnlselect is the full size of the activity but you can see through it. It does stop the clicks from getting through. It dims the screen some just like a messagebox does because of the color setting. Whatever you initialize the pnlselect as, will be the click event. In this case "Select". Hope this helps.

 

[Guardian17]

Thank you

Margret:

Thank you. Your brief reply is very concise, helpful, and I believe answers all of my questions. I'll be trying all of this ASAP.

:wav:

 

[Guardian17]

Click Response

After the new parameters have been set in the overlaying Selection Panel and I exercise "CloseSettings" to remove the Selection Panel, is there something I need to do to re-enable my main screen and all of its buttons? Right now, after executing "CloseSettings", the Selection Panel disappears and I am left with my main screen, but in a very dimmed state (the entire screen is dim), and none of the buttons on the main screen respond to any clicks.