Maxwell Render | Official public forum

when i open a linked mxm using the mxm edit button of the plugin i can't sample any color using the mxed color picker. When i click somewhere on the screen i get a complete freeze and have to kill the mxed.exe in the taskmanager.

(v3.0.1 and plugin v3.0.5)

I'm not yet able to reproduce this, checking in SU8 (I think you use that) and SU2014. Could you please let me know more precisely what is meant by complete freeze? Since you say you can kill mxed with task manager, I guess you must mean mxed only. Additionally, are you able to reproduce it when starting mxed directly, or only from within the plugin?

yes, sorry... you're right, SU8.
Freeze maybe isn't the right description - i can't access anything with the mouse, the cursor doesn't change back, the keyboard (windows key etc.) is working.
After opening the taskmanager using strg+alt+del i can access everything again, but only until i select the still opened mxed or SU again.

It happens only from within the plugin.

Sorry, but I don't have many ideas at this point, there must be some missing key factor. My instinct would be to try enabling or disabling Windows Aero, and/or various graphics adapter settings, to see if one of them makes a difference.

Looks like there's another report of this, but also happening in Studio: http://www.maxwellrender.com/forum/view ... 08#p380908.

in studio i don't have this problem (v3.0.1)

The problem is still there (v3.1.1), but not only in SU (SU2015 plugin 3.1.3) but also for the max plugin (2014, plugin 3.1.

Opening the tast manager stops the "freeze"

I still have never observed this here, and don't expect to, since as I wrote above, it seems like a problem that would be related to something in the OS (e.g. some third-party program installing a system-wide hook that is not properly passing messages along to Windows, or is not releasing control when it should, and so forth, the hint being that by forcing the focus on Task Manager, you're apparently able to break out of the loop), or to graphics drivers, or graphics adapter settings.

Thanks! I'm currently setting up a new workstation. I hope this will solve the issue - i will report back how it goes...

If it does occur on the new machine, then the questions would be: which other programs have been installed, and how similar are the graphics adapters & drivers. Because of that, I'd recommend making sure to install Maxwell first, in order to check it before other programs are installed.

Yes, I'll do so

I just wanted to note that there's an extremely similar side discussion going on about this issue that may be useful:

http://www.maxwellrender.com/forum/view ... 18#p391318

Hi Zack, thanks for the input -- unfortunately, being machine-specific, I don't think I can say much more than I have above. I've written a similar function (mine works by starting to sample when you right-click down, and grabs the color under the cursor when you release the mouse button, using standard GDI methods) before in the Rhino & SolidWorks plugin material editors, but those are Windows-only, and using .NET instead of Qt.

Hey JD,
If I understand your response, MXED is written in Qt? If so (and if its permissible to disclose), do you know which version of Qt and is it using the QCursor class with a custom bitmap for the cursor? Perhaps there's something similar happening in other deployments of Qt that use that class. I can poke around the web to see if there's anything like this happening in other Qt based apps if in fact that's what's running MXED.

I'm using Maxwell 3.2.1.4 w/ 3ds Max plugin 3.2.9. I'm pretty sure the 3ds Max plugin version is irrelevant since I can briefly see the CMD call / prompt that launches the "mxed.exe" binary directly.

Thanks JD!

All of Maxwell's gui applications are built on Qt, and 3.2.1.4 is using Qt 4.8.7 (if you ever need to check, you can always look at the file metadata for the Qt dlls in the Maxwell 3 directory). As for how this function is written, and which classes it uses, I don't personally know. But, I do know just from observation that when cursors, especially, are involved, Qt may choose to use acceleration, since I've seen what I took as pretty clear visual evidence of that on odd occasions. However, in the case of being started from another application, where that application must wait on mxed to finish, I also suspect third party software installing system-wide hooks (since the problem is machine-specific), where this ends up screwing up Qt's ability to properly pump windows messages, through corruption of memory, failure to properly forward messages, and so forth.