now bind the spinners:
try(destroydialog trackbarNavigatorLight) catch()
rollout trackbarNavigatorLight "Trackbar Navigator" width:327 height:24
(
spinner sa_sp fieldwidth:50 range:[-1e9,1e9,0] type:#integer pos:[0,4]
spinner sr_sp fieldwidth:50 range:[-1e9,1e9,0] type:#integer pos:[61,4]
spinner er_sp fieldwidth:50 range:[-1e9,1e9,100] type:#integer pos:[200,4]
spinner ea_sp fieldwidth:50 range:[-1e9,1e9,1000] type:#integer pos:[261,4]
fn update event:#custom =
(
-- format "event:% range:%
" event animationrange
if sr_sp.value != animationrange.start do sr_sp.value = animationrange.start
if er_sp.value != animationrange.end do er_sp.value = animationrange.end
)
fn setRange start:animationrange.start end:animationrange.end =
(
end = amax end (start+1)
start = amin start (end-1)
if animationrange.start != start or animationrange.end != end do animationrange = interval start end
)
on sr_sp changed val do setRange start:val
on er_sp changed val do setRange end:val
on trackbarNavigatorLight close do
(
callbacks.removescripts id:#trackbarNavigatorLight
)
on trackbarNavigatorLight open do
(
callbacks.removescripts id:#trackbarNavigatorLight
call = "if trackbarNavigatorLight != undefined and trackbarNavigatorLight.open do trackbarNavigatorLight.update event:"
callbacks.addscript #animationRangeChange (call + "#range") id:#trackbarNavigatorLight
callbacks.addscript #filePostOpen (call + "#open") id:#trackbarNavigatorLight
callbacks.addscript #systemPostNew (call + "#new") id:#trackbarNavigatorLight
callbacks.addscript #systemPostReset (call + "#reset") id:#trackbarNavigatorLight
callbacks.addscript #postSystemStartup (call + "#start") id:#trackbarNavigatorLight
update()
)
)
createdialog trackbarNavigatorLight style:#(#style_titlebar, #style_sysmenu)
do you see the problem?
the callback binding is almost finished. expect the problem that you are looking for… but it will be very easy to fix.
now it’s a good time to think about how to store our data in file and make our tool undoable.
any suggestions?
also… we need to add “global range” functionality.
Aha i see the problem,I think for callback is natural behavior , one call for startframe, one for endframe.
About storing data i think we can use SceneRoot or fileProperties.addProperty.
About undo i think we can use undo contex ,umm?
Why you use this complex method to set animationrange?
on sr_sp changed val do
(
end = animationrange.end
animationrange = (interval Val end)
)
on er_sp changed val do
(
start = animationrange.start
animationrange = (interval start Val)
)
Problem with this way?
first of all because max doesn’t allow to set ZERO length time interval.
second because you don’t not check difference of new and old intervals you set it any way, and it causes the range changed callback. do you need it? i don’t.
but this is not the problem…
what exactly this spinners (sa_sp,ea_sp) wanna do?
these are spinner for the ‘global range’.
for example, the animation is 1000 frames long. but you work only in interval from 100 to 200.
in this case the global range is from 0 to 1000, working animation range is from 100 to 200.
i want use the same mechanism for both data storage and undo/redo system. so fileProperties doesn’t work.
so what we have?
the rootnode and CA added to it… any alternatives?
I think putting data in a dummy is better than SceneRoot, because we can merge it later, maybe for getting data from file.I always use setuserprop for storing data not CA.
the User Defined Object Properties is very unsafe way to store a data. it’s too easy for any lamer reset/change/delete it.
it’s node a bad idea to use some extra node… but again… the lamer will delete it for sure.
aha i got it, CA is undo-able, animatable, safe, and fast.is it hide in curve editor?
yes… it’s hidden. but i have a better idea.
unfortunately the adding CA to rootnode is not always safe. in some situation when current scene uses older CA definition than an xref scene that might cause the problem. it depends on the type of stored data. but any way it better to use CA added to the rootnode with caution.
what about AppData mechanism?
the same problem… it’s not undoable. but for your knowledge the setting of AppDatais to the rootnode is much safer than CA.