ccroft

I posted a script here http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=113373#Post113373 about half way down. (hope that crazy looking link actually works). It contains a simple function that loads an array with the handles of all selected objects using ForEach, and traverses the array with a While loop operating on the objects therein. The key to that whole exercise is understanding indexes as they apply to arrays and incrementing them accordingly. In fact, you could basically copy and paste that function and simply change the settings on ForEachObjectInLayer to process all objects on all layers. (After declaring a suitable array variable of course.) There's lots of good stuff about Doc List Handling and ForEach in there as well, and it's also a great example of how different strategies can be used to the same end. Too bad about Josh's suggestions. That looked promising.

No real answers I can give, but maybe some suggestions. Whatever you try I think you should do some testing with a snip of your script. It might be the only way to accurately answer some of your questions. Trim an object and use LNewObj to modify an object....maybe change it's color. You'll soon see what LNew is doing. I had to do this to use ClipSurface and understand what was the LastNewObj after the clip. It was a long time ago and I can't really remember what the details are, but it was counter-intuitive. Might have been that the LNew was the "clipper" rather than the result of the operation. I think I had to use PrevObj to get to the resultant clipped object. Miguel's idea sounds promising, but you still have to understand what is the LNew after your operations so that you assign the correct objects to the new class. For that matter, D's suggestion shouldn't be off the table. There's no reason I know that you can't assign the handles of the new objects to a global array as you process thru the trimming/duplicating. It'll be much the same as assigning to a class as you go. Just declare a procedure "loadArray" that stores the handle at the current spot in the array and increments the index after that. Call it anytime you can get a handle to an object that you might want to work on later. After all the clipping, duplicating and loading is done, step thru the array getting handles to newly created objects, test them further and do whatever to those objects. In both cases you'll need to know how LNew is working in your particular situation. Or...what about building an array of all the objects that are present before doing anything. Do your manipulations and then select everything that's not in the array? Now you could use ForEachObject with part of the criteria being Sel=True. BTW I'm not entirely sure what LObject gets. Seems it's affected by stacking order.

It does launch on my G4 laptop running 10.4.11. It seems to run *OK* but I only use the laptop in the field for viewing files and a little 2d drafting, and not very often. No freezes that I can remember, but I'm hardly using the program at all on this machine.

My script worked fine on my system. Like Ray, I would first suspect the spelling, or that the font that's written in the script doesn't exist. Anything between quotes in vScript is a literal, so spelling (including punctuation & spaces) is taken literally. I've been tripped up by the occasional space in front of a name a few times. Or...maybe it's a version thing. If you haven't already, I would suggest trying and buying the plug-in that Brudgers linked to. That's a monumental piece of work and unbelievably cheap if you ask me. If I cared at all about text I would buy it in a heart-beat. The chief functional difference between that script and the approach we've taken, is that Mr. Chandler has put in the effort to make a 'fool-proof' and fully developed tool. It reads all the fonts in use and displays them in a dialog for the choosing, instead of hard-coding them as we've done, thus by-passing literals and mucking about in the script editor altogether. I'm not sure off-hand where you can actually see an example of this type code, but I think you might be surprised at how much work that takes. As for a tutorial....I wish I knew. As I've said before, bone-headed determination and an interest in puzzles and language are invaluable. Just keep thinking of things that you wish you could do, try to imagine the steps that you might need to do them, apply the above mentioned attributes, and post questions here. Oh...and while you're here, do read Brudgers and Kool-Aid, but please try to see past their game. In amongst all the flame you can occasionally find some usable fuel to keep you going forward. Happy puzzling! PS to Ray if he makes it this far: I was remembering something I wrote a long time ago when everything seemed to start with WHILE etc DO etc nextHandle etc. If I ever need to edit symbol defs again I will try to think of FEOIList. Thanks for posting.

Hello Gentlemen, So I read the first few posts, had dinner and then thought I might play with criteria a little. Came back to find Ray's script. As usual he is more thorough than I. Figure I might as well post anyway,since for the learning two examples might be interesting. PROCEDURE change; PROCEDURE setFont(h:HANDLE); ????Begin ????????setTextFont(h,0,GetTextLength(h),GetFontID('Helvetica')); ????End; BEGIN ???ForEachObject(setFont,((FOT='Geneva') & INSYMBOL & INOBJECT)); END; RUN(change); I don't have a PIO with text to try it on, but it seems it should get in there. It takes care of symbol instances in the drawing, but I don't see why it would get symbol defs. Didn't test that. I did learn something about FEO: it will go into groups without any further criteria than FOT='font name', so it does viewports as well. It does need INSYMBOL to get into those. I guess it might be possible to declare setFont as a procedure for FEO, and as a function for FEOIL to cover everything. A question for Ray: Will your FEOIL get into symbol folders, or will the list only be the symbols on the top level? I seem to recall that some further acrobatics are needed if there are folders present, possibly involving FInFolder.

It appears that 20 is the limit. This was know to be the limit in older versions, and despite the change in documentation I'd say it still is. Tested on vWorks 09 in Mac OS 10.5.8

Hi 'Kool-Aid' ;-) Good to have you back. Implicit/explicit is a nice way to think of this. Thank-you. Fact is, if selection or visibility state, layer options and traversal options are the only criteria then FEOinLayer is simpler. No need for an explicit array at all. In the example I was referring to above (my version) the whole array exercise could be replaced with something along the lines of: ForEachObjectInLayer(Change_it,2,0,2); or possibly: ForEachObject(Change_It,SEL=True); If there's something more that needs to be done with the selection set (like collect, process and output data about the objects), then an explicit array can be useful.

There is no 'real' reason, but it's pretty much the same in all major graphic apps. Maybe you're right about Mac history since all these were developed on Mac. There's probably some 'Best Practices' paper from the late 80's floating around suggesting this architecture. On the bright side we do, however, get the tool behavior for 'free', since we don't have to write anything that looks for an interaction in the drawing window. Much like we get a dialog for next to nothing with .vso thru the OIP. Just don't forget that our beloved vScript is not a full-fledged programming language and has limitations (as well as pay-offs). You can probably do what you want with SDK.

http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=113373#Post113373 Here one can find an example of how to load the handles of a group of selected objects into an array (both dynamic or otherwise) and how to step thru the array while acting on each object as one might see fit. Document List Handling.... there are a number of lists in a document that exist or can be created. All the symbols in a folder, all the layers, all the classes and so forth are lists that already exist. All the objects that meet certain criteria comprise a list that a user can create. Break into one of these lists and the tools in 'List Handling' become your means of navigating therein.

Haven't been in here for a while so I'm a little late to the discussion. This limitation is part of the architecture of vScript, as stated above. There are 4 types of vScripts, 3 of which are decided when you create a Plug-in. I understand it as follows: .vst??????VectorScript Tool???????for working in the drawing window IE drawing things .vso?????VectorScript Object????for placing a parametric object .vsm????VectorScript Menu?????for everything else So since VST has been designed for working in the drawing window it requires you to click there. If you wish to do something that doesn't involve the drawing window then your script should be implemented as VSM. If your menus are getting too cluttered it's time for a visit to workspace editor, where you can create a new menu in the bar called for EG Preference Toggles. This will allow you to access these much more easily, without drilling down thru the built in preference dialog. As for context menu, you can add the new 'Toggle' menu and the enclosed scripts will cascade out from 'Preference Toggles'. This takes up one line in the context menu. Further, you can set it so that it only shows when you right-click in a blank area. And that also makes some sense, since you aren't trying to edit an object in the drawing window. The closest thing we have to a button activated VSM is the palette script. The palette can be put into a template so the scripts are available in every new drawing. They require 2 clicks to run, just like a command script implemented as a VST, but they're in the same place instead of one on the icon and one in the drawing window. Not saying this is the way it 'should be'. It's just the way it currently is.

Such a criteria certainly exists, but I'm too high on spiked Kool-Aid to remember... I think it's about time you dropped that insulting signature.

I would also like that. I have some classic dialogs with this, but I guess I won't for long. I can't remember... is it the next version that will no longer support them?

I believe it is, but don't know for sure. You might try: SetPref(94,NOT GetPref(94)); or something to that effect. SetPrefInt and GetPrefInt are 2 other possibilities.

A script such as Pat describes would be a great solution. In the meantime you could use 'Custom Selection' to create a selection script. You might use the criteria 'Symbol is'. Click the button to the far right, and pick your symbol. If you select 'Create Script' from the first window it'll save it in a script palette for future re-use. Double clicking that will select all the instances of the spec'd symbol. You'd need one for each. Any change you make in the data tab will affect all selected, provided you have the correct layer option settings. This is also a great way to start investigating vScript. Option double-click (Mac) the script in the palette to see the code. The reason I like it the way it is: I have a library of symbols that I use for estimating as I create the layout. I have a field that has a default starting point for time to manufacture each component, but very often there are factors which do not show in the graphic representation that require me to adjust that number on a case by case basis. I have other fields for material costing that sometimes require massaging in the same way. I don't want a library full of symbols that look the same and who's only difference is an entry in a data field. As in Pat's example, I'd soon have a ridiculously huge and practically unusable library. I'm not even sure how I'd create a naming scheme that would make sense. I agree that there should be a more elegant built-in solution for your situation while still retaining the current behavior. Under 'Tools' there are some menu commands for editing the fields in the definition records. There could be something in there like 'Update Instances' for eg.

Hi Orso, Thanks for pointing out my mistake. I forgot about that. If you get the record you can set document defaults with the record calls, but I wonder how you would set/change visibilites of record fields? I'm always interested in learning something new, so I went and searched the archives on list-serve for 'hide default preferences' and found some good stuff. Heiner posted a template there for an event enabled PIO that bypasses that event. You can just hide the pref Pane or Object Creation pane or whatever it's called just as Andrew describes. (I rarely see it, since I'm usually working in a template that has already had my PIO's inserted and therefore already has the document record present.) Thank-you Gentlemen!

Duckz, If you haven't already done so, a reading of Charles Chandlers excellent articles on events might be useful:http://www.vectorlab.info/index.php?title=Events In particular 'Preferences Button' and 'Object Info Palette Behaviors'. Also, I may be mistaken but isn't objHD and GetOject(objName) getting you the same handle after calling GetCustomObjectInf? Both would be the handle to the currently executing object. If you're trying to determine if this is the first use of the object in the drawing IsNewCustomObject will get the job done. I'm hardly an expert, but it seems that the behavior you want might not be possible with vScript. An alternate approach might be to use a custom dialog for the Preference Event on first insertion, though that might be more work than it's worth.

Well, for me the point is that I don't always want every instance of a symbol to carry exactly the same info. I often change field values after insertion for a particular instance, and I don't want that changing if I change the default (or import an edited version of that symbol from my library). All records in vWorks behave in the same way. The fields which show in the Obj Info Palette for window PIO are record fields. The attachable record you're creating works just like these. You have a default which the object takes on insertion. This value is editable on a case by case basis, but un-affected by subsequent changes to the default. You wouldn't want it any other way. So if you want to change one of the fields in all the instances of an inserted PIO you create a custom selection and change them all at once. You can do exactly the same with your symbols. All of us can identify behaviors in vWorks that we think should be different, but not all of us use this program in the same way. The behavior you wish for would be a nightmare for me. To make both of us happy there needs to be a second kind of record that behaves like a symbol: change the definition and all instances take the change. This record would not be editable on an instance by instance basis in the same way a symbol isn't. Might be worth posting to the wish list.

In a case statement you can specify a range of selectors, so maybe you can use something like 3..21: SetItemEnable(23,False); 23: SetItemEnable(23,True);

Way off topic here, but I'm curious: Is there something wrong with a 2% world-wide market share? It's a big world and that's a lot of business. I wish my company had a 2% world-wide share. err...wait a minute...maybe I don't..

This is totally obvious, but just to clarify: if you set up multiple database rows you can have as much space as you want *between* them to manually enter stuff. I'm pretty sure Pat knows what MEP is (I don't) so he knows you want to put that stuff in the same row as the database. And while I'm here I'd point out that you can manually enter formulae to this multiple database sheet that will operate on the totals in the database columns. So, for eg, you can have a database row reporting area of one type or class of object, another row reporting perimeters of other objects, total them all up with a worksheet formula and then maybe multiply them by a cost or something equally useful. just sayin'...

Version 8 had unlocked Plug-in Objects. Together with the tools and menus these were indeed invaluable for learning vScript. Maybe they locked them down to prevent people from easily making a different stair tool (for eg) that could be used in Fundamentals, and selling it for less than the cost of the up-grade to Architect, or giving it away for free. I think Miguel is correct that the encryption started with the introduction of different tiers, which is also right around the time Nemetscheck bought Diehl Graphsoft. This is pretty much the only way that I can see that open plug-ins could possibly hurt Nemetscheck, but I doubt there'd be much damage. ODBC is also wanted by folks who like the presentation capabilities of Excel. (I'd like to make it clear that I'm not one of them). Writing from an outside source to attached records is totally do-able with vScript, but you have to export a delimited text file from the source every time you need to update something. Same with going the other direction. It seems that two-way worksheets satisfied some of the clamor for ODBC. It'll happen one day....mac included. The plant tool might be a case in point. There's been a few people who'd like to customize that database, and one at least that spent what appears to be a large amount of time trying to do with script something that'd be easily done with ODBC.

Quick question if you please (too tired to research) What is criteria PON?

Hi Ivan, This may work for you: Procedure SelectEveryOther; VAR h: HANDLE; BEGIN h:=FSActLayer; h:=NextSObj(h); WHILE h<> NIL DO Begin SetDSelect(h); h:=NextSObj(h); h:=NextSObj(h); End; END; RUN (SelectEveryOther);

Happy to hear it worked out for you Ivan. Thanks for posting back. (finally.... beat Stanford to the punch...must've been climbing a mountain or something :-)

Sooo.....later that day: Got to a machine w/ vWorks installed and played with the script. The above seems to work in terms of skipping every other poly. But it fails due to the first FOR loop in the main block. As written the script counts the number of selected objects and executes the loop that many times. But with the above changes we're skipping objects, so the loop keeps going after the last selected poly has been processed. It gets NIL handles to non-existent objects and spews out faulty data leading to various errors. The solution seems to be a WHILE loop instead. You can skip the counting part entirely. The loop keeps executing until it gets a NIL handle....IE until it processes the last selected object. Here's the re-written main block: BEGIN h:=FSActLayer; GetPt(x,y); ii:=1; FindP(x,y,h,ii,x,y); WHILE h<> NIL DO BEGIN????????{was the FOR loop} i:=GetVertNum(h); ALLOCATE Myp[1..i+1]; ALLOCATE Myp2[1..i+1]; IF ii=1 THEN BEGIN FOR j:=1 TO i DO BEGIN GetPolylineVertex(h,j,Myp[j].x,Myp[j].y,Myp[j].z,d); END; END; IF ii=i THEN BEGIN FOR j:=1 TO i DO BEGIN GetPolylineVertex(h,i+1-j,Myp[j].x,Myp[j].y,Myp[j].z,d); END; END; h1:=NextSObj(h); h1:=NextSObj(h1); IF h1<>NIL THEN BEGIN i:=i+1; FindP(Myp[i-1].x,Myp[i-1].y,h1,ii,Myp.x,Myp.y); Myp.z:=0; END; Del_Points (Myp,i,.2,.2,MyP2,i2); DrawPol(Myp2,i2); h:=h1; END; layer ('new Lines'); END; RUN (TheProcedure); Hope that works for you.