Microsoft, after a few years and a considerable pressure from the clever programmers out there, has ditched ActiveX controls. While this was an overally good decision, it can also cause a lot of headaches! To my astonishment when I run a merely few months old script I wrote in Max 8 in Max 2008 x64 (on Vista Business x64) the script didn’t work, in fact it threw the error message you can see in the picture above. At first I didn’t know what the hell was going on, even the MAXScript reference included the old ActiveX declaration part, so I really had no idea what was going on, further on when I run the same code in Max 8, also on the same computer running Vista Business x64, the script worked! The reason for that, as I learned on the internet, is that since Microsoft doesn’t support ActiveX anymore, they didn’t recompile most of the controls to 64bits, so, when you run a 32bit app., like Max 8, on 64bit Vista, it still calls the old 32bit ActiveX controls, however, when you run a 64bit app., like Max 2008, there’s no equivalent of 64bit ActiveX and since a 64bit program cannot run 32bit plugins/apps. from whithin itself, it simply throws you an error.
So I followed a few threads here and there on the internet to find the solution, since I’m a bit new to 64bit systems and Max 2008. The solution is simple: .NET (dotNET) Framework. Since Max 9, Max supports .NET Framework objects and classes etc. and therefore you have to re-write your scripts that use more advance UI elements such as ListViews or TreeViews in order to be able to draw the UI correctly (without errors) in Max 9 and up. Both 32bit and 64bit versions of .NET objects are supported and provided, so you won’t have to use ActiveX for scripts running in a 32bit version of Max and .NET for scripts running in a 64bit version of Max. At least. However, Max 8 scripts are doomed, well, at least on a 64bit platform. This is sad as I have to rewrite some of my tools in order for them to run in newer versions of Max. Well, at least that suggests some progress, so I’m not really bitching about it, in fact quite the opposite, the .NET objects and classes look quite robust, mature and feature-rich!
Now, the change in code isn’t, thankfully, that drastic, you just have to call the objects in a bit different way within MAXScript, but in the same manner:
So you see, it’s very similar, however, the properties and general workflow differs a bit more between ActiveX and .NET objects. Thankfully, we still have Bobo (the MAXScript genius) around as he put together a thorough list of available objects and classes that are useful for MAXScripters and tool developers: Using dotNET in MAXScript, but if you come from a software developer side of things, you might be interested in the full .NET Framework documentation that is available on Microsoft’s own websites: .NET Framework Developer Center.
To finish off, if you’re looking into MAXScript and developing some tools either for yourself or for a collaborative environment, definitely look into .NET and forget about ActiveX as that’s the technology of the past, while .NET will, most likely, be around a few years if not longer than ActiveX. Also, there are some good examples in Max itself, like the Named Selections tool or the huge Render To Texture dialog, which got rewritten to sport the new .NET objects as opposed to ActiveX, so go ahead and dissect them to learn the new technology from the masters that put them together in the first place. The MAXScript reference also describes the .NET workflow as well as shows some direct comparisons between ActiveX and .NET code.