Context-sensitve maxscript UI?

gamedev

Just curious if anyone has created a context sensitive maxscript UI. Basically what I'd like to do, depending on suboject level, or if a radio button is pressed, etc, change UI elements to present different options. I know how to disable and enable UI controls on the fly, by can I remove and add UI elements, etc on the fly? Are there prefered methods of doing something like this?

-Tyler

gamedev

Hey Perna,

Thanks for the input. At this point, something like that seems like a an ok solution for small stuff, but when managing a larger UI could be come cumbersome. I'm guessing it could be slow as well to re-build a larger UI on the fly, though I'm not sure.

I'm wondering if this really possible. I've yet to come across a really nice maxscript UI that was context sensitive. Maybe I'm missing something.

Has anyone seen something like this?

Ben Cloward

Tyler,

The reason Perna is suggesting doing it this way is because there is no "good" way to do it. It's not something that the engineers thought about when they designed the system. I guess they just assumed people would build very simple UIs not not need all kinds of dynamic fancy stuff. Because of that, we're stuck thinking off all kinds of work-arounds. Perna's execute suggestion is a pretty good way to go about it.

-Ben

gamedev

Thanks guys. Yea, I was hoping there was something built in for this. perna, I'll try out your solution this weekend. Its good to hear you're using this for larger UI / scripts.

Thanks again!

-Tyler

PaK

Tyler, I like your portfolio.

-R

Rob Galanakis

Building a UI with strings is a terrible way to handle large rollouts. Yes, I know this is what many people do and how it has been done for ages, and many great tools have been written this way (I use some of them). But that doesn't mean it is the best way.

What you should really try doing is using SubRollouts. That means, you will be able to make a bunch of rollouts as normal, and switch them out in a subrollout UI item based on... anything, really, but most often a .NET tab control. But radiobuttons could work fine as well if you don't want to get into .NET.

Sometimes you will need to take the string route- specifically, building UI's dynamically that are almost entirely unpredictable and not modular. In this case, you should consider your design, because it can probably be improved. This is also acceptable in most simple cases. And in Max 2008 and up, you have verbatim string literals, which means the code for a string-based UI generator is more straightforward (you don't need to use the \ escape character, you can just put @ before the string and it will treat it verbatim, ie, won't parse it with the regular parser, so things like \n are read as \n and not a newline character).

By all means, if you are new to this Maxscripting, go the string route- it is easier to get started with. But there WILL be a point where it becomes a big hassle- usually as soon as you need to do any significant editing or rework, or if you have any significant code in the UI/event handlers. The time investment you will make in coming up with a better and more flexible and extensible UI system via subrollouts will be well worth the hassle of dealing with a string-based UI. There are also plenty of samples available, so learning how is not an issue.

gamedev

Hey Rob,

Can you point me to a script that uses the subrollout method you describe above? I'd prefer not to tackle .NET just yet.

-Tyler

Rob Galanakis

These are all good threads:
http://forums.cgsociety.org/search.php?searchid=1264661

Most of them use tabs, but you could switch the rollouts based on whatever you want (such as a radiobutton). But the .NET involved is minimal so I would say go with tabs if they fit the bill.