ccroft

I'd like some Kool-a ... ah...no not really. As far as I know there's no simple way to get the extrude value. X and Y values (height and width) are quite easy but are view dependent, so you need some way to transpose the X value of a horizontal to length. Enter vectorscript and classing of your pieces. You could attach a record to each and manually fill in a length field. Not that much work really. But anybody qualified to build these should be able to do a take-off and part list in about as much time as it'd take you to fill in the records. Good reliable part listing software is expensive.

I think you want: GetCustomObjectInfo(name,handle,record,wall); GetSymRot(handle); Despite 'Sym' in the call it's also supposed to work in PIO.

This may be true. In my world the end-user and scripter are one in the same, with the exception of just one other user in the office. I'd write a script that runs through each object that has the first record attached. It would read the data in the finish key field and replace it with the recipe. So you'd see 1,2,3 etc in the worksheet until you ran the script. (I might lose the 'F' in the finish key and try a case statement to get rid of all the iffing and elsing.) In the real world you might be able to hire someone to write this, but then you'd probably need to hire him again every time you added a new finish. The end-user/scripter would just mod the script. The other downside would be remembering to run it every time you made a pertinent change in the drawing. Myself, I'd have no problem running the script right before any output.

I'm with you on this. Like the snap loupe or whatever it's rightly called. Z key Great request!

Hey D, Thanks for posting. I never really thought about it much, but yeah...it makes sense. I was using DVLP for zoomed in detail views sometimes, but those should really be on a sheet layer as it's a presentation thing. Design layers for objects you want in the drawing and reported, sheet layers for different ways of looking at the objects.

So in an effort to learn something I went back to Language Guide and found: "It is highly recommended that you use static arrays wherever possible for the best possible script performance. If dynamic arrays are required in your scripts, avoid making frequent calls to ALLOCATE to reserve storage. Use ALLOCATE only when absolutely necessary to change reserved storage during script execution, and avoid any use of ALLOCATE inside of a loop or repetition statement (see Repetition Statements for details on these statement types)." It doesn't say it'll crash VW though. Of course...it's only a guide.

According to vScript Language guide you 'should' be able to re-allocate: "Once all the objects have been processed, the array can be redimensioned to allocate more or less space as needed. In the example, additional storage space is reserved with another call to ALLOCATE, ..... Note that the existing data values stored in the array are preserved when the array is re-dimensioned. If an array is redimensioned to a larger size during execution of the script, VectorScript will preserve all the values currently in the array. VectorScript will also attempt to preserve as many data values as possible if an array is redimensioned to a smaller size. In the case of dimensioning to a smaller size, any values contained in locations beyond the newly defined boundaries of the array will be lost." But then, things don't always work like they're supposed to. I'm curious as to why you'd want to repeatedly call allocate in a loop. Maybe it's because I'm more of a static guy, but my first inclination is to run a count as a separate routine and allocate once. Strikes me a bit odd, so it seems like an opportunity to learn something.

Better make that a double.

Is this still happening in 2010? I was really hoping they'd give us a more elegant solution one day. It'd be so much better if they'd just give us a check-box to "look in DLVP". It'd be off in all my templates. It's a pain to have to re-edit your worksheets if you decide to change the drawing structure.

Hi Ray, Thanks for sharing your considerable knowledge of Last and LastNew objects. LObject in particulas has always been a bit of a mystery whenever I've tried it. Very tricky indeed! You must've spent a bit of time testing those.

Sam, Have you looked into SetPrefInt and SetPrefLongInt? You'll find the index/selector numbers in the appendix. There are selectors for Fill Style and Type. Maybe something like SetPrefLongInt(528,0). I think the second value would be the number corresponding to the place in the drop-down of the style, so maybe by class is zero, or -1 or.... It *seems* this should set the default value in attributes. edit: Or maybe use SetPref(8,False) to make sure that fill behind text is off.

ahhh....i see. You're running setObj in another script trying to control the wall break? Is it a VSO?

Hey Kool As you may know I don't use wall objects much, but I wonder: why can't you write this info directly to the parameter record of the wall in question if it's a value in the OIP?

I agreegiously agree!

Great! Thanks for posting back.

Principle reasons for MacPro are expandability and serviceability. You can swap a hard-drive in about a minute. Same for the other components. In a "mission-critical" machine this can be important. It's all about that big easy-open box. Gigs of Ram go for about $30 each. 1TB drive is around $100 and you can put 4 in if you're feeling cramped. Multiple monitors of your choice...and so on. And it'll get an upgrade soon enough. The Imac is a great machine, but for some there are good reasons to spend another $500. Just sayin'...

Well...yeah, but...In my world that box is more likely a drawer in a cabinet. It gets it's height, width and depth when it's built. If I take it out of the cabinet and lay it on it's side nobody thinks it's width has changed. Same for doors. A 7ft high door is still 7ft high no matter how you stack it. It's like that. You give the rectangle it's height when you build it and it retains that no matter how you rotate it or the plan. This thread is starting to resemble those ones about None Class that turn into lengthy investigations of what None means. Or what a standard is.... ;-) Anyway, glad to see you've found the behavior you need. That's what really matters.

What you have there is a script that calls the rectangle tool, allowing you to draw one with a set fill color already applied. For what you want to do you need something more like: Procedure Filler; FUNCTION fillObj(h:HANDLE) :BOOLEAN; Begin ????SetFPat(h,1); ????SetFillBack(h,50000,50000,50000); End; BEGIN ????ForEachObjectInLayer(FillObj,2,0,4); END; RUN(Filler); This will fill selected objects on editable layers with a med/light grey. You'll find that this grey is not on the color palette cause I just put in randomly selected RGB values. Should get you started.

But it's not a bug. The tool is behaving as designed. I don't think it's a waste of time for people to discuss how the tools work and how they might be improved. Something for the wish-list perhaps.

Miguel, Most of my scripting was in 8 and I'm not sure if we had the debugger back then or not, but in any case I never really learned how to use it very well. My need for new tools since then has been pretty sporadic, and every time I use it I have to re-learn what the controls actually do. It is a powerful tool and has solved some thorny issues. Call me old-fashioned (or a simpleton), but sometimes message seems easier. In one script a counter separate from the index value showed an error in loop structure. You can have a situation where a loop executes too many times and where the index isn't equal to loop iteration. I think it was a troublesome sort routine. Maybe that's more of a loop debug than index debug. So Peter, did you go with selecting all and deselecting everything that's in "OldObjBin"?

Just for the record, it was Ride who suggested converting to polygon, and it's a sensible work-around for some users. That's what the older versions did with a rectangle rotated something other than 90 or 180. My suggestion is to improve the tool. In the mean time, if I need to transpose the height and width of a rectangle I avoid the short-cut of rotating and change height and width in OIP. Then rectangles remain rectangles, and height and width remain aligned with the screen. For me it's not something that happens very often. DWorks said: "The only thing they can do to fix this is not displaying the width and height but displaying other things: *The base point *The rotation angle *The first side *The second side" That's what the rotated rectangle PIO that I used in vWorks 8 and 11 did. It was a line PIO and it got the job done, but the new rotated rect is easier for me. The main point of the new behavior is that you can have a rectangle on an angle relative to the screen and still edit it's height and width in OIP. A quick glance at the widget in OIP tells what's what. You can also drag a control point and it'll stretch in the same way an un-rotated rectangle does. You lose both if it's a polygon. If all your rects are aligned with the screen you might as well abandon rectangle for poly. You can always rotate plan when they're not.

Run a test script that counts objects and messages out the result. Construct it using the same bit of script that's loading your array. Assuming you're using ForEachInLayer, do you have it set to go inside groups, and containers? Do you really need to do this? A group will count as one object, but if can be made up of many for EG. A tip for trouble shooting arrays: put a counter in there to count how many times the loop that loads the array executes and message that out after the end of the loop sequence. Another thought. Did you initialize the index variable? If the array doesn't start loading at 1 you'll have big trouble.

Before this behavior was introduced the wish list was full of people asking for the current behavior, but perhaps with a different implementation. What people wanted was for rectangles to remain rectangles when they were rotated something other than 90 or 180?. A reasonable request for those of us who use rectangles for layouts on angles in 2D. Previous to this if you rotated a rectangle 45? it became a polygon and lost the ability to edit height and width in OIP. Many of us used a custom PIO to get around this limitation. If memory serves, that's why it happened. Undoubtedly the new tool has it's problems and needs some work. Maybe it should know when it's been rotated an increment of 90? and display itself in the old style. Maybe not. Not sure what the implications of this might be for 3D work. Have to say that for me at least the new tool is far better than old one or the PIO I used for boxes on angles.

You know what though. If we keep this thread alive somebody will read it who has a much better idea....

I think Ray says in that post it's 32K, and I tend to believe what he says. Might've changed in the new 64 bit world though. I'm no computer scientist (obvious...I hope), but I think when you declare a static array you are reserving...whaddaya call em....registers? in memory. So what does 32K registers in a one dimensional array add up to? 32K of Ram? Any scientists out there? I don't *think* there's much of a downside to setting up an oversize static array. I've done it a lot with no apparent harm. I'll set up a 1,000 place array for what will likely be 100 to 200 objects at most. Actually it was a programmer friend who told me to just go ahead and do it and not worry about it. However, as you can read in that thread there's very little overhead to declaring a dynamic array. It just says there will be an array and we're going to figure out later how many places are needed. Counting objects with ForEach is the way to go. I think there's probably a few ways that you could go about acting on objects not in the array, but doing what you said was the first thing that came to mind. If all your object processing is selection based this seems easiest. Another possible might be to declare a second array NewObjBin. You'd get a handle to each object, test OldObjBin to see it it's there and if not put it in NewObjBin. Sounds like a lot of processing but this stuff is very fast. I have one long and tedious script that has three 2D arrays that get traversed and sorted a few times for each object. I've tested it on maybe 800 objects and there is no lag that I can detect. If you find a need to speed this kind of thing up you can start doing things like stop traversing the array when you encounter a blank. Then you can take it a step further and if you find a handle that is in OldObjectBin you can delete it and sort the array so the blank goes to the bottom. When you get towards the end of all this comparing you're only traversing a few registers in the array instead of all of them. I must me crazy cause I kinda enjoy doing this sort of thing. I may just create a drawing with 31,999 objects and count 'em just to see if it takes any time. That is... if I get any time for such foolishness.