PeterT

It would be good if the "Remove Current From Favorites" command in the Resource Browser had a confirmation dialog like the "Remove All Favorites" does. It is too easy to accidentaly remove a favorite file from the list when you are trying to open it. You should never have the ability to delete a file from the list without the opportunity to cancel the removal.

Alexandre, What Am I missing here? The following script sets th font to Geneva, 18 pt, bold(on my local machine), and selects the text tool: code: Procedure CustTool; VAR Name:STRING; Result:BOOLEAN; BEGIN TextFont(3); TextSize(18); TextFace([bold]); TextSpace(2); TextJust(1); SetTool(-200) END; Run(CustTool); [/code] As a stand alone script it seems to work as expected. Are you saying that if used as a sub-routine in a larger script it would fail?

Thanks, Ramond, I will have a look at your code more closely, but on first glance it appears that your code will also find objects which are completely enclosed inside of another object's bounding box. I wish to exclude these objects, and only find the objects which are actually touching or crossing the bounding box. For example, if I were to draw a large rectangle across the middle of a busy drawing, I would like to get handles to all the objects touching the rectangle, but not to any objects completely inside or completely outside the rectangle. I think the first line of your code would get the objects inside the rectangle even if not touching it. I have never used PtInRect before so I will also look at that. And I just discovered the problem with dimensions in my script. I had previously comment delimited the Type 63 line in my code for testing, and forgot to remove the delimiters. Now the dimensions are being recognized just fine. I am just a beginner at this, and sometimes the simple things get me. Regards, Peter

Is there a simple way to tell in a VectorScript if the bounding boxes of two objects are intersecting? The way that I have been doing it assuming two rectangles with the coordinates b1x,b1y,b2x,b2y and r1x,r1y,r2x,r2y is awfully wordy: code: IF ((((b1X<=r2X) AND (b2X>r2X)) AND ((b1Y<=r1Y) AND (b2Y>=r2Y))) OR (((b1X<r1X) AND (b2X>=r1X)) AND ((b1Y<=r1Y) AND (b2Y>=r2Y))) OR (((b1Y>r1Y) AND (b2Y<=r1Y)) AND ((b1X>=r1X) AND (b2X<=r2X))) OR (((b1Y>=r2Y) AND (b2Y<r2Y)) AND ((b1X>=r1X) AND (b2X<=r2X)))) THEN (--BBoxes are intersecting--)[/code] 1. Is there an easier way than this? 2. This test does not seem to work if the objects being tested are "dimension" objects. Do dimensions have bounding boxes at all? If I group a dimension, then I seem to get its bounding box, but then it is not a dimension anymore, it is a group. Thanks for any input, Peter

Hi Tom, Thanks for the response. Maybe I am worse at explianing my understanding of VectorScript than the understanding itself. I have a working script that is very slow to execute. So now I am trying to look at the individual portions of the much longer script, and see if I can streamline anything. The portion I am working on now is meant to select objects in the drawing that meet certain criteria. The loop I have been using to this point is as follows: layerhndl:=FLayer; WHILE layerhndl<>NIL DO BEGIN {loops through layers} hndl:=FInLayer(layerhndl); WHILE hndl<>NIL DO BEGIN {loops through objects} IF {-certain criteria is met-} THEN SetSelect(hndl); hndl:=NextObj(hndl); END; layerhndl:=NextLayer(layerhndl); END; The problem with this loop is that it processes every object on every layer. In my file I have 16 layers, but only 6 of them are visible when I execute the script. Furthermore, all the objects I care to select are on only two of the visible layers. My first thought was by using "ForEachObjectInLayer" maybe I could filter for only visible objects thus eliminating the processing of all the objects on the 10 invisible layers. So I was using the "ForEachObjectInLayer" to process the objects on each visible layer, and a loop to process through the layers: FUNCTION SelectIt(hndl:HANDLE):BOOLEAN; BEGIN IF {certain criteria is met} THEN SetSelect(hndl); END; {------------------------------} layerhndl:=FLayer; WHILE layerhndl<>NIL DO BEGIN {loops through layers} ForEachObjectInLayer(SelectIt,1,0,2); layerhndl:=NextLayer(layerhndl); END; {------------------------------} Next, I figured if I used "ForEachObjectInList" instead, I could skip the layer loop, and just process through visible objects regardless of the layer, so I tried this: FUNCTION SelectIt(hndl:HANDLE):BOOLEAN; BEGIN IF {certain criteria is met} THEN SetSelect(hndl); END; {------------------------------} Obj1:= FObject; ForEachObjectInList(SelectIt,1,0,Obj1); {------------------------------} The problem with this, I realized, is the first object in the document is on one of the invisible layers, so by filtering for visible objects, maybe it was never finding the first object. (In this version of the script, no objects were ever being selected.) By setting Obj1:=LNewObj the script now selects the objects again, but I am not confident that it isn't just luck. LNewObj would have been the last object created in the script, but I am not sure that would always be in the stacking order below the two layers I care about selecting objects on. I really only want to process through the objects on two layers, and I am not thinking I can do that with "ForEachObjectInList". I would need to define the list of objects on just those two layers. These two layers happen to be the two top-most visible layers. I tried starting with the first object on the lower stacked of these two layers by getting the layer's name: hBasePln:=GetLayerByName('BASE PLAN'); FirstObject:=FInLayer(hBasePln); ForEachObjectInList(SelectIt,1,0,FirstObject); I was thinking maybe this would process through the "BASE PLAN" layer and then proceed to the top-most layer (last layer), and process through that. Of course, it did not do that, I think because by defining the list parameter as the first object on a specific layer, it processed the objects on that layer only. One of the concepts I am trying to understand is, if I define an object in the middle of a list as the "list" parameter, will "ForEachObjectInList" process only the objects in that list that are higher in the list stacking order, or will it still process the entire list, or will it process nothing because it was not the first object in the list? This is where I am now. Maybe I should just get both layers by their names and process through them specifically, but I was trying to keep the script more flexible by not naming them specifically. Any further comments welcome. Thank You, Peter

I am using the ForEachObjectInList procedure in a script, and I do not fully understand how the objects in the list are traversed. In my script I gave a handle to FObject as the "List" parameter, and for the "Object Options", I was filtering for Visible Objects only. This script failed, so I got to thinking that perhaps the first object in the document was not on a visible layer. Would that cause the script to fail? Next, I tried a handle to LObject as the "List" parameter, since I am pretty sure the last object is on the active layer, but the script also failed. I got the script to run by giving a handle to LNewObj which I know is on the active layer since it was just created in the script. Through this trial and error, I seem to have found more questions than answers. The documentation says the "List" parameter is a handle to the first object in the list. Does this mean, literally, the first object in the list (FObject if the list is of all objects)? Or does this mean that whatever object handle you give as the "List" parameter becomes the starting point of the traversal through the list? When I gave the handle to LNewObj and the script worked, why? LNewObj is certainly not the first object in the list, wouldn't it be the last object in the list? I am a bit of a beginner with document list traversal. Can anyone help me to understand it better? Thanks, Peter

The trim routine is just a part of a much larger script which relocates the trimmed objects, and draws additional objects, and is all controled by a modern dialog. I have refined my script to get away from the edit group stuff by using ForEachObjectInLayer instead, and filtering for only selected objects. I did encounter the infinite loop problem you are talking about myself, but somehow resolved it. I am using the ForEachObjectInLayer procedure with a trim function being called. In the trim function, a cutting line is drawn, used to trim an object into two objects, then deleted. My script seems to work now, but in a file with a lot of objects, it seems to take a long time to execute. When an object is cut into two, what happens in the document list? Does one of the two pieces retain its place in the list and the other become the newest member of the list? If that is the case, then would a ForEachObject routine first go through the list of objects originally in the file, then continue through all the newly created objects (ie the second halves of all the trimmed objects)? If this is true, then none of these new objects need trimming and somehow I need to exit the routine after it is done trimming the original objects before it gets to the new ones. How would I get the trim function to return "True" to stop the traversal? This would save about 50% ot the trim calls I think. Peter

The trim routine is just a part of a much larger script which relocates the trimmed objects, and draws additional objects, and is all controled by a modern dialog. I have refined my script to get away from the edit group stuff by using ForEachObjectInLayer instead, and filtering for only selected objects. I did encounter the infinite loop problem you are talking about myself, but somehow resolved it. I am using the ForEachObjectInLayer procedure with a trim function being called. In the trim function, a cutting line is drawn, used to trim an object into two objects, then deleted. My script seems to work now, but in a file with a lot of objects, it seems to take a long time to execute. When an object is cut into two, what happens in the document list? Does one of the two pieces retain its place in the list and the other become the newest member of the list? If that is the case, then would a ForEachObject routine first go through the list of objects originally in the file, then continue through all the newly created objects (ie the second halves of all the trimmed objects)? If this is true, then none of these new objects need trimming and somehow I need to exit the routine after it is done trimming the original objects before it gets to the new ones. How would I get the trim function to return "True" to stop the traversal? This would save about 50% ot the trim calls I think. Peter

Seems good to discuss these things when no documentation exists. Just through this discussion I have already found a few good uses for this feature. For example, we plot some sheets using layer colors, and others without. It is nice to know now that I can now save my sheet with with a SetPref call added and avoid having to remeber to change the document preferences each time before I plot. This could also be done for the Black & White Printing preference. Thanks, Peter

A custom tool script does not select any tool, it just sets the defaults/attributes for the tool(s) to whatever they were when you saved the script. Are you saying it is not doing this? It works fine for text defaults on my Mac running VW 10.5 on OS 10.3. Have you tried option double clicking the script to open it up and see how it reads? Is it calling out a particular font size, style, etc.? Peter

Raymond, I guess I was thinking along the lines of adding a script which hides a layer when the edit sheet script itself is set to show the layer, for example. I am not quite sure why I would want to do that in particular, I am just trying to gain an understanding of how this feature works so I could figure out how to use it to my advantage. Thanks, Peter

Petri, Is this documented anywhere? I have posted this question before as well and never gotten any response. Since the edit sheet script itself does not show in the editor, if you are adding to the script which cannot be seen, would you add a stand alone script with its own set of variables, begin, end, and run, statements? Would the added script execute before or after the actual edit sheet script? If you add something contradictory to the edit sheet script itself, would it replace that item in the script, would it generate a VectorScript error, or would it just ignore it? Thanks, Peter

Why is Dialog Builder 4 still a beta version? Is there something still seriously wrong with this that it cannot be released as a final version? It seems like it has been out there for an awfully long time for a beta. I am not in the habbit of using applications in thier beta format, but there seems to be no other choice for building modern dialogs easily. Should I be expecting future problems with all the scripts I have written using DB4 for the dialogs? I have not encountered any problems yet. Thanks, Peter

Hi All, Thanks for the replies. I started this thread a while ago, and since got busy with real work (architecture). I never finished my script as I could not resolve some issues, but would still like to finish it when my time frees up. I know I should not use "DoMenuTextByName" if I can avoid it, but it was the only way I could think of to get around a couple things. First of all, I am trying to trim some objects with a cutting object like a line. I am not clear on how to "trim" without using the menu command. Secondly, to trim the objects, I need to have the cutting line selected, and the objects to be trimmed deselected. I have written my script to select all objects touching a user defined line. To trim them I thought I could group the selected objects, then enter the group, deselect the objects, trim them with my line, exit the group, and ungroup them again. As these objects may all be on different layers, I am already having to step through my layers and do a separate group/trim/ungroup for each layer. But at least when I trim, I can trim all the desired objects on each layer with one command. If I step through all the objects in each group, and trim them individually, I might be invoking the trim command a couple of hundred times for each layer. Next, my script was selecting objects on one side of the line an deleting them, but only those objects that were just trimmed (i.e. only those objects touching the line) The problem I was having with the script before I stopped working on it was the execution seemed very slow, and it also seemed to select objects nowhere near my cutting line and delete them unintentionally. I will try to get back into the script soon so I can be a little more specific with the problems it is having. Regards, Peter

Try the Function "GetObjectVariableBoolean"and check the VectorWorks appendix for the selector index for "Object is Locked" under Misc. Object Selectors. It appears the Function will return "True" for the index value 700 if a referenced object is locked. Never used it myself, but hope that helps. Regards, PeterT

As far as I know, the only prerequsite of offset by distance is the distance itself, and the direction of the offset. Both of these are set before the first click. After this, all that is needed is the number of clicks, i.e. the number of copies. The tool should have nothing to do with how fast you click, or weather the mouse moves or not. Why would it possibly be intended that this tool require the mouse to move after the first click? Oh well, according to iboymatt, VW11 has resolved this issue anyway.

Katie, I am on Mac OS 10.3.4 and running VW 10.5.1. I also just tried it on VW 9.5.3 and I get the same bug there. Going back to version 8.5.2 in Classic, it works normal again. To replicate it just draw a line, get the offset tool, choose offset by distance, and click twice rapidly on one side of the line. When I do this, I only get one copy, not two. But if I click three times rapidly, I get two copies. It is only the second click that is failing.

In VW version 10.5, if you offset the same line multiple times rapidly, nothing offsets on the second mouse click. If you offset slowly though, it works fine. Has this been fixed in version 11? It is a bit frustrating. Thanks, Peter

Please add a "Back" Button to the Resource Browser like all other "browsers" have. It is easy to navigate down through nested folders to get to the symbol you want, but if you accidentaly open the wrong folder, to just go back one level, you have to go to the pull down menu and scroll through a list of all the folders in your file and look for the name of the previous folder you are trying to get back to. I don't know about anyone else, but everytime I go to the pulldown menu, I have to scroll through a list of hundreds of folders just to find one. Backwards navigating was much easier in VW version 9 than it is in version 10. I think it is odd that the palette was renamed a "Browser" but was neglected one of the most important features of a browser, the "Back" button. I do not have version 11, but I do not recall seeing this feature in the demo. Regards, PeterT

If I enter a group during a script using "DoMenuTextByName('Group Navigation Chunk', 1);", once inside the group, would any additional calls affect only the objects within the group or would they affect objects outside of the group? For example, would "SelectAll;" select only objects within the group, or when the group is exited, would all the other objects on the layer(s) be selected? Is this a good method for isolating objects in order to perform operations on just those objects, or is their a better way of acheiving this? Thanks for any input, Peter

Check the VectorScript Archives for the answer to this one. There was a discussion on this back on May 30 or so. http://lists.nemetschek.net/archives/vectorscript-l.html Here is a snippit from the thread: ---------------------------- Subject: Re: How to close a Modern dialog Gerard, The way I do it is like in the code below. The statement "item := 1" is the only additional code required to close the dialog. Your message sounds like you're doing more than necessary... Matt ---------------------------------------------------------------------- CASE item OF {- dialog init -} SetupDialogC: BEGIN {Your code here} END; {- dialog cleanup -} SetdownDialogC: BEGIN {Your code here} END; { - OK button case - } 1: BEGIN {Your code here} END; { - Cancel button case - } 2: BEGIN {Your code here} END; { - Popup Menu case - } PopupMenuID: BEGIN IF {Your code here} THEN item := 1; <--- THIS CLOSES THE DIALOG END; END; {CASE} ----------------------------------------------------------------------

I would love to have the ability to Justify text in VectorWorks (right and left align at the same time). This is essential for long note strips, or text in columns, such as on a General Notes sheet. Although the text tool is better than it used to be, we still have to import all of our note strips as pictures due to this limitation. I can double justify in MS Word, but bringing in text from MS Word is limited at best, and gives inconsistent results when pasted as picture into VectorWorks. Life would be great if I never had to launch MS Word again, ever.

It is set for "One Page", as we have always had it set.

Yes, I ran it after upgrading to 10.3.3 and I run it regularly. Since my last post, though, I have come up with a new custom Page Size that cuts properly at 24", but I just don't understand why I have to do exhaustive trial and error test plots every time something changes. We have never been able to use any of the pre-configured page sizes that HP provides with their driver. The "D" size setup, for example, sets up the page for 24" x 36" exactly, but with no margins. Since the plotter itself has hard leading and trailing margins of .70 inches, if you plot using the "D" size setup it adds these margins to the 24" dimension and cuts the paper at 25.4". Under OS10.2.8 we had to set up a custom page size of 24" and then set up margins of .7 inches, which you can do in the custom page setup. This worked great and cut ther page right at 24". In OS 10.3.3, however, I now have to set up a page size that subtracts the margin dimension from the page size, and put nothing in the margin field. So if I call the paper 22.6" with no margins, now it cuts off at 24" again. Why this is different in OS 10.3 and 10.2 I do not know, but it must have to do with the driver, which is updated to version 3.0 in OS 10.3.

I just upgraded to Mac OS 10.3.3 from 10.2.8 and now my plotter is cutting the plots too long. What is up with this? I am using the exact same custom page sizes I used in OS 10.2.8 which was cutting the roll at exactly 24" (we plot in Landscape orientation to a 36" roll). But now on 10.3.3 the plotter is adding an extra 1/2" or so to leading and trailing edges and cutting the paper at around 25". I am using the exact same page setup and print settings that I have used for the past year on OS 10.2.8, but getting different output. Has anyone else had this problem?