Jump to content

Sam Jones

Member
  • Content Count

    503
  • Joined

  • Last visited

Community Reputation

131 Spectacular

About Sam Jones

  • Rank
    500 Club

Personal Information

  • Occupation
    Technical Director
  • Homepage
    www.autoplotvw.com
  • Location
    Los Angeles

Contact Info

  • Skype
    AutoPlotVW

Recent Profile Visitors

3,932 profile views
  1. FUNCTION vsoStateGetExitGroup( hObj:HANDLE; VAR outGrpType:LONGINT) :BOOLEAN Super, but given the documentation state of "vsoStateGet..." functions in the Function Reference, what do I pass in the "outGrpType"? And, is the function only true when the path object is changed? Some things just wouldn't happen without you Josh.
  2. Also, is there a way to get the new location of a specified vertex (the last vertex).
  3. Is there an event, paramChange, or GetState result that will tell a path PIO that its path has been changed, usually by the Reshape tool? Yet again, TIA
  4. When placing truss using the truss insertion tool, it is possible to insert them so that they are identified as being part of a system. It is possible to select all of the truss pieces that are part of that system using the object context menu command "Select System Objects". I have a command that needs to identify or identify by selection all the members of the system of which the selected truss piece is a member. I have looked at all the records and fields that I can access using the GetRecord(object, index) and GetRField commands, and have had no luck finding a record field or parameter that will identify members of a truss system. Does any one know of a way for a command to identify all the members of a truss system? As Always, TIA Sam
  5. Undoubtedly, but I have never used the procedure. Not only do you want to know if Event Aware is required, but also, what event to place it in. Good luck; I'm looking foward to hearing from someone who knows.
  6. Which dimension is the "length"? The greatest? What about height? There are objects that have a greater height than length. There may be an answer that I'm not seeing, probably not seeing, but the answer to which is dimension is length is not obvious to me. The length of a lighting device might be defined as the axis defined by the center of the lens to the focal point of the lens. This would not be the length, but it would define the axis along which length could be measured. However, that would only apply to lighting devices, and there are number of theatrical lighting fixtures that have a greater width than length using that criteria. I doubt that VW would want to have length functions that were based on relative dimensions as they would vary greatly in clarity from application to application. I'm not saying there is not an answer, but it does not seem obvious to me.
  7. Raymond, Preliminary testing seems to show that this works wonderfully. I still have some extensive testing of the cleanup routine to be sure I can do everything I need to do, but there doesn't seem to be any reason why I could not. Thank you so much !!
  8. In other words, no. Oh well. It would have allowed for a lot of very desirable cleaning up for those PIOs that go around spreading information about themselves. It doesn't seem like it would be a big stretch to implement since OnDeleteDelete is already implemented.
  9. Is there an event that is generated when a PIO is deleted? Can this event be trapped and routines run before the completion of the deletion?
  10. please display the RigPoints with the requested attributes that meet the following criteria: The ".Type" parameter equals "1-Ton" AND the "LoadWeightLB" parameter greater than 2000 OR The ".Type" parameter equals "1/2-Ton" AND the "LoadWeightLB" parameter greater than 1000 :-) :-) :-) It looks like he wants data display to flag overloaded rig points.
  11. Josh, your template does not have a Reset event subroutine. Its not necessary, and the Main routine has the necessary event case of Reset event. However, the ResetEvent case calls the Main. Essentially, Main keeps calling itself. Recursion is cool, but I don't see a way to get out of the recursion loop. I think there needs to be a Reset subroutine that is called by Main in the Case event test. If not, if what you show actually works, please explain how you get out of the recursion loop. This could be cool, or it could be that you were in a hurry :-)
  12. Quick answer is no. The long answer is that you can get very far with a good PIO template and asking the rest of us what gives. I'm kind of at the bottom of the asking wrung. Andy knows a lot about VS drawing and he gets help from the mothership because they keep purchasing upgrades to stuff he sells them. Not as much as he might occasionally want but enough to get the job done. Josh did a deep dive of research into SDK constants and then into the SDK itself, so I consider him my ultimate source. If there were enough of us, I would try to get him to teach a course on scripting PIOs, but I would be lucky to find 4 guys willing to pay money. So, I try to keep my questions to him one at a time. In some ways, you are lucky. Since you are just beginning scripting event aware PIOs, you will be able to go far with a good template and questions here. You can also try and hit up Kevin, Josh, Andy, and I, directly. Everyone one has a day job, so turn around time varies. These days, as sucky as they are, have tended to improve response times. Again, after a week, hit me up again for a little fuller template, unless my mentors come through first. BTW, Carlotta is another wonderful and talented resource, but as I understand it she has 2 jobs and very very busy.
  13. Unfortunately, the Chandler example is missing the kOnWidgetPrepEvent (41) which is where most of the formatting of the OIP and populating of drop down menus happens.. Strangely, indenting of parameters needs to happen in the kObjOnInitXProperties (5), not the kOnWidgetPrepEvent. Josh corrected me there. Also, you need a: Result := GetCustomObjectInfo(gPIOName, gPIOHandle, gPIORecordHandle, gWallHandle); statement before the CASE test so that you have those variable values to use both in all case events and before the case events. Understanding the difference between a widget and a parameter is a bit of arcane knowledge. Widgets are what is displayed in the OIP, and parameters hold object data. The vsoInsertAllParams statement makes a widget for every parameter and connects them. You soon come to think of parameters as OIP objects, but they are not. Yes you send data to the parameters to display in the OIP, but that display is done by the parameter widgets. It is also good to have a: ParamChangeFlag := vsoStateGetParamChng(PIOHan,ParamChangeWidget,ParamChangeIndex,OldParam); statement near the beginning of your ResetEvent routine so that you will know when a parameter has been changed, in case you need to process as a result of the change. In a Data Cable object when a Part parameter value changes all the other part parameters have to process the change entered in the Part parameter widget. BTW, you can see that you need the GetCustomObjectInfo() function to harvest the PIO handle to use in the vsoStateGetParamChng() function. Also missing is the kObjOnAddState (44) event and the GetStatChange Procedure which has the: MsgData := vsoStateAddCurrent(PIOHan, MsgData); procedure that will track state changes. I.E. has anything in the OIP changed. Then there is non parameter widget placement and handling, which is what a button is. Chandler has that in the case test, but understanding where that button is and how that placement effects parameter widgets, I don't think is documented anywhere in the VS docs. Are we having fun yet? :-) I think I can find an example that was sent to me by Andy Dunning when I first got started that was invaluable. But I'm still hoping to find a Josh Benghiat example that was a little more comprehensive, but I will need to check with them before sending anything out.
  14. That is going to be what you need, and that is what you are going to get. If you get it from me, it will be in Vectorscript. Also, I may forget about you, so send me a tickle in a week if no one comes through. The simple example will might declare over 100 constants, at least 15 global variables and then roughly 100-150 lines of code for the main and subroutines. The some of the subs and main deal with rare cases can be ignored and/or left out. :-)
  15. Well. To do what you want it is going to have to be. You might have some wiggle room grouping parameters, but not much. It depends on what you mean by "grouping". Buttons in the OIP require an event aware PIO. If you want to go there, you probably need to get an example of a simple, event aware PIO. There is a structure to it and some arcane (somebody has to tell you) object variables and constants you have to set up. If Kevin Linzey, @Josh Benghiat, @Andy Dunning, or @Pat Stanford have one, super. I'm trying to finish an update right now, but if no one chimes in after a while, I'll strip one of mine out and send it to you or post it. That's how I ushered into event aware PIOs, so I owe it to somebody. If your lucky Josh will send you a structure example. His code is beautiful. Event aware PIOs are really cool, but they are an order of magnitude more complex. Take a deep breath and think about if the functionality, or cosmetics you gain are worth the added complexity and work. I had to be dragged kicking and screaming into event awarenesses, but once there, even my simplest objects are event aware.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...