Interesting idea. In the SDK there is Interface::AbortRender() that could be used for this taks.
i think that AbortRender() can very useful as mxs extension. let’s say in the case when ‘potentially long rendering’ was run with ‘wrong’ settings.
#preImageViewerDisplay callback returns IVFB Interface as notification param. it means that VFB hwnd is already created at that moment. if we know the hwnd we can close the window before it will be opened. the question how to know it. any ideas?
i could find nothing about the VFBInterface (or IVFB) in max SDK.
I’ve been down this road already. There is no way to get the HWND from Maxscript or the SDK. If you find such a way I will literally bang my head against the wall and increment the counter that keeps track of how many beers I owe you.
Anyways, to get the VFB HWND you have to get it yourself by enumerating windows and checking the class of their first child.
The first child of any image viewer is a BitmapWindow control.
In order to determine if this is a regular image viewer or the main VFB you must check the first child of the BitmapWindow, which is the toolbar. You must then count it’s buttons. The main VFB will have at least 10 CustButton controls in the toolbar, while a regular image viewer will have at most 9.
If anyone is interested I can share the C++ code that does this.
lo,
do you think that at the moment of preImageViewerDisplay fires all VFB window children already created? i’m not sure.
IVFB knows for sure the vfb hwnd. everyone who have debug version of max (mean its source code) can see how they do it.
No, I am doing this on postImageViewerDisplay. on preImageViewerDisplay the VFB HWND is not yet created. The VFB object may be in existence but it has probably not yet called CreateWindow.
the interesting fact is that #preImageViewerDisplay event fires before my hooker catches any vfb window message. that means system creates vfb window after the event.
Isn’t that what you would expect? I suppose the order of events is something like:
[ul]
[li]create VFB object
[/li][li]broadcast preImageViewerDisplay
[/li][li]create VFB Window
[/li][li]broadcast postImageViewerDisplay
[/li][/ul]
i was wrong. the VFB window is created BEFORE #preImageViewerDisplay fires. it makes sense. it’s activates after. i just had to use HCBT_CREATEWND message…
The most ideal solution would be to have a way to return the IMaxBitmapViewer or IImageViewer from an imageViewer callback.
ok. i’ve almost solved it.
what do i do
catch #preImageViewerDisplay event
setup CBTHook
if in time between preImageViewerDisplay and preRender events any window with first child ‘BitmapWindow’ created i kill this window (close)
catch preRender event and destroy CBTHook…
it works! the same way i can close render progress window as well.
one problem standard “VFB_methods” callback from “VFB_methods.ms” file throw error message about deleted IVFB interface (which I did :))… it’s only one line to fix but … it’s not my code.
You could just destroy it on #PostImageViewerDisplay instead of on #PreRender, no?
theoretically yes. but when i try catch PostImageViewerDisplay event after vfb destroyed the system throws Unknown system exception
so it needs another investigation
looks like the system is very surprised when some one kills VFB except the system itself.
but i’m absolutely sure that has to be a safe way to kill VFB