How much are you using dotNet in Max these days?

I’ve been using dotNet controls almost exclusively now for our new tools, and we’ve also started running into what seem to be strange memory issues and a lot of “Unknown system exception” errors with the artists. I’m wondering if the two are related. I generally use a Max rollout, but then populate it with dotNet controls plugged into a tab control or panel. And everything is defined in a huge struct loaded at startup.

I’m doing this mainly because the DN controls are so much more flexible than Max’s, plus it’s easier to add and remove them dynamically if needed.

Is anyone else heavily integrating DN controls, methods, and event handlers into their tool set? And have you run into issues as a result? I want to retrofit some of out older tools now, but I’m wondering if maybe I’m pushing Max too hard and it just can’t handle having so much dotNet going on under the hood.

There are some of our tools we simply could not do with Max’s controls, and need to use DotNet- we have a few datagridviews and listviews that would be impossible to replicate correctly. Sometimes I’ll use dotnet spinners, etc., if I need the added functionality. Also, things like tabs are invaluable.

I’ve gotten the dotnet out of memory error. I don’t really think it is a dotnet thing, though- I am pretty sure it is the standard max ‘out of memory so I’ll throw a system exception’ error but for some reason dotnet is catching it (maybe if a dotnet control- like a progress bar- is running?).

AFAIK there aren’t major problems like you are describing with Max and .NET. The guys at CGTalk do some amazing things and I haven’t seen them have these issues. My guess is what I stated above- the problem is a max memory issue and dotnet is throwing a memory error. Random unknown system exceptions are very often because of memory, as well.

Also, how ‘huge’ is the struct loaded at startup? What is in it, exactly?

The struct is about 2,500 lines of code with about over a hundred controls and their even handlers. The tools itself is made of a tab control with four different tabs. It’s the main tool for setting any game related property on a mesh, or any of its faces. We’re also doing some things with dotNet to talk to outside C# apps.

I know a lot of people are doing the same types of things, and more. I just wondered how widely its been adopted in the Max using game dev community, and how far TA’s are pushing it.

I think you’re right about the exceptions being more related to Max’s internal way of handling memory than dotNet itself. And I’m looking into ways of optimizing our scripts to minimize this.

Have you tried using MaxForm instead of Max rollouts? That could be an issue… I also had lots of problems like that when using a huge amount of pictureboxes created in runtime… I solved that creating a custom class in VB… but it’s hard to manage garbage collections with max+dotnet… Cheers!

There’s an issue with using .Net comboboxes in forms. There’s a CGTalk thread on it here. The strange thing about that bug, though, is that I’m only using the rollout as a shell basically, with only the tab control assigned to it and every other .Net control added into that. So the bug is with using the form at all, and not with using a Max dotNetControl combobox over a dotNetObject “System.Windows.Forms.ComboBox” control.

Hi James,

I am being cautious about what I deploy currently, and have stopped short with a full on framework that all other scripts reference. Most use custom dotnet controls (which I am still learning about really) to augment or provide UI functionality that max controls can’t. Currently my Eye control joystick and slider controls seem to be behaving themselves.

The biggest issue i have seen so far is the bug that prevents you from adding handlers to dotnet objects outside of global scope. It means putting some controls into the command panel for custom attributes do not work how they should,
To get around it you have to build a custom control than can do all the handler stuff outside of max. Its not difficult, but means reliance on another assembly.

I am on the cusp of releasing an XML based character facial pose storage system, this again has custom UI elements that allow me to pass a lot of the code handling to dotnet. This has the advantage of saving a huge amount of time with the UI generation, by keeping the custom dotnet stuff as flexible as possible, needing only a few extra lines of MXS (usually in the handlers) to make it work. I’m an animator, not a TD so this stuff has to be about speeding up my day to day stuff!

Pete