Zugg Software :: View topic - [1.33] Multi-state Buttons in Module not sending Commands

Posted: Fri Jun 08, 2007 8:54 pm

I have a multi-state button defined in module that not sending commands to the MUD. If I move this same button under the session window the commands are sent.

To recreate open CMUD and hit Esc to open an offline session.
Open the package editor and define a new module Test.
Define a multi-state button under this module with at least two states and commands to send the MUD. I used 'state one called' and 'state two called'
Save the button and close the package editor.

Try to use the button. You'll notice no commands are sent.

Open the package editor and move the button to window for the session.
Close the package editor.

Try to use the button again. You'll notice the commands are now sent.

If you move the button back to the module, the commands will fail to be sent again.

Posted: Fri Jun 08, 2007 9:20 pm

Here is the response I sent about this from the feedback system:

I think we have already talked about this on the forums. Buttons *only* work properly when defined within a *window*. They do not work from packages or modules. This makes sense if you think about it...a button is a visual object and it needs a visual parent like a Window in order to be displayed. CMUD cannot currently create multiple instances of a single button definition, so there is no way to put a button definition in a module that can be used in multiple windows.

Posted: Fri Jun 08, 2007 10:09 pm

Is it possible to revisit this? Consider the rest of this more of a feature request.

The reason I'm asking is that I'm trying to develop some packages that includes buttons as part of their distribution. I only want the button displayed on the toolbar of the main window session and only displayed once. The challenge is I'm facing is that I don't know (can't think of) of way to distribute buttons with my packages without forcing a superfluous window on the user or forcing them to use my window neither of which I would want do.

I'll play around with this some more, but all thoughts/ideas are appreciated.

Incidentally a single push button works in the manner described above. I don't know if that's a fluke or not.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Tech,
Wow... I had noticed some strange behavior with push buttons in modules but had not mentioned it because they are not supported anyway.

Ok, so I just looked at the multi state buttons and tried the workarounds I used for the push buttons on them and a few more I thought up, no luck sorry.

Zugg did recently give us back the ability to add a window without having a mud output window attached to it. This in effect gives you a button bar
that is dockable. Not quite the same as being placed along side their own buttons but that can be a plus sometimes.

Zugg,
This gave me something to think about though. How hard would it be to merge the button bars that each window has with the button bars from a module?
Perhaps have a checkbox somewhere that you could set if you want to enable a bar from a module you already have enabled for a window?

If that is completely out of the question and you don't want us to use buttons within a module at all how about creating a third kind of object
a ButtonContainerObject that can be placed within a package? This object would only be able to hold buttons and if it is enabled for a window
the window receives the buttons within that object.

I haven't distributed anything in a while and would want to use a private package library if I were going to use it at all but, I would like to be able
to distribute buttons with my settings without forcing someone to have another window open; even a small docked one.

Posted: Mon Jun 11, 2007 4:52 pm

Arminas, I like the idea of a button container. Because we can still distribute button sets that way and give the user of the package the option to place them where they think is best. I, personally, prefer my buttons at the bottom, but I've seen quite a few folks use them at the top.

It would address what I see is the main concern a way to effectively distribute buttons as part of your package, and if need be we can impose the one window assignment on the button container. I think buttons being a different beast than menus or windows will be the only ones that need this container concept.

I tried the window with the hidden output but it's really kludgy and has issues.. programmatically defining the display would be funky and would be required for multiple packages that have this button set. I think I can get it to work, but the idea of a button container, as you suggested, would be a much more elegant solution.

Any of you uber-zScripter have any thoughts? Matt, Fang, Arminas, Larkin, Vijilante, Nexela et al...

What about you Zugg, is this something that is possible? If not what are you recommendations for addressing this type of problem?

Posted: Mon Jun 11, 2007 5:20 pm

I definitely agree that there needs to be some sort of solution for buttons. The issue here is that buttons need a visual parent and since the window information for that parent window will be different for each of your script's end users, you can't distribute buttons that'll automatically associate themselves with that window.

Button containers are one possibility, definitely. They'd have to have some kind of dropdown allowing the user to choose which window the buttons in the container take for their parent. The end user would then just choose their session window from the drop-down box and Bob's your uncle. The only issue with this really is that it doesn't allow different parents for different buttons - so why can't the parent of the button just be selectable? It could be ignored if the button's inside a window.

In both these cases, there ought to be a "none" option you can select to get your package ready for distribution. Buttons with an invalid parent wouldn't be drawn, and there could be a preference to have a message echoed when a button has an invalid or blank parent.

The only real problem here is complexity though. There definitely needs to be something added here, but ideally it'd be as simple as possible. I don't know if these are the most simple solutions.

Posted: Mon Jun 11, 2007 5:44 pm

Sure you can have different parents for different buttons. Just have multiple button containers. And if it comes down to the point where the user wants to control each button individually they can just manually move them to specific window the want them included as.

The idea is to let the end-user use the package as the author intended without a deep knowledge of all things CMUD. A more experienced user could hack it up anyway the want knowing that it would all get overridden if, and when they updated that package.

I don't like the idea of it being on a single button, because then the set up gets tedious.

For example if I have a Button Container (BC) with Status that contains gauges for Health, Mana and Movement, I would logically want these grouped and displayed together. Next I could have a BC for movement compass that's potentially 9 buttons I would want grouped together. I'd hate to have to set it individually. Similarly you may want to do things for charges on different staves or even spell effects, but you get the idea.

The button interface will have to change a little. It would need an option to either use it toolbar setting under a window or outside of window be force to chose the BC it's associated to. That way it will automatically pick up whatever setup the BC has. Thinking about it more you can do away with the ToolBar location altogether and rather give each window 4 default BC that correspond to what we now consider toolbars, because essentially they are interchangeable. The only difference is that the toolbars are already tied to a specific window.

I'm hoping with an extension of the Panel/Container in Delphi, an extension of the ToolBar code and a health dash of that Zugg magic this will actually work quite well.

(The brain is really flowing now)

Thinking even more, you could probably skip extending the current code and and just tie the BC to be one of the geewhiz features that come in to play when you do zApp integration (seems like a very logical fit). The only drawback to it is that it would probably be some time before this problem is addressed.

Newbie Joined: 14 Aug 2007 Posts: 1

Ive tried the method above and its not working..Ive tried creating a multi-state button, and its not sending commands no matter what I do.

Posted: Tue Aug 14, 2007 2:03 pm

By "the method above", do you mean only creating your multistate button inside a window, or something else?

Posted: Tue Aug 14, 2007 4:45 pm

NolePaul, make sure you read the entire thread. You'll see that we have already said that buttons in other modules don't work at all. The button needs to be defined within a window for it to work. Also, v2.0 has many multi-state button fixes, so you might want to wait for that.

Back on the ideas presented in the original topic: Not sure how I missed this discussion, but this was the first time I read about all of this. I agree that "button containers" is a really nice idea. I'll try to think about how this might be implemented.

But the main killer problem with buttons right now is that CMUD only associates a *single* visual button with a given button setting. So there is no way to have a button stored in a module and then have it visually displayed in more than one window. So, to handle any of this, I need to implement button "instances" where you can multiple instances of the same button. That's an architecture change that is on my to-do list, but it will be difficult and isn't part of the next 2.0 version.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

NolePaul,
If you mean my suggestion of using another window to make a button bar there are a few tricks you must use. It is also still buggy and if you encounter any of the bugs it is best to give up the idea. I suggested this method to Tech who I was sure could iron out what I meant. Here is a short rundown of the process.

Create your new package named ButtonBar.

Create a window within this new package Name it ButtonBar as well.

Set the window to have no network connection or to use the main connection.

Uncheck command line, uncheck status bar.

Click preferences, go to the window options tab and uncheck session output. Click apply and then OK.

Create a push button named Test1 inside your new window. For the script put.

OtherWin Test1

Save the button and click on the module that is named ButtonBar.

Create an Alias named OtherWin. For the value put the following.

untitled:#raise %1

If you are using something other than a blank session to test this you will need to change the word "untitled" to the name of the window that you want the button to work for.

Save the alias and create a new Event named Test1 also within the module ButtonBar. For the value put the following.

#say {You pressed: Test1}

Save the event.

Now close the package editor and drag the window named buttonbar to the place on the screen where you want your Button Bar.

If you follow these instructions you should be able to make your multistate buttons in the same manner. Keep in mind that you want to create your button scripts as Events within the ButtonBar Module and NOT within the ButtonBar window.

Posted: Tue Aug 14, 2007 8:37 pm

Well Zugg I'm glad you picked it up, this is definitely one I've been waiting for. Having multiple instances of a single button can probably get thorny, but I can see how the multi-players would appreciate it as a feature.