ccroft

I'm still back on 2009 and I think it's mainly for that reason. I'll have to update all my dialogs to Modern Dialog if I ever want to update vWorks. Anyway, I think you'll want GetItemText and SetItemText. Sorry 'bout that.

Have a look at SetField and GetField. CreateEditText is used to create the field and set the default text that shows in the dialog box... if you want to.

Option Shift 8, Option J, Option K Open Keyboard viewer and you can see a bunch of these things.

Hi Jeff, I actually haven't written anything meaningful in quite some time, and I'd like to thank you for posting and tweaking my interest again, and trying to see what you were up to. If I may I'd make a couple more comments. I think you'll find that you're doing a few things in your code that don't need to be done. You don't need to have a separate "fill the first location" line. My example handles that in the first line of the loop. IE the first time we look at the array we can assume that it's blank. Actually, some might say that we need some error checking to make sure, but I've never done that and in some 8 years of using a tool daily that doesn't check I haven't had a failure. Also, the section at your comment {IF NAMES DONT MATCH ADD 1 to arraycnt to look at next element} isn't needed if you increment the index after the logic is finished evaluating things. If neither condition is met, then the index increments to look at the next location in the array. So let's say we're on the fifth instrument and it hasn't yet been entered into the array. The logic looks at each value in the array consecutively and doesn't find a match. It then encounters a blank location. That means that we've looked at every instrument in the array, so we add the value there. You can use the way an array is filled to your advantage. The fact that I'm using 'done' to control the loop is essentially the same as what you're doing with: arrayCnt := kmaxArray; I've just rearranged things a bit. On the subject of error checking: you may want to add a safety valve in case something funky starts happening. Something like: While (not done) | (index < arrayCnt) Do.... If arrayCnt = kMaxArray then done := true; AlertMessage('funkiness encountered)'; I have something like that in a script, but it's never gotten funky. :-(

Here's how I've looked at values and added to array, or counted them if they were already in the array. It's the same approach if the values are in another array, or the values are derived from a PIO. In my EG I already have two procedures: sameValue and newValue. You already know what each does. You could write out the procedures directly in the loop if it made more sense to you. In any case, the last thing that happens in each is that a boolean becomes true. If conditions are met and either procedure runs then 'done' becomes true, we exit the loop and move on to the next value to either be counted or added to the array. If neither condition is met then done stays false and we move to the next location in the array until one of the procedures runs, and then we're done with that value. pioName:= aValueFromArrayOrObject done := false; index:= 1 While (not done) Do Begin If array[index] = 0 then newValue else IF array[index] = pioName then sameValue; index := index+1; End; This could be a procedure in a ForEach statement. ForEach looks at every object in the drawing that matches your criteria, gets it's name and then runs above to either load the array or increment the counter in the array accordingly. With this approach you build one properly summarized array from the get go. This *might* be a more efficient way, but if what you've got is working for you well... why rock the boat?

Are you doing something else with xArray besides summarizing it with another array? IE does xArray exist only to be summarized? If so, I'd do the counting while loading xArray. The loading procedure looks at an object. If it's not been seen before it adds it to the array. If the name is on the array it increments the count and moves on to next object. You'd need a two dimensional array. Column one is intelCount and two is intelData. Of course, you may have needs that disqualify this approach, but if not it seems a lot simpler to me. The entire loading and counting is done within one loop, there's one less array to manage, and one less array to traverse. My apologies if I'm stating the obvious.

Even better! I didn't think of doing it all with criteria.

I'd try one of the ForEach calls with something very similar to the example in function reference under GetRField that said "IF GetRField = FieldValueMeLookFor THEN HandleToObjectMeLookFor := H". If you used ForEachObject you could restrict the number of objects queried with some sort of Criteria filter. Possibly by PIO name, since if you know the value you're looking for you probably also know the name of the object it's attached to. The 'record' parameter in GetRField(h,record,field) is the PIO's name, and field name is... well usually it's the name of the field you see in OIP. I haven't been around much lately so there's a pretty good chance I've forgotten something, but there's plenty of other posters who'll know this routine. Hopefully they're enjoying a lovely Labour Day weekend. Just thought I'd give you something to start with until one of them comes along.

If the above is true then it must have something to do with the different behaviours of VSM and VSO. In past posts you were working with nested pio's.... parent PIO placing other PIO's. Is this code part of that project? All of my run-ins with out of memory problems have involved loops running out of control. With nested VSO's it is possible to construct event loops, where the parent changes the child, and the child changing causes the parent to change, and on and on until all memory is eaten up. Above is total guesswork and conjecture, but what I'm trying to suggest is that instead of thinking along the lines of forcing more memory or tweaking bits of code, the problem may be more in the implementation of the code: the differences between VSM and VSO. The principal difference as I understand it is the constant event monitoring of VSO. On the other hand, if Josh's *very* generous offering solves the problem...

If you select a worksheet-on-drawing, and convert it to group it becomes a dumb graphic/text object...frozen in time. You could copy/paste that into another file, or reference the layer it's on into another file. Note that the dumb schedule will not update to reflect changes in the target file, and the worksheet no longer shows as 'Worksheet on Drawing' in resource browser in target file. So if you make changes to target file, you will have to delete the dumb worksheet, go back into resource browser and select 'Worksheet on Drawing' and convert the worksheet-on-drawing to group all over again. If you have referenced the worksheet into 'Schedules File' those changes will be updated. So it's hardly automatic and introduces lots of opportunity for error when managing changes, but it does work in VW '09. There might be a better way.

We don't own CNC, but I output dxf/dwg for stone counter-tops and also for some of the more complicated millwork parts when it makes sense. Haven't had any trouble at all. Mostly curved stuff but only since upgrading to 2009. Sorry to hear about Tom's trouble. So far it's been very accurate for us. Of course, we're a millwork shop so it's not like we're building space shuttles or anything, but I've scrutinized the work very closely in case we need something really critical in the future.

Been using this mouse for about 2 weeks. I didn't instal any 3rd party software. Pan and zoom work really well for me, so something funny's going on here. Maybe you should dump the MagicPrefs app and try again. Or delve more deeply into how that app works.

I think you'll have to do it 'manually'. I've never needed to do exactly this, but I would try stepping thru the array with a while loop with something along these lines: index:=1; stringMatch;=False; While NOT stringMatch Do ????IF array[index] = theString THEN StringMatch := TRUE ????ELSE index:= index+1; Message(index); {if you'd like to check} The loop will terminate when it finds a match, and index should be what you're looking for. (or it might be index-1...) If there isn't a match you'll have some trouble, so you better have a limiter in there like: While (index < arrayLimit) & (NOT stringMatch) DO ??etc. Since your using dynArray you've already calculated the array size, so you could probably just use that variable in place of arrayLimit.

No Ray....YOU da' man. But you need to re-read my post. I never for a minute thought you would suggest an array. From our history I figured you'd know that would be my solution, since it seems to be my go to move when there's any kind of handle trouble. I like your 'look-ahead'. Haven't seen the Geek here for a while. Good to seeya!

Seems like that should work. You must be getting kicked out of the loop due to a nil handle. Could it be that once the PIO is moved out of the wall NextObj can't figure out what's next in the list? I think Ray knows what I'm about to suggest... Build a quickie array of all objects in wall = 86, and step thru that. (or maybe something else is happening that I can't see)

Kool gave you the answer, Brudgy trotted out one of his favorite complaints and I foolishly stepped into the fray. Sorry if it sounded argumentative or rude. I'm not arguing with anybody. A vectorscript tool (.vst) won't do anything until you click in the drawing window. This is built into the way Vectorworks plug-ins operate. Make it a menu command (.vsm) and assign a keyboard short-cut. Or leave it as palette script and double click that.

This again... Here's the deal. If you want tool behaviors beyond the capabilities of v-script you just have to learn to use the SDK. Vectorscript is not a full-fledged programming language. It has limitations, but the payoff is that you get a lot of behaviors with no programming whatsoever. And you don't have to work with that god-awful acad script either. If you want different behaviors then start learning C++ or whatever they're using these days. Nobody's defending anything. Just trying to explain how it is to somebody who might think they can do something they can't. Kool's advice is spot-on and no amount of belly-aching will change that. Well, not anytime soon at least.

I would copy/paste or duplicate and move (via OIP) the tiles to a new design layer for detailing. (Actually I'd be more likely to use sheet-layer viewports and detail thru annotations but that's not working out for you) I would restrict the database reporting to the main layout layer or layers. Or change the class of the detailed copy if the database criteria was by class. Or delete the record if the criteria was by 'record attached'. One way or another I'd find a way to structure the drawing and the database criteria so that it could all be in one file. Not saying that wanting to have more drawings open isn't a reasonable wish. It's just that I'd rather manage one file per job than 50 or 60. Not to mention being able to arrow thru the layer list hitting a couple key commands as you go. That happens to be something I have some experience with. It took us about 7 years to upgrade to an Industry version and batch print was one of the primary reasons. I believe you'd be well served to be working towards a unified file and an upgrade. Hopefully you won't have to wait as long as I did for batch print.

I've never tried referencing a Worksheet, but I import them thru the Resource Browser all the time. The imported worksheet sees the symbols referenced thru DVLP in the same file.

I just spent a little time fooling with your script and couldn't access 'Convert To Group' either. I could get the script to place a PIO, group it using ('Group Chunk',1) and count the one PIO inside it.... The appendix says that the selector is 'Convert to Group Chunk' but that didn't seem to work with any index. Thing is, it's not part of a chunk. If it's part of any chunk it would be the Convert chunk, but all the other Convert commands are not part of any chunk and would be called like ('Convert to Lines',0) And it didn't work as simply ('Convert to Group',0) either. I didn't work with it that long, so maybe I'm missing something but it does look a little bug-like. This kinda illustrates why DMTBN isn't recommended. Custom workspaces and changes to workspaces made in product updates can break the script. What I keep wondering is why you don't make this simple PIO a procedure in the parent that takes the needed parameters, rather than taking on the whole child/parent thing. Of course, I've no idea where you're headed with this. Guess I'm not much of a family guy.

Hi Justin, Are you saying that you can't get access to the group? Wouldn't surprise me if this was true. Fairly sure hobject is nil after you call HUngroup(hobject) After CreateObject, hobject is handle to placed PIO, no?

Not positive on this, but you might try another set of enclosing parenthesis for everything after the equal sign. If I have to edit the criteria directly, sometimes I'll set up a dummy database row and use the 'set criteria' button to see what the structure should look like.

Try putting this as the last line of the function declaration, before 'END' hDuplicate3D := CopyHandle; Not obvious at first, but makes sense if you think about it. You want the compiler to see hDuplicate3D as the return value of your function, which in this case is copyhandle. A function is kinda like a self-assigning variable. It is because of this characteristic that you can use a function directly without assigning it's return value to another variable, should you so desire.

But that right there is cut-list optimization! If you work from longest to shortest, and use the shortest piece in the shop that'll do the job you get the best possible yield. What I posted is just the algorithm (if I may be so bold as to call it that) for the script. The scrap-bin is the array that stores the cut-off lengths. The key is keeping it properly sorted and this is true for both the software and the shop. In the real world the guy looks at what's left over and either throws it in the trash, or puts it aside to use for one of the shorter lengths in the list. If he's working with 8' stock and the list asks for 4 pieces 59", and 4 pieces 36" he knows he can get it all from 4 lengths. If he doesn't know what he's doing he might cut all the 3' pieces first and end up using 6 lengths and leaving a lot of fairly useless clutter. Of course 1x3 is so cheap compared to labour that it doesn't matter much how it gets done, so you're right about the trade-off between labor and yield. With some other materials and a longer list you do it right or lose the shop. Boxjoint: That right there is why I'm still working in 2d. One day we'll buy Interiorcad and I'll let my quirky system of worksheets and scripts fade to obscurity on some obsolete storage disc. I'll be sad to see it go though. It has served us well.

Length cutting optimization in a nut-shell: - get a list from somewhere - sort it from longest to shortest - get the first part length - look in the scrap bin for the shortest piece that'll do the job - cut the piece of scrap if you find one, else cut a piece of stock - if a length of stock is used then up the tally of lengths required - put the cut-off in the scrap bin - get the next length needed from the cut-list - repeat the above 5 steps until list is finished It's really just a game of simple math, shuffling numbers and sorting. It took me who knows how long and about 300 lines of vectorscript, not including the data input part. The list comes from a rather huge dialog in one tool, and a chunk of script in another which runs thru objects in the drawing to build the list. I learned a lot. One thing I learned is just how valuable a good tradesperson is. (Just thought I'd share my experience with this whole thing)