Notifications
Clear all

[Closed] .net createtext fails in max 2016

Today I tried to write some text to a file in max 2016 but failed. I’m using the following code

thePath= (dotnetClass "system.io.path").combine (getDir #temp) "textfile.txt"
 theFile= (dotNetClass "system.IO.File").CreateText thePath
 theFile.write "Bingo"
 theFile.flush()
 theFile.close()

In max 2015 the word “Bingo” is indeed written to the file. In max 2016 only the first character is written. Can anyone confirm this?

5 Replies

i don’t have MAX 2016, so try yourself:

theFile.write (dotnetobject "System.String" "Bingo")

maybe they changed something in case of unicode

Indeed using the .NET string works, there seems to be some problem in the implicit casting of WStr to System.String.
Another work around you can use is: (dotnetclass “System.IO.File”).WriteAllText thePath “Bingo”.

Thanks Denis and Daniel for the suggestions and confirming this.
I’ve also placed a string in the tag of a button. That seems to work just fine.

but.tag = "Bingo"

Please guys report this bug – it might look small but i think it’s hideous !

In the mean time i had a look at the SDK source code ( samples/maxscript/mxsdotnet ) and fixed the issue

No guarantiees or whatsoever , it works but is purely experimental of course. To install simply follow the readme.
Download 3ds Max 2016 – unofficial mxsdotNet hotfix

it’ a general bug in the MXSDotnet code ( CalcParamScore() in utils.cpp) dealing with dotNet<>MXS type matching.

In short: a new function was introduced to calculate a “matching score” to determine which dotnet type to generate from incoming MXS types. This function is flawed as it evaluates “System::Char” as exact match for MXS’s “String”. It continues to test for all other dotnet types too and even determines “System:String” is a perfect match too. But it does’nt handle this and only acts in a first come first serve manner, witt the first match being “System:Char”. Thus you get only the first char in the dotnet side

Currently this function is used to do the parameter type matching for dotnet Methods ( FindMethodAndPrepArgList() ) and god knows what other things might break because of this flaw. Affected are MXS string and stringStream passing BTW

I fixed the bug and recompiled the “mxsdotnet.dlx” assembly. This one now evaluates “System::Char” as “kParamScore_PoorMatch” instead of “exactMatch”, so System::String always gets precedence over System::Char

Again : no guarantiees , no connection to Autodesk, purely my humble fix and i take NO responsibilities ;

Thanks Josef for the fix. I have actually reported the bug.