Can anyone confirm that "DialogMonitorOPS.GetWindowHandle()" is actually returning a valid window handle anymore in 2017? No matter what I try, even the example in the documentation, it either doesn't return anything or returns "0P". From what I understand, if I run the code below, when I launch the "Customize User Interface" dialog, there should be some information logged to the MAXScript Listener... but there isn't! I'm also experiencing similar issues with "DialogMonitorOPS.GetWindowHandle()" in other third party plugins and scripts.
The code I am using currently for testing is:
DialogMonitorOPS.unRegisterNotification id:#eyeInTheSky fn dmnotification = ( WindowHandle = DialogMonitorOPS.GetWindowHandle() format "Dialog Window Handle: %\n" WindowHandle format "Dialog Name: %\n" (UIAccessor.GetWindowText WindowHandle) format "Window Class Name: %\n" (UIAccessor.GetWindowClassName WindowHandle) format "Window Resource ID: %\n" (UIAccessor.GetWindowResourceID WindowHandle) format "Is Window: %\n" (UIAccessor.isWindow WindowHandle) format "Window DLL Filename: %\n" (UIAccessor.GetWindowDllFileName WindowHandle) format "Window DLL Description: %\n" (UIAccessor.GetWindowDllDescription WindowHandle) UIAccessor.SetWindowText WindowHandle" All Your Windows Are Belong To Us" format "=====================\n" true ) DialogMonitorOPS.RegisterNotification dmnotification id:#eyeInTheSky DialogMonitorOPS.Enabled = true DialogMonitorOPS.ShowNotification()
Any help or clarification would be greatly appreciated! Thanks!
Works as expected here (2017 SP2), what servicepack version are you on?
Dialog Window Handle: 16202474P Dialog Name: Customize User Interface Window Class Name: Dialog Window Resource ID: 0 Is Window: true Window DLL Filename: C:\Program Files\Autodesk\3ds Max 2017\CustDlg.dll Window DLL Description: =====================
We're on SP3 currently. I'm going to try and see what the results are with a clean install. Perhaps some of the custom tools we have here could be interfering some how.
And there you have it! It seems something in our custom tools is causing a conflict. On to the troubleshooting! If I find the culprit, I'll be sure to post back with details.
So, it looks like another callback we are registering on startup is interfering somehow. It seems to prevent my test callback from being called. When I disable the startup callback, everything works as expected. There's nothing complex going on with this startup callback either, so I'm a bit stumped. You are supposed to be able to register multiple notifications with DialogMonitorOPS, correct?
I can't english well 😞
I have same problem few years.
Reset ENU folder and try DialogueMonitorOPS.GetWindowHandle(), it's work.
but I using some callbacks in macro. it doesn't work.
I think it's callback event's compile order issue.
1. Reset ENU
2. run 3dsMax
3. run DialogueMonitorOPS script
4. max close
5. add Macro(callbacks) in usermacro folder
6. run 3dsMax
It's work.
1. Reset ENU
2. add Macro(callbacks)
3. run Max
4. run DialogueMonitorOPS script
It doesn't work.
※ If you use ENU/script/startup/startup.ms (regardless of callback)
It doesn't work. never
DialogMonitorOPS registers notifications about pop-up windows and notifies about them when the window is already shown and activated. Therefore, there is no point in "hanging" and listening for all "pop-up" windows. This is usually used to intercept any particular window that is already ready to be shown. After that, the monitor is usually turned off.
Multiple callbacks can be registered at the same time, but each must be unregistered independently, not by shutting down the entire monitor.
You can assume that the monitor is used by another process (tool, script) that shuts it down after use. You register your notification while the other process is running. Thus, the first process disables the monitor for you before you receive the notification.
Now the question is what to do about it... the only solution is to find this process (the original script) and fix or kill it.
But for your process, kindly, instead of disabling all monitoring, just unregister your callback... At least if monitoring was already enabled at the time of your registration.
Thank you for your answer.
Bad new is that, if you used 'ENU/script/startup/' even once
the only way to use DialogueMonitorOPS is reset ENU folder.
callback and DialogueMonitorOPS used in startup folder
DialogueMonitorOPS is enabled and it didn't disable and unregisterNotification because it had to continue.
and callback too.
callback.addscript #postExport
I learn callback scope, so I solved the problem.
I temporarily stopped callback and DialogueMonitorOPS being used in startup folder, ran DialogueMonitorOPS (I want) and then activate them again.
Thank you for your help, I learned from it
Thank you!!!
How do you stop the callback from startup? Probably by unregistering by id…
but how do you know the id?
yes, I set id, and remove callback.
Scripts in startup folder were created by other people.
I didn't know about callbacks until now.
I was able to learn about event callback scope at this time.
but I knew a little bit about scope and I had create feature to back up a previous state and revert that.
so I read DialogMonitorOPS and callback manual several times and try it again.
It's not a universal solution... because it cannot be automated.
MXS does not provide methods to retrieve the list of registered notifications, their IDs and status.
there is DialogMonitorOPS.ShowNotification()... but as I know it can't return the list into a variable
yes, I think so too, but for now I got results what I want.
I used another DialogMonitorOPS in Macroscript.
Having to change settings with multiple clicks each time is very tiring task.
so I wanted rollout button click to change viewport configuration settings.
I'm still studing Maxscript now, I don't know how I get a function in another file for macroscript.
(Today I learn include and filein's different, but I don't know)
I'm not comfortable with copy and paste function code into a macro to redeclare the callback.
I think this is the limit of my current skills now.
Do you have any advide for me? 🙂
open a new topic with your last post...
this seems like a different subject, and there's no point in continuing someone else's topic.
I agree, I was just trying to explain my situation.
Thank you for your help again.