try this simple test:
callbacks.removeScripts id:#viewport_changed
fn on_vp_changed =
(
format "% %\n" (timestamp()) #changed
)
callbacks.addScript #viewportChange "on_vp_changed()" id:#viewport_changed
It works as expected in my MAX 2020, sending notifications for every “change” to the viewport, including Pan and Zoom actions. But only when the scene is empty. As soon as I make any visible objects, the Pan and Zoom notifications disappear.
You can hide or remove nodes from the viewport... and the notifications come back.
This problem is not present in MAX 2023.
So, could you please confirm or deny me this problem?
try this simple test:
callbacks.removeScripts id:#viewport_changed
fn on_vp_changed =
(
format "% %\n" (timestamp()) #changed
)
callbacks.addScript #viewportChange "on_vp_changed()" id:#viewport_changed
It works as expected in my MAX 2020, sending notifications for every “change” to the viewport, including Pan and Zoom actions. But only when the scene is empty. As soon as I make any visible objects, the Pan and Zoom notifications disappear.
You can hide or remove nodes from the viewport... and the notifications come back.
This problem is not present in MAX 2023.
So, could you please confirm or deny me this problem?
If this problem does exist, does anyone have any idea what can be “listened to” to still get these notifications? I'm assuming the system has them since everything is drawing on time.
I'm overriding the WinProc of an active viewport window, and that seems to work. However, I need the specific viewport change notification because it's tied to the mechanics of viewport redrawing and is synchronized to a specific moment.
If this problem does exist, does anyone have any idea what can be “listened to” to still get these notifications? I'm assuming the system has them since everything is drawing on time.
I'm overriding the WinProc of an active viewport window, and that seems to work. However, I need the specific viewport change notification because it's tied to the mechanics of viewport redrawing and is synchronized to a specific moment.
Of course, it's possible to register a Redraw Views callback, but this solution has two main problems:
This makes using the redraw callback heavy and uninformative.
Of course, it's possible to register a Redraw Views callback, but this solution has two main problems:
This makes using the redraw callback heavy and uninformative.
Just tried this in 2025 and I do get the notifications. In fact I even get more than I would expect.
This is the output from unmaximizing a single viewport back to quadruple view:
69015857 #changed
69015869 #changed
69015884 #changed
69015895 #changed
69015910 #changed
69015923 #changed
69015936 #changed
69015951 #changed
69015978 #changed
Martin Breidt
http://scripts.breidt.netJust tried this in 2025 and I do get the notifications. In fact I even get more than I would expect.
This is the output from unmaximizing a single viewport back to quadruple view:
69015857 #changed
69015869 #changed
69015884 #changed
69015895 #changed
69015910 #changed
69015923 #changed
69015936 #changed
69015951 #changed
69015978 #changed
Martin Breidt
http://scripts.breidt.netAlso I do get these notifications while creating a new object - but only if I am in quadruple view...
Martin Breidt
http://scripts.breidt.netAlso I do get these notifications while creating a new object - but only if I am in quadruple view...
Martin Breidt
http://scripts.breidt.netThe problem has been fixed in MAX 2022. I ask to check this in 2020 and possibly earlier versions.
Anyway, thanks for your participation in solving the problem.
The problem has been fixed in MAX 2022. I ask to check this in 2020 and possibly earlier versions.
Anyway, thanks for your participation in solving the problem.
I currently have three available versions: 2020, 2022, and 2023.
In versions 2022 and 2023, the viewport change callback works as expected in all cases. However, in version 2020, the callback does not fire if any objects are visible in the viewport.
To solve this, I have used Window subclassing mechanics to specifically check events with the mouse button-down state, MOUSEWHEEL, NCHITTEST, and TIMER. It seems that version 2020 uses WM_TIMER messages to update the
viewport, but I don't see the same messages in versions 2022 and 2023.
I believe this is a bug. Since I don't think it can be fixed in the earlier version and I have my patch for it, I'm not too concerned. However, it would be nice to get confirmation from Autodesk that the issue occurred and has been fixed in the latest versions.
I currently have three available versions: 2020, 2022, and 2023.
In versions 2022 and 2023, the viewport change callback works as expected in all cases. However, in version 2020, the callback does not fire if any objects are visible in the viewport.
To solve this, I have used Window subclassing mechanics to specifically check events with the mouse button-down state, MOUSEWHEEL, NCHITTEST, and TIMER. It seems that version 2020 uses WM_TIMER messages to update the
viewport, but I don't see the same messages in versions 2022 and 2023.
I believe this is a bug. Since I don't think it can be fixed in the earlier version and I have my patch for it, I'm not too concerned. However, it would be nice to get confirmation from Autodesk that the issue occurred and has been fixed in the latest versions.
By the way... An attempt to use the registered redraw views callback failed. The notification comes too late for my needs and makes it difficult to determine the specific cause of the redraw.
By the way... An attempt to use the registered redraw views callback failed. The notification comes too late for my needs and makes it difficult to determine the specific cause of the redraw.
Can't find what you're looking for? Ask the community or share your knowledge.