Miguel Barrera

I believe you are setting the wrong scale: 1/4" = 1'-0" => 1/4" = 12" => 1" = 48" (1:48) You really want the object to be 1/4 of its size which is a scale of 3" = 1'-0" 3" = 1'-0" => 3" = 12" => 1" = 4" (1:4)

You could also mark them invisible by overriding the classes and/or layers of a viewport created in a sheet layer.

Just to expand on the vector solution: VAR vec1,vect2: VECTOR; p1X,p1Y,p1Z,p2X,p2Y,p2Z,p3X,p3Y,p3Z,dist1,dist2: REAL; BEGIN {.......} {.......} {vector starting at p1 and ending at p2} vec1.x:= p2X - p1X; vec1.y:= p2Y - p1Y; vec1.z:= p2Z - p1Z; dist1:= Norm(vec1); {Length of vec1} dist2:= dist1 - 5; {Assuming mm is the default unit. Otherwise use 5mm} vect2:= dist2 * UnitVec(vec1); {UnitVec is the vector that is 1 unit long} {p3 is 5 units shorter than p2} p3X:= p1X + vect2.x; p3Y:= p1Y + vect2.y; p3Z:= p1Z + vect2.z; {.......} {.......} END;

All plugin objects have a record with the name of the plugin so you would need to get a handle to this record. In older versions, the parametric record would be the last one but now you can get a handle directly with GetParametricRecord. PROCEDURE GetPio; VAR pX,pY: REAL; objHdl: HANDLE; pioName: STRING; FUNCTION GetPioName(pioHdl: HANDLE): STRING; VAR recTot: INTEGER; recHdl: HANDLE; BEGIN IF GetType(pioHdl) = 86 THEN BEGIN recHdl:= GetParametricRecord(pioHdl); { or this code if an older version} { recTot:= NumRecords(pioHdl); recHdl:= GetRecord(pioHdl,recTot); } GetPioName:= GetName(recHdl); END ELSE GetPioName:= ''; END; BEGIN GetPt(pX,pY); objHdl:= PickObject(pX,pY); IF (objHdl <> NIL) THEN BEGIN pioName:= GetPioName(objHdl); IF Len(pioName) > 0 THEN Message(pioName) ELSE Message('Not a plug-in object'); END ELSE ClrMessage; END; Run(GetPio);

I have experienced this before and I guess it has not been fixed yet. You probably have 2 choices: REPEAT GetMouse(mx,my); UNTIL Mousedown(px,py); {note: use other variables px,py} or substitute the REPEAT block with GetPt(mx,my);

This is something that I have thought about but have not had a need to code it. I would think that you can create a custom plugin and then embed the vw plugin within it. You will have to duplicate the vw plugin parameters to control it from your plugin. Then you can add your own code to customize your plugin further.

It seems odd that you would have that limitation on a windows machine. My largest plug-in is 272 kb (= 272,000 char) and is running from a single file. I had this problem about 8 years ago but it seems it got fixed on the Windows side around that time because all the newer plug-ins I have created since then are larger than 32 kb and running without problems.

Get a handle to the parent of the line and get the object type. If it is a group type then skip.

Make it a tool rather than a command. As you pick/select each line, the text will be placed immediately after. You can continue picking as long as the tool is active.

That is exactly what I am talking about. Your display units may be cubic & square meters but internally, it is calculated as cubic & square millimeters. So volume/area will give you linear millimeters, and in your case it is 4500 mm = 450 cm.

Because the internal units are mm even when the display units are cm. 1 cm = 10 mm so just divide the result by 10, which would give you 449.9915 and rounded up is 450 cm.

It seems that the connection to the record is broken. The code assumes that the Z value is in a record named "1' contour" and field "CONTOUR". If you can post a sample file, I can update the code to make it work better.

Should be placed right after a call to an ODBC function that returns FALSE such as IF DBSQLExecuteDSN() THEN BEGIN ... ... {Continue code} END ELSE IF DBSQLExecuteError() THEN BEGIN ... ... {Write out error information} END;

First you are trying to connect a database to a worksheet which cannot be done automatically. The ODBC is designed to connect an external database to objects that have attached records. An object is then matched to a row in the external database with a common field value. However, it is feasible to match the database to vw worksheet with scripts that will read from or write to the database. a sample script can be found at DBSQLExecuteDSN

There is also 2 other alternatives that you may want to consider. The one that will give you more flexibility and two way communication is ODBC but it is also the most complicated to set up. The other one is creating a *.csv file, also a text file, that can be read directly by excel. This last one was the only way to set up databases some time ago and I still use this method to read from data tables.

If your test is OK then most likely it is a hardware problem.

This is just a simple box I created in a new file. The rectangle has a solid fill and it is extruded.

No just the viewport. The design layer does render in solid color. I am also aware that there is a new checkbox that allows the rendering to be colored or not. Checked or unchecked, it does not make a difference.

I did update the view every time I changed the mode but OpenGL always renders as wireframe

I am having a similar problem when choosing OpenGL as the render mode in a viewport. It shows the wireframe rendering of the object instead of OpenGL. All other modes do change and render as expected. I have a windows laptop with 2 GPU. If I use the built-in Intel, it will not even change to a 3D view and gives the Out of Memory error. If I use the NVidia with 1 GB VRAM, it works fine except for the problem above. Win 7, i7-2670QM, 14GB RAM NVidia GeForce GT 540M

These are parameters in the "Extrude Along Path" pio: SetRField(extrudeHdl, 'Extrude Along Path', 'Scale', 'Exponential'); SetRField(extrudeHdl, 'Extrude Along Path', 'Factor', '-0.555827'); SetRField(extrudeHdl, 'Extrude Along Path', 'Lock Profile Plane', 'True'); SetRField(extrudeHdl, 'Extrude Along Path', 'Fix Profile', 'No');

Use PROCEDURE SetClFPat(className:STRING; fillpattern:LONGINT); basic fillpattern codes: 0 = No fill 1 = foreground color 2 = background color normally, you would set an object fill to the background color.

Piet, The following code will let you select 2 lines and will join them similar to the way is done with the Join menu command. The Join procedure is the same format that you suggested: PROCEDURE JoinLines; VAR line1Hdl,line2Hdl: HANDLE; selPt: POINT3D; FUNCTION CheckObjCallback(h : HANDLE; px, py : REAL) : BOOLEAN; BEGIN IF GetType(h) = 2 THEN CheckObjCallback:= TRUE ELSE CheckObjCallback:= FALSE; END; PROCEDURE Join(VAR line1,line2: HANDLE); VAR dist1,dist2: REAL; parallel, intOnLines : BOOLEAN; ln1beg,ln1end,ln2beg,ln2end,intPt: POINT; BEGIN GetSegPt1(line1,ln1beg.x,ln1beg.y); GetSegPt2(line1,ln1end.x,ln1end.y); GetSegPt1(line2,ln2beg.x,ln2beg.y); GetSegPt2(line2,ln2end.x,ln2end.y); LineLineIntersection(ln1beg,ln1end,ln2beg,ln2end,parallel,intOnLines,intPt); dist1:= Distance(ln1beg.x,ln1beg.y,intPt.x,intPt.y); dist2:= Distance(ln1end.x,ln1end.y,intPt.x,intPt.y); IF dist1 > dist2 THEN SetSegPt2(line1,intPt.x,intPt.y) ELSE SetSegPt1(line1,intPt.x,intPt.y); dist1:= Distance(ln2beg.x,ln2beg.y,intPt.x,intPt.y); dist2:= Distance(ln2end.x,ln2end.y,intPt.x,intPt.y); IF dist1 > dist2 THEN SetSegPt2(line2,intPt.x,intPt.y) ELSE SetSegPt1(line2,intPt.x,intPt.y); END; BEGIN TrackObject(CheckObjCallback, line1Hdl, selPt.x, selPt.y, selPt.z); IF line1Hdl <> NIL THEN BEGIN SetSelect(line1Hdl); TrackObject(CheckObjCallback, line2Hdl, selPt.x, selPt.y, selPt.z); IF line2Hdl <> NIL THEN BEGIN SetSelect(line2Hdl); Join(line1Hdl,line2Hdl); END; END; END; Run(JoinLines);

If you can select them, then you should be able to change the end points. You can find the intersection point with: PROCEDURE LineLineIntersection( l1start :POINT; l1end :POINT; l2start :POINT; l2end :POINT; VAR parallel :BOOLEAN; VAR intOnLines :BOOLEAN; VAR sectpt :POINT);

All you have to do is change the elevation of each NURBS vertex. In the example above if you start at 0.00 and end at 12.00 elevation, you then assign the appropriate elevation to the other mid points, which in this case is 4.00 & 8.00. The effect is a quarter spiral. In my experience, getting the NURBS object in the correct shape or roundness is far more complicated than setting elevations. By converting a polyline to a NURBS curve, most of the hard work is already done. Is it a bit too much effort? Yes, it is and the NURBS learning curve is steep. I spent countless hours trying to get a traffic signal mast arm (a tapered path extrude) in the right shape so that I could calculate the elevation at any point along the arm axis.