Qustion on GUI Buttons in Max

[D'Lanor]

Could you try PtGetControlEvents(true, self.key) and PtGetControlEvents(false, self.key) instead of PtEnableControlKeyEvents(self.key) and PtDisableControlKeyEvents(self.key) ? That's what I always use. No idea why there are two methods for the same thing though.

[tachzusamm]

Hmm, the code seems quite right to me.

Maybe you could try:

Code: Select all

        if (id == GUIActivator.id) and state:

instead of:

Code: Select all

        if id == GUIActivator.id:

in OnNotify(), to prevent IOpenGUI() executing twice. Could be that calling it twice causes problems.

Explanation: OnNotify() is always called twice; once when you press the mouse button, the second time when you release the button. The parameter state informs you which action took place.


EDIT:
And it might be a good idea to unload the dialog finally in the destructor:

Code: Select all

    def __del__(self):
        PtUnloadDialog(kGUIName)

[Christopher]

If it don't work you can try to make always a debug print when the def OnControlKeyEvent is executed. Maybe you are only using a wrong number...

Christoper

[TheMagician]

Could you try PtGetControlEvents(true, self.key) and PtGetControlEvents(false, self.key) instead of PtEnableControlKeyEvents(self.key) and PtDisableControlKeyEvents(self.key)

Tried that but doesn't change anything.

And it might be a good idea to unload the dialog finally in the destructor

Thanks for the tip. Added the piece of code.

Could be that calling it twice causes problems.

To prevent that I had already inserted the boolean variable 'CamGUIActivated' which prevents the IOpenGUI from running twice (and from the log file I can see that it only runs IOpenGUI once).
Still nice to know this other method.
When you use

Code: Select all

if (id == GUIActivator.id) and state:

which state is actually detected? Mouse down or mouse up?

you can try to make always a debug print when the def OnControlKeyEvent is executed

I've done that now and the code looks like this:

Code: Select all

def OnControlKeyEvent(self, controlKey, activeFlag):
        print 'CONTROL KEY PRESSED'
        if (controlKey == PlasmaControlKeys.kKeyExitMode):
            print 'CONTROL KEY ESCAPE PRESSED'
            self.ICloseGUI()            
        elif ((controlKey == PlasmaControlKeys.kKeyMoveBackward) or ((controlKey == PlasmaControlKeys.kKeyRotateLeft) or (controlKey == PlasmaControlKeys.kKeyRotateRight))):
            print 'CONTROL KEY ARROW PRESSED'
            self.ICloseGUI()

Whatever buttons I press none of the debug prints ever makes it into the log file which indicates that the keyboard input is completely ignored

[tachzusamm]

When you use

Code: Select all

if (id == GUIActivator.id) and state:

which state is actually detected? Mouse down or mouse up?

If I remember it correctly, state=1 means mouse down, state=0 means mouse up again.


How do you test it?
Export from MAX, and testing on a MOULa-like server, or do you convert it using drizzle and try it locally on a POTS installation?

And do you have the Python glue block included in the script as well at the end?

[TheMagician]

I use Drizzle + local POTS installation.

Yes, the Python Glue block is attached.

[Christopher]

Maybe you should try something, which is not recommended... I would try to put the "PtGetControlEvents(true,self.key)" in the OnServerInitComplete-part. If it works, then there is something wrong in you def IOpenGUI.

Christopher

[TheMagician]

... after an hour of analysing the setup of xDialogToggle and different age prp files from Cyan's ages I found the cause of the problem.

I followed THIS tutorial on setting up GUIs.
There it says that in the GUIDialog component you should tick the "modal" checkbox. For the tutorial that's the right choice because there's a clickable button behind the whole GUI that you can click to exit the GUI again. However, if you don't have any buttons to exit the GUI you MUST NOT (and I'm sure everyone apart from me has already known that ) tick "modal". This seems to block all keyboard input.

Shame on you for not thinking of this source for the error Just kidding, of course, thanks a lot for all your input

[D'Lanor]

Actually you are supposed to be able to exit xDialogToggle by keyboard input as well. So I'm afraid that tutorial is still wrong. Or at least it should explain what exactly "modal" does.

P.S. And nope I had no idea since we don't have that option in Blender. Yeah, I know... wrong forum but some of us only chimed in because we saw that magic word "Python".
P.P.S. Hmm, odd. Last year I created a GUI dialog mod through Blender (and a bit of hacking) which has modal enabled and still responds to keyboard input. Oh well, never mind. Glad that it is fixed.

[andylegate]

Ooopsy!

Okay, let me explain what "Modal" does. First however, please forgive me for not chiming in earlier here, as someone pm'ed me and I just found the pm notification in my emails. I'm not hanging out here anymore so I didn't see this until now.
Also please forgive my tutorial on this. it was one of my first, and when I'm done here, I'm going to go edit it to explain what I'm about to tell you here.

First, remember Google is your friend.

If you Google the word "Modal" you'll get a great link to Wikipedia explaining what it is:

In user interface design, a modal window is a child window that requires users to interact with it before they can return to operating the parent application, thus preventing the workflow on the application main window. Modal windows are often called heavy windows or modal dialogs because the window is often used to display a dialog box.
Modal windows are commonly used in GUI systems to command user awareness and to display emergency states. On the Web, they are often used to show images in detail.[1]

Here is the link: http://en.wikipedia.org/wiki/Modal_window

Okay, now, using Modal in Cyan's Plugin, is dependant on a few things. In my tutorial, you HAVE to have it. That's because if you read the tutorial, you'll notice I don't have you set up a "click off panel". This is a invisible panel that pops up with the GUI, and allows the player to click to have the GUI pop up, pop down. This is used in case the player clicks off to the sides of the GUI pop up.
Using Modal Enabled, you do not need a click off panel. The player can simply click on the GUI pop up and it will go down, and the cursor will not work on anything else outside of the note, and player navigation will not happen.
Obviously, Modal is only good for things like notes, or pictures, etc. For things like, say, the Er'cana pellet ovens, using Modal would be a bad idea, as you need to be able to click on other things.

Here is some screen shots. This is a GUI pop up of a note in Neolbah. If you look, my cursor goes hot when I move it off the note, and over the journal laying on the desk:



If I click on that journal (because I don't have a click off panel, AND I do NOT have Modal enabled), it pops up too:



Worse: If I move my mouse over to the side, I can make the avatar turn, and if I keep the mouse button held down while turning, and move it back to the center, I can navigate. Hey look! I brought the note to the Atrium!



So that is what "Modal" is for: it makes it to where a Note, Map or Picture pop up does not need a click off panel, and makes sure that only the GUI panel you are looking at can be clicked on (and no navigation with the GUI up).