Mel script, correct way to call a built in procedure into a GUI?

[malcolm_341]

Hey I have a custom mel GUI that calls $myVariable = texGetShells(); which is procedure in scripts/others from the Maya default folder. I get an error the first time I try to run my button that calls it, but if I launch the GUI a second time then everything works fine? What is the correct way to call an existing Maya procedure in a GUI? I hacked it by copying the whole procedure into my GUI and making it a global proc, is there something cleaner?

[jmreinhart]

It could be that your script is not in a directory that Maya is set up to look for .mel scripts in. Running the following line will allow you to see all the directories Maya can "see" when trying to source a script:

getenv("MAYA_SCRIPT_PATH") ;

If the folder your mel script is in is in that list then you may have forgotten to source your script, which you can do with a line like this:

source theNameOfMyMelFile;

[malcolm_341]

It works fine if you call the proc from a button or in the script editor, this is some annoying behavior because it's in a GUI that I've run into before, so I'm just trying to learn what Autodesk intended me to do to call a proc they created inside of my simple GUI. I did try sourcing the script, but not with a specific path and that didn't work. Maybe I'm naively assuming procs that are part of Maya located here should just work?

C:\Program Files\Autodesk\Maya2019\scripts\others\texGatherShells.mel

Edit, I just tried that code and that location is indeed listed, so this has to be that I just don't understand how to source the script, so what should I try?

[jmreinhart]

source "others/texGatherShells";
window -title "Test Window" -mnb false -mxb false;
rowLayout();
button -c "print_hello()" "test";
showWindow();

You may have forgotten to put "others" in your source line, just the .../scripts folder is in that list of files Maya can source from, doesn't mean it knows about the folders within that folder, unless you specifically tell it too look there (like in the above code).

print_hello() is just a dummy prodecure, whatever function you are trying to call. Make sure that the prodecure you are calling is global. The global function inside texGatherShells.mel can call non-global prodecures that are also inside texGatherShells.mel.

Hope that helps you sort out what's going wrong for you.

[malcolm_341]

I did forget to add the others folder, but unfortunately that doesn't help the script from finding the proc that is built into Maya. Same error unless you launch the window a second time. Here's the exact problem if you launch this window and click the button it can't seem to find the contents of texGetShells.mel even though I just sourced it?

global proc myButton()
{
source "others/texGetShells.mel";
ConvertSelectionToUVShell;
$shellUVs = `ls -sl`;
$findShells = texGetShells();
$numbShells = `size $findShells`;
$shellIndex = 0;

for ($item = 0; $item < $numbShells; ++$item)
{
select $shellUVs;
$findShells = `texGetShells`;
tokenize($findShells[$shellIndex], $findShells);
select $findShells;
}
}

window -title "Test Window" -mnb false -mxb false;
rowLayout();
button -command "myButton";
showWindow();

[jmreinhart]

global proc myButton()
{
    source "others/texGatherShells";
    ConvertSelectionToUVShell;
    $shellUVs = `ls -sl`;
    $findShells = print_hello();
}

window -title "Test Window" -mnb false -mxb false;
rowLayout();
button -command "myButton";
showWindow();

So this test code worked for me. I did notice that your script has changed from texGatherShells to texGetShells. Is it possible that you've changed the name of the file in the script but not the name of the actual mel file?

I would recommend putting a dummy procedure (like print_hello) into the mel file you are trying to source and running the code above. If that works then we know that the issue is with some other part of proc myButton or the contents of texGetShells. If it doesn't work then we still haven't resolved the sourcing issue.

When you paste code in this forum it's best to press the "</>" button because it will guarantee that the indentation formatting is correct.

[malcolm_341]

EDIT Yeah sorry I typed the wrong command when I first posted, the texGetShells.mel is the script I'm trying to source.

So to do a clean test I replaced the contents of texGetShells.mel with create sphere, this now works, but when I copy the original contents back in it doesn't work. The test is pretty simple at this point, select some UV's and click the button, nothing happens. I'm starting to think there's something special about this global proc I'm trying to source.

global proc myButton()
{
source "others/texGetShells.mel";
texGetShells();
}

window -title "Test Window" -mnb false -mxb false;
rowLayout();
button -command "myButton";
showWindow();

[jmreinhart]

Ok, then we've narrowed down the issue quite a bit. Something within the contents of the function you are sourcing is causing an issue.  I can only think of a few things that could be causing it, like if you are sourcing other mel files within the file you are sourcing from the ui.

I would suggest commenting out the whole script contents, and testing the first section by itself, then the first and second, and so on until it fails.

If you post the code here I can take a look as well. Best of luck 

[malcolm_341]

Good idea, the way the global proc is written though I've never seen it before I'm used to seeing:

global proc myProc ()

{

}

But in that one it's, which is unfamiliar to me?

global proc string[] texGetShells()

{

}

[jmreinhart]

What global proc are you talking about? Are you referring to an example?  The answer to your question though:

global proc myProc (){}
//this is just a normal global proc that returns nothing

global proc string[] texGetShells(){}
//by putting string[] before the name of your proc that means that it returns a string array 
//a string array is something like this ["cat","dog","bird"]
//you could change string[] to whatever type of value you want to return like float or int

[malcolm_341]

Oh interesting, thanks for clearing that up.