Miguel Barrera

Also any other tool that requires 3D view to operate.

No, only symbol definitions must have a unique name but you can have as many symbol "instances" in the document which is what the criteria is looking for. It would prove my finding that the script cannot reallocate and will stop at the second iteration if you indeed tested it with several symbol "instances".

Is there any particular reason it should be part of the viewport. I only include annotations that must be kept together with the viewport if it needs to be moved or symbols that must be at the same scale as the viewport. Otherwise, I keep other symbols and notes outside the viewports. Have you used INVIEWPORT in the wksheet query: =DATABASE((INVIEWPORT & (L='Layername') & (R IN ['Revision Marker']))) I just tested this and finds all markers in the layer whether they are located inside or outside of a viewport.

1. Just the alternate name 2. You must mean the Name. The double underscore hides the field until its visibility is turned on. 3. Explain further. What do you mean by #99? 4. Dimension fields already have values for metric and english units. If your document has metric units, the metric value will appear in the OIP as the default value. 5. The starting point would be the VW help with Vectorscript being the last chapter. After that, you can research further on the NNA website under Support->Vectorscript.

Annotation objects belong to the viewport and the viewport belongs to the layer.

DWorks, This is an example of reallocation that caused my computer to crash and have avoided since then. PROCEDURE Test1; VAR symTot: INTEGER; symList: DYNARRAY[] OF HANDLE; PROCEDURE ProcessSym(symHdl: HANDLE); BEGIN symTot:= symTot + 1; Allocate symList[1..symTot]; symList[symTot]:= symHdl; END; BEGIN symTot:= 0; ForEachObject(ProcessSym,((S='Symbol-1'))); END; I could not get past the second iteration of the loop and VW would always crash on Allocate. Charles, Before the debugger, I used to do the same thing and write out values. But for checking one value at a time it is faster to use the debugger because you do not have to add the Write statements and remember to delete them after. I only use Write statements where I need to check a sequence of values such as values in a long loop.

GetPickObjectInfo may work if there is only one symbol in the wall. If I remember well, walls are group objects that contain a 2D group object, a 3D group object, and the symbols inside the wall. Try FInGroup to get an object handle inside the wall and then iterate with NextObj until you find the symbol/pio type object.

This is usually a bug in the script that is not easy to recognize if you are using a variable for the index. Any value outside the limits of the array will trigger this error such as negative values, zero, or numbers larger than the upper limit. I am surprised that not many use the {DEBUG} directive to find errors. If you step over the function that declares the array, the script will stop at the point where the error is and you can then check the value of the index. A word of caution if you want to use Dynarrays. I have used Dynarray safely if I know beforehand the total size. I do not know if it is my computer or something else but I could not Allocate the Dynarray size more than once without VW crashing. I tested this behavior some time ago so I do not know if this was fixed in current versions of VW.

I have not tested this but it seems doable. You can create a dummy class and assign it to the new objects. Later in the program, use ForEachObject with the class as the criteria. When processing the resulting objects, you can then test further and select only the subset that you want. You can reassign the class for each in the loop or delete the dummy class at the end.

Why not just convert the polyline to a polygon in one step. You can adjust the number of sides of a curve by setting the 2D conversion resolution from low to very high in the VW preferences. But if you still need to do it your way, a simple script would do the trick. All these commands can be called in sequence. Furthermore, scripts would not fail due to the change of the parasolid engine. Scripts will function if all the commands used are still valid. NNA will drop commands once in a while and add much more on every release.

What are you trying to do with this info? There may be another way to accomplish the same task.

The name is assigned to the object following the procedure. Since you are calling a tool, it may be assigning the name to a temporary object used to draw the final object. Try assigning the name after the object is created. .... CallTool(-201); SetName(LNewObj,'Test Name');

Bret, Which analysis software do you use and how do you use it in conjunction with VW? Can part or all the analyis be done in VW? I know that some of the information needed for structural engineering is already in the drawing and is just a matter of extracting the data to do the calculations.

And why do you need to export the callouts to a spreadsheet or text file? It seems like a lot of work just to edit the callout text.

Where is the symbol that you are inserting? If it is in a template, you need to save the template with the updated symbol.

Actually, Pascal was the language of choice in the early and mid 80's when the mac came out. The OS and most mac programs including MiniCad were developed in Pascal so the obvious choice for scripting was to use the same language that everybody was familiar with. Before being renamed, Vectorscript was called, appropriately, MiniPascal.

Dynarrays are handled the same as arrays with the exeption that you need to allocate the number of items that it will hold while the program is executing. The size of arrays are predefined in the declaration of the variable while dynarrays have no size until you allocate its size in the program code. VAR totItems: INTEGER; strArray: ARRAY[1..5] OF STRING; strList: DYNARRAY[] OF STRING; BEGIN totItems:= 3; ALLOCATE strList[1..totItems]; strList[1]:= 'first'; strList[2]:= 'second'; strList[3]:= 'third'; END; I do agree that documentation on vectorscript is thin and some of us had the benefit to learn when the scripts were unlocked.

Even tough my reply was not about this but vectorscript, Ian already answer that question in his attached JPG. You can use the object info palette to change the formatting of characters as you type them. This would be faster than typing formatting codes that you need to memorize.

Which manual are you looking in? Text formatting has been included for a while now. You can either define the format before or after the text is created. PROCEDURE SetTextFont(objectHd :HANDLE; Start :INTEGER; Count :INTEGER; FontNum :INTEGER); PROCEDURE SetTextSize(objectHd :HANDLE; Start :INTEGER; Count :INTEGER; Size :REAL); PROCEDURE SetTextStyle(objectHd :HANDLE; Start :INTEGER; Count :INTEGER; Style :INTEGER); With the advent of object oriented programming, all objects have attributes (formatting) and actions encapsulated in the definition of the object. In this case, each character in a text string is an object. C++ and Java, which are currently the most used to develop programs, are OOP languages and OS independent.

You have the same options in Windows and as Pat says you should print with the "No Scale" option. If you choose "Fit to Printable Area" then it will scale down the whole sheet to fit within the boundary of the printer limits. For example, if your sheet size is 11x17, it will scale the document to fit in the printable area which is about 10.5 x 16.5 inches.

You can add as many buttons as you like in a custom dialog. The predefined dialogs cannot be modified other than providing the message and default string that will appear in it.

You should be able to use SetViewMatrix where the objectHandle can be a layer or a viewport. Declaration: FUNCTION SetViewMatrix(objectHandle :HANDLE; offsetX, offsetY, offsetZ :REAL; rotationXAng :REAL; rotationYAng :REAL; rotationZAng :REAL) :BOOLEAN; Description: Sets view matrix for layer or viewport object.

You keep missing the meaning of my reply. In plain words, even if ODBC was available I would have no use for it because I can always device better workflows than what is provided. You may benefit from having it but not all users will. Sometimes, certain technology is forced on us because it is the belief of someone that it is the only way to do a task. We need to think outside the box, analyse the task at hand, and come up with more efficient solutions if what is available does not satisfy our needs. A GIS object is no more than a graphic or cad object (point,line,or polyline) with a record attached to it. I am not suggesting that VW has the same functionality as a GIS program. One purpose of the GIS is to perform queries on the database and present the results in a graphical form. In my case, the manipulation of the data is done in arcview and the result is then imported into VW. If I had hundred of objects, it would be a lot of work to attach the data to each object. The parcels that I bring into VW already have the data attached and have no need for the live link because the data is not going to change in the time I design a road. The benefit I get from doing it my way is that the objects look exactly the same in VW as they do in ArcView without having to edit the objects. It only takes 3 clicks for me to do the whole operation.

With polylines I would convert it first to a polygon with a 64 resolution or higher. Depending on how accurate you need to be, this setting has given me acceptable results. I would then use the LineLineIntersection as Raymond stated to find the intersection with each poly segment.

There is always a trade off even when a dynamic link is available. You still have to put the time to setup the connection and make sure the data goes where it is supposed to. When you do your own scripts to import the data, you know exactly where the data goes and program it accordingly and best of all, you can change the script for unusual situations if you need to. And if the added feature, in this case ODBC, does not satisfy the requirements of some users, you will still hear complaints. Case in point, VW can now import shape files but I do not use it because it does not meet my needs. It imports the graphics as polygons without any attributes and all the fields (20+) in the database attached to each graphic. I would have to spend the time to change the attributes for each graphic and remove all the unwanted fields from the record definition. The workflow I developed even before the feature was added to VW consisted in an extension I created for Arcview which exported the area in the window view with all the attributes and selected fields into a vectorscript file. I would then import the vectorscript into a VW layer and I had an exact replica of the Arcview window with only the necessary fields. So the point is that even if you get what you ask for, it may not necessarily meet the needs of all users.