Seeking advice

#1 I think you have to add/remove (or show/hide) the individual windows from the base PlayGui rather than using pushDialog.

#2 An alternate approach would be to create a Gui that acts as a frame (or pane if that makes more sense) that contains all of the five different window controls, and then set those individual window controls as modeless.

With this setup, you would push the pane via pushDialog, and then be able to interact with all of the "child" windows within that pane in a modeless manner, which should meet your needs.

An example would be how the Options dialog works--when you activate the dialog, it pushes a pane that contains many child GuiControls, and allows you to interact with each, yet the Options Pane as a while is mode driven.

#3 I thought I had tried something like that, and there was still a problem with that from an Inventory window perspective. All the Inventory "packs" work fine, but the player is still unable to interact with the game world "around the windows." I had assume this is because all the "pack" windows exist on a parent guicontrol that when pushed as a dialog over the PlayGui, nothing in the PlayGui could be interacted with. Basically, as long as the user had at least 1 Pack window open, no mouse clicks would be processed in the game (events caught by the TSCtrl).

#4 Thanks guys for the suggestions.

@ Stephen: I see what you are saying and I may give that a try if I don't get it to work by recognizing what is the top-most window (in case 2 or more are overlapping each other) under the cursor. The reason I am striving to do it that way, is because I don't have a defined set of inventory windows throughout the whole game, which could just be pushed or popped as panes. The way it works is, that whenever the player obtains an inventory container (such as a backpack for example), a gui script is executed based on the size of the container and that is then tied to the backpack item, which gets pushed when the backpack is double clicked. Because of this, the inventory windows could end up changing quite a bit throughout the game, so the pane idea may not work out as I would like...unless I haven't understood how the pane system works (I will look into it after posting this)

My thoughts so far are to set 2 script variables with the mouse click position in GuiControl::onMouseDown and then find out in script which window controls are at that location and set the one that is the top-most in the stack as the current layer, giving it focus.

I will post my progress and the solution here...but more suggestions are welcome.

#5 @Mark (and the rest of the thread):

For that type of interaction, you'll need to go the way you originally said--make your gui items part of the core PlayGui so they are of the same "status" as the rest of the gui elements (of which the game itself is one when looking at it from this perspective).

push/popDialog is designed specifically to not allow interaction (for the most part anyway) until the dialog is completed--it's an interruptive technique (it's modal to use the proper term). There are probably ways to get around that design assumption and still use push/popDialog, but in general for that type of user interaction, you'll need to have your GUI's within the main play gui, and enable/disable them based on game state.

@Jacob: keep in mind that the "pane" concept is simply a GUI design term, and one that I personally use to define a parent control that has multiple types of child controls that can be treated as a single unit....move the pane, and everything "on" the pane moves as well, for example. Nothing says that you can't have a different pane activated for each inventory object size if needed.

#6

Quote:
The way it works is, that whenever the player obtains an inventory container (such as a backpack for example), a gui script is executed based on the size of the container and that is then tied to the backpack item, which gets pushed when the backpack is double clicked.

Ok, you're definitely looking at doing some dynamic Gui stuff. When the player picks up a new container, write out the script for its Gui into a file then exec it. Make sure to name the Gui something that can easily be dynamically constructed later (eg. Pack1). With it saved to file, it can easily be re-loaded next time the player starts the game. Add them to the PlayGui with Visible set to False. Then, when your pack button is clicked, have it call something like togglePack:

function togglePack(%packNumber) {
   %packGui = "Pack" @ %packNumber;
   %packGui.setVisible(!%packGui.visible);
}

Your button would have:

command = "togglePack(1);";

Hmmm... looks awfully close to some code that I know....

#7 @ Mark: that could work and I think I had a similar idea if I din't come up with something else :)

I have a solution and it is actually very simple.

In GuiControl::onMouseUp, I have it set 2 script globals with the x and y point of the mouse click and then eval a script function, which using the global vars does a