.mel Character Encoding Issues

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
  01 January 2013
.mel Character Encoding Issues


I'm developing a script on a Windows machine. I don't have access to a Mac or Linux machine, and people using my script who are running Maya on OSX have reported issues with my script.

My question is: is there a difference between OSX/Linux/Windows when it comes to how a .mel file is encoded?

My hunch is that there is. For example, I broke a string down over several lines, appending "\" to the end of each line to tell Maya that the string will continue on the next line:

string $myString = "bla bla \
		bla bla bla \
		bla bla";

This worked without problem on Windows, but the line continuation character "\" wasn't properly recognized on OSX and my script failed.

Also, when I receive .mel files that were created via Maya on OSX, my IDE (Ultraedit) prompts me to convert to DOS (Ansi, I suppose?) format, which is never the case with .mel files I save from Maya myself on Windows. I can't be sure, but I think that OSX text files are encoded in UTF-8?

I know that different Encodings handle CR/LF differently, and that this might be the cause for the example issue described above, but that's pretty much all I understand about Encoding.

So I saved my script to UTF-8 and tried to source it in Maya it couldn't even parse the first line.

I really need to get to the bottom of this because I'm receiving bug reports from OSX users describing behaviour that I simply cannot replicate on my Windows machine.

Is it common practice to save and distribute different versions (with different encodings) of .mel scripts?

I've tried googling the issue, but there's virtually zero information out there. Only in the Maya docs, under the "preparing Maya files containing japanese text" is there mention of Encoding settings (but, because it refers to Japanese locale, it suggests SHIFT_JIS for windows, which is specific to Japanese)

TL;DR: Can a text-file's character encoding (Ansi, UTF) be the source for incompatability between Operating Systems?
  01 January 2013
I believe your problem has to do with the EOL character(s) being used. On Windows it's "<CR><LF>", on Linux "<LF>" and on Mac "<CR>".

I set the EOL character to the Windows "<CR><LF>" and attempted to run the script on a Linux system. The error generated was "Unterminated String".

After setting the EOL character to "<LF>" it worked just fine (it still worked on Windows too). Sorry, I'm unable to test on OSX right now but I expect it to also work.

In a program like Notepad++ you can convert the EOL characters to Unix (Edit->EOL Conversions). You can also turn on show hidden characters to see what the actual end-of-line characters are.

I would recommend converting the EOL characters to Unix (it should work for all three platforms), save it out and send it to one of your Mac users for testing.
  01 January 2013
Thanks for the Info.

Yes, I suspected as much about CR/LF issues. I converted to MAC and it still works under windows, so that's how I'll leave it for the moment.

But there's still issues I'm getting when the script is run under OSX. The example I gave was just that, an example, which I was easily able to work around.

But another bug that has been reported is this: In my script there's a UI with a bunch of iconTextButtons that have drag- and dropCallbacks. On windows, I can drag and drop them at will, but on OSX, its been reported that you can't drag them at all (you get the 'not_allowed' cursor, just like you normally do when you drag onto a UI element that doesn't have a dropCallback defined).
I'm at an absolute loss because under windows, but otherwise identical conditions, it works like a charm.
Any ideas?
  01 January 2013
The drag-and-drop issue doesn't sound like it would be related to encoding. I would imagine the whole script would fail if something is incorrect in that regard.

One possible cause could be a bug with the OSX drag-and-drop functionality. It's not something I've really used (outside of Qt). But, if you have a basic code sample, something that works in Windows, I can give it a try on a Mac tomorrow and see what happens.

I should probably ask what version(s) of Maya are you having this bug reported on?
  01 January 2013
I mention the drag-and-drop issue because it suddenly appeared and only on OSX.
It was reported on Maya 2013.

I already checked the documentation to see whether any of the commands I use have been updated/altered in 2013, but they haven't (I'M developing this on 2012).

Anyhow, I can't offer short example code because I can't be sure that it would replicate the problem. INstead, I can point you to the script in question:


(It's a zip because it contains images for the UI that need to be installed to the icons folder)

I'd greatly appreciate it if you could take a quick look and see what happens when you run the script (it's a GUI Picker, so you'd have to create a cube or sphere or something and create some buttons for them). The issue has been reported when middle-mouse dragging buttons within the UI, which on Windows works like a charm.
  01 January 2013
Hey Nyro,

First, I can confirm that the drag-and-drop functionality of the picker doesn't work on OS X (Maya 2012). That's the bad news. The good news is I think it can be reworked so that it will work on both Windows and Mac.

To make it work on OS X I moved the drop callback from the button to the column layout that holds the button. I then tweaked the (move) drop callback procedure to expect the drop ctrl to be the layout.

string $dropParent = $dropCtrl;

It wasn't perfect, and the drop callbacks will need further modification to support the change (e.g. the 1st button can't be dragged down), but the drag-and-drop behavior appeared consistent on Windows and OS X.

I can't give a definitive answer as to why using the layout drop works, but I'm guessing it has to do with the different window manager behavior between Windows and OS X. Even using Qt to unify the environment, there are still some differences with the advanced windowing functionality that isn't quite the same between the two OSes. Throw in Linux and it can become maddening. It's hard to fault anyone for this (Autodesk, Qt, Microsoft, Apple) there are so many highly specialized little differences that it can be near impossible to account for them all.
  01 January 2013
Thanks alot, Chris!

That's some invaluable information right there. Since I don't have access to a mac for development, I would never have found this workaround on my own.
I'll get to implementing the change right away, and I'm sure I'll find workarounds for the problems you've listed once I encounter them.

  01 January 2013
Hey Chris,

if I may bug you once more:

I've implemented the change (effectively just changing 2 lines of code) as you suggested, placing the dropCallback on the layout instead of the pickerButton.

It works here under Windows. In fact, it works like a charm, no observable difference to indicate any change (which is good, normally).
However, since you mentioned issues (e.g. the first button not being draggable) which I'm not experiencing here, I wonder what I may have overlooked.

I'm sending the script out to afriend with OSX to be tested, but he's not, ah, technically minded and thus won't be much help when an actual problem occurs. So I was wondering whether you could quickly tell me why you think any issues might arise or whether you actually experienced any.

Thanks a bunch!
  01 January 2013
The modifications I did were just to confirm drag-and-drop worked (quick and dirty) so I may have introduced the problems on my own. The good thing was, the problems were the same on both Windows and Mac.

I did a quick retest and the thing I was finding was that the drop "hit-box" was weird.

When dragging a button up, I would need to drop it on the top half of the button I wanted to move it to, otherwise it would be placed one lower.

When dragging a button down, I would need to drop it on the bottom half of the button I wanted to move it to, otherwise it would be placed one higher.

Otherwise, it did work as expected. Again, all of this was tested on Maya 2012 (Win & Mac).

Something to keep in mind if the dragCtrl is a button and the dropCtrl is a layout, the comparison at the start of aweCPMovePicker() will always return false:
if($dragCtrl != $dropCtrl) {
You may need to update this section of code (and others like it, if they exist).
  01 January 2013
Ah ok, so I'm relieved. From what I can tell, the issues were either due to your quick implementation or actual design.

The thing you mention with having to drop on the lower half are actually a feature:

To insert a Picker before another Picker, you drop on the upper half. To insert after, you drop on the lower half.

if($dragCtrl != $dropCtrl) {

Yep, I caught that and took it out. There wasn't a real reason for it to be there in the first place anyway

Again, thanks for your help! I owe you one
  01 January 2013
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 06:16 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.