Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

:vlr-SysVarWillChange

21 REPLIES 21
Reply
Message 1 of 22
Anonymous
441 Views, 21 Replies

:vlr-SysVarWillChange

Is it just a VisualLisp limitation that many sysvars won't fire a reaction, such as "ctab" "viewctr" "viewsize?" Are there other programming languages that can recognize their change? I realize that the vlr-AcDb-Reactor will fire on many things (still excepting "viewctr" and "viewsize"), but that's exactly why you can't use it in real life... way too many reactions. -- John Uhden, Cadlantic http://www.cadlantic.com Sea Girt, NJ
21 REPLIES 21
Message 21 of 22
Anonymous
in reply to: Anonymous

Then one last opinion(if I understand the underlying problem). Why not mirror layer state data in your own custom dictionary. Then you can easily "restore" a deleted layer state programatically, add a custom xrecord with handle information of the layout(s) the layer state is attached to, and keep track of associated layer states like deleting un-used ones (maybe providing the user with a back-up mechanism in that instance). You would still access the LayerStateManager via activex to apply layer states to the active document, you just have your own "untouchable" record to keep things coordinated. You could set up your own GUI for createing, editing, and associating layer states with layouts AND react to the layer command when users "inadvertainly" do an end around and edit layer states there. I've certainly got alot out of this discourse. I can see where a program like this would have far reaching benifits in a small architectural firm that doesn't need a heavy handed "Standards" program. I don't have time right now - I don't know how I'm going to get through this month - but I'd like to play around with this when I get a chance. I'll fill you in if I do . . .. jb
Message 22 of 22
Anonymous
in reply to: Anonymous

Thanks, James. I'll take it this is the last entry (it's about time) in this thread. Yes I had experimented with the CopyObjects method to clone LayerStates to a different owner's dictionary; works well. Unfortunately, my head was turned to saving the copy in the layout's ExtensionDictionary which (I think) caused access problems during the LayoutSwitching. Regardless, the obstacle still becomes one of not being able to ascertain a rename or a creation by copy, but what the hey? You may be right that it can all work simply by handles. Hmmm... wish I had more time to play. Got home at 11; gotta leave by 7. Sounds like craps, eh? 🙂 Thanks for all the insight. G'night. -- John Uhden, Cadlantic http://www.cadlantic.com Sea Girt, NJ "James Buzbee" wrote in message news:40449e8d$1_2@newsprd01... > Then one last opinion(if I understand the underlying problem). > > Why not mirror layer state data in your own custom dictionary. Then you can > easily "restore" a deleted layer state programatically, add a custom xrecord > with handle information of the layout(s) the layer state is attached to, and > keep track of associated layer states like deleting un-used ones (maybe > providing the user with a back-up mechanism in that instance). > > You would still access the LayerStateManager via activex to apply layer > states to the active document, you just have your own "untouchable" record > to keep things coordinated. You could set up your own GUI for createing, > editing, and associating layer states with layouts AND react to the layer > command when users "inadvertainly" do an end around and edit layer states > there. > > I've certainly got alot out of this discourse. I can see where a program > like this would have far reaching benifits in a small architectural firm > that doesn't need a heavy handed "Standards" program. I don't have time > right now - I don't know how I'm going to get through this month - but I'd > like to play around with this when I get a chance. I'll fill you in if I do > . . .. > > jb > >

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost