Hiding/disabling Maya's UV Editor via MEL script

OK, here’s a question for Maya MEL scripters.

I’ve written a script which does some heavy editing of UVs and vertices, which if run when only a 2d/3d model view is visible, runs really fast.
As soon as the UV Texture Editor window is visible, the script slows down hugely, because Maya feels the need to refresh the selection on every change in the UV view (something which it doesn’t do in other viewports).

So what I want my script to do is detect if the UV panel is open/visible (I already know how to do this, and that’s ok), but then it should either “disable update/refresh” in the UV panel, or hide/replace the UV panel until the script is done, then show it again if it was visible in the first place.

So far all the methods I’ve tried for removing it (un-managing the parent panel, using the removeTextureWindow proc, some other hacky techniques) all result in unsatisfactory end user experience. Most of the time if I un-manage or otherwise hide the window, when I put it back again after the script is run, it doesn’t update properly. Either it doesn’t respond to any input at all until you tear it off and re-dock it, or it displays properly but only in the portion of the screen that was visible before it was hidden (so increasing the panel size has no effect, the drawn region of UV editor stays the same).

In Maxscript all I had to do for a similar result was prefix my script “with redraw off”, and all was well. I haven’t found anything nearly as simple in MEL yet, hopefully someone can shed some light on this?

Cheers!

Hmm, that redraw issue sounds odd. I did a simple test where I did a deleteUI, ran some code, then called TextureViewWindow again and it seemed to work fine. Can you give me an idea of the kind of stuff you’re doing in between? Maybe it’s specific to what’s going on.

Haha, you just did deleteUI? Damn, why didn’t I think of that… Will try that out tomorrow when I get back into work. I didn’t even consider trying that, I think I just tried all the hardest and most convoluted ways without looking at the obvious one first!

Hehe, well as they like to say in my home state of Arkansas “i ain’t to swuft. . .” i tend to brute force alot of stuff out of the gate and then refine from there(production schedule and artists’ patience permitting, hehe). On a side note i did do a comparison test using removeTextureWindow and did see some refresh wierdness. . .i wonder if it’s just Maya wanting things to be cleaned up. On another side note, i hate doing UI stuff in MEL:D:

Ah yeah, you’re right, using deleteUI then calling TextureViewWindow does work, however this always “Tears Off” the window again even if it was originally docked. So I guess if I use this method, and want to return the UI to the state before the script was run, I’ll have to put the UV window back into the appropriate view panel if it wasn’t Torn Off to begin with.

Yeah, i think that might just be a good thing to think about anyway though, like you could create a placeholder code object that holds the last state of the UV window, then you could capture all sorts of things ie what someone had selected, window position, size, etc, then just restore the UV window to exactly the previous state, something like that?

Came up with a decent solution. If the texture window was “Torn Off” to begin with, my script now just does deleteUI on it, then calls it back with TextureViewWindow.
And if it’s an actual view pane in the main pane layout, it sets the active pane to any other pane and does the panePop command to maximise the viewport to a single display.

The only time this won’t work is if you have your UV window as a single docked pane, however I don’t know anyone who works like this. I’ll probably work out a solution to this one eventually too. Swapping views into panes doesn’t work because the rest of the script seems to kick in before Maya actually manages to swap the pane (I was just trying to swap in one of the generic front/side/top model views).

And yeah, I basically restore the window position/size, and the selection once the script has run. Nothing else is affected so it should stay consistent before and after.

Oh well, it all works well enough now, thanks for the help!

That’s pretty similar to what I do for most of my UV scripts too: close any floating UV window and restore it if it was closed. If it’s docked into a panel, I switch it and restore it back later. I can’t remember if I had any problems with it not updating, maybe throw a “refresh” call in there before continuing on with your script to update the UI?

Oh man, call me Captain Idiot…

The only reason I wanted to close the UV window is because whenever I was making a selection in my script, the UV window would refresh. The vast majority of these were conversions between UVs, vertices and edges. However the only reason I was doing this is because I was porting a script I wrote for 3dsmax into MEL, and so I was converting using the “physical” methods (eg. “select -r $whatever; PolySelectConvert 4;”), and that’s the only reason it was updating.

So I just converted all of my script over to use “polyListComponentConversion” and then all the refresh problems went away, since it was all happening in the background, so I don’t even have to hide the UV window after all!

I also noticed that I should always use “filterExpand” after a “polyListComponentConversion”, because otherwise you get back ranges of items (eg. obj.vtx[1:19]), which doesn’t play nice with iterating over a selection, and there doesn’t seem to be a flag on “polyListComponentConversion” to make it expand ranges automatically.

Oh well, I guess I’m learning :slight_smile:

Now my script works perfectly, and doesn’t call for any “undoInfo -swf 0;” stuff that I needed before when it was actually making selections physically.

[QUOTE=MoP;724]Oh man, call me Captain Idiot…
[/QUOTE]

Can we just call you n00b instead? i kid, i kid!!:D: That’s maya hell, a million different ways to do things. . .finding the best one is an epic conquest that men lose their minds during and tales of which are told to frighten children. . .

Bah, scratch that, it only worked for one of my scripts which deals only with simple UV selections.

I have another script which works on UV shells, and the polySelectBorderShell command seems to be the only way to get a UV shell selection from a single UV, and that’s actually a “physical” command resulting in a selection.

There doesn’t seem to be a way to return an array of UVs making up a shell without doing this, so that of course refreshes the UV window and generally slows things down.

So I guess in this case I will still be hiding the UV window…

Edit: Looks like I can use Python to access the API and use MFnMesh:: getUvShellsIds to find the information I want. Shame this isn’t exposed to MEL script, since I don’t know Python at all and I haven’t got the first clue about the API!
Oh well, gotta start somewhere I guess…