tcam.gif (6094 bytes)   mouse.gif (3933 bytes)



OFFSET operation for a true ELLIPSE

How OFFSET command works on a true ELLIPSE entity?  It seemsthat it will give different result for the same ellipse under different circumstances.

Yes, it is true that OFFSET may produce different results upon the same ellipse entity under different circumstances.

The true parallel path of an ellipse is not a true ellipse. It is a path that can only be approximated by spline, which is not directly supported by TwinCAD of current release. So, if the OFFSET operation is to create a geometrically parallel entity, then it will certainly fail or reject the operation when you pick up an ellipse.

However, an ellipse can be a projected circle under PUCS mode.  The OFFSET operation to such an ellipse can thus be defined to create an offset to the projected circle. That is, it is the original circle being offset and then projected to produce the required ellipse. This feature is useful in creating parallel projected drawing.

So, under PUCS mode, if the selected ellipse satisfies the requirement of a projected circle, the OFFSET command will give the result as mentioned above. Otherwise, it will be rejected, assuming that the operator is trying to create an offset projected circle while not setting up the correct PUCS axis for it.

If the operation is not under PUCS mode, then the OFFSET command will give you an ellipse result by directly modifying the length of the original major and minor axes. Of course, this is not the true parallel path to the original, but would be close.

If you do need to create a true parallel path of an ellipse, you can explode the ellipse into polyline first and then create an offset to the polyline. You can control the precision of the ellipse approximation by setting the system variable @splineseg to an appropriate value, before exploding the ellipse.

Rule for TEXT mirroring

When the system variable @MIRRTEXT is OFF, the texts resulted from the MIRROR operation may sometimes be different from the one produced by AutoCAD. Is that a bug or a rule difference?  What should I do, if I need the same result as what I will get from AutoCAD?

This is a rule difference, not a bug. The resulted text may differ only in its orientation within its bounding box. You may use FLIP command (a TCL/TCA program shipped with the package) to flip over its orientation to the other alternative.

When the system variable @MIRRTEXT is off, the MIRROR command operation over a Text entity will be treated differently. The Text will not be mirrored to produce the geometry result of its text strokes, but instead to produce a Text that remains the same readablilty within the same bounding box which is virtually mirrored in geometry.

The problem is in the text orientation within the mirrored bounding box. There are apparently two possible results. TwinCAD always takes the one that has the base line which is the geometry mirror of the original one. This gives a clear and consistent definition in mirror transformation. On the other hand, AutoCAD determines text orientation by maintaining its original "reading direction", which does not have a very clear definition from AutoCAD's documentation. The idea of maintaining the original "reading direction" of a text after mirroring is probably from the way we create dimensioning text annotations.

You may try to mirror a text serveral times in AutoCAD with respect to lines at different angles, and observe the change of text angles that result. You would find the change is not continuous at certain angles (depending on the original text angle). A major drawback of this mirroring scheme is in mirroring a paragraph of texts.  The text line ordering in the paragraph may be altered after mirroring.  You can easily see this by mirroring a horizontal dimension with a text annotation containing upper and lower tolerance expression with respect to a horizontal line. This is probably one of the reasons that AutoCAD would replace the dimension texts with a single MTEXT after R13.

Operation tips in changing line segments with QCHANGE

What is the operation rule of QCHANGE over a line in changing its length?


When you issue QCHANGE and pick up a line, you are going to change the length of the line (about the same function of LENGTHEN from ACAD). There are several ways to complete the change:

  1. By specifying a fix length value.
    After picking the line, you may directly enter the desired length of it. QCHANGE will modify the nearest end point to the pick point to meet the length requirement.  If the length value is given negative, the resulted end point will be in the opposite direction of the original line.
  2. By specifying a relative length increment value.
    After picking the line, you may enter a relative value in the form of @val to specify an increment or decrement of the line length. If the value is positive, the line will be extended from the end point nearest to the pick point; otherwise, it will be shortened by the given value.
  3. By designating a point.
    After picking the line, you may designate a point or enter a point coordinates. If the projection point on the line is beyond the line limit, then the line will be stretched from the nearest end point to the projection point. If the projection point falls on the line, then the line segment containing the original line-pick point will be retained, and the other line segment will be trimmed from the projection point to the opposite end point.
  4. By extending to a boundary object.
    After picking the line, you may issue PER snap directive to snap at a boundary object. The line will be extended ortrimmed to the geometry intersection point with that object.   The rule is the same as that in rule 3, except the projection point is replaced with the intersection point.

The rules stated above also apply to the ARC entity.

Note that in the first and second rules, it is the nearest end point of the line to the pick point that will be modified, not the other end point.


I try to DIVIDE an Ellipse, only get an erroneous result.  Does DIVIDE command support Ellipse as the target for division insertion? If not, what should I do to resolve this problem?

According to TwinCAD document, the DIVIDE/MEASURE commands support only Line, Arc, Circle and Polyline as the measuring targets, and the Ellipse is nowhere mentioned. This implies that the Ellipse entity is not officialy supported within the two commands. On the other hand, the system did not decline yor request outright for dividing an Ellipse, but simply treated it as an Arc. That is why you would get erroneous result.

The updated version of TwinCAD after V3.1.049 and its DOS counterpart after V3R4C1 have already included the capability to divide/measure along an ellipse, an elliptic arc or a polyline containing elliptic arcs.

If you do not have the update yet, you may explode the ellipse into polyline first, then proceed to the DIVIDE/MEASURE command.

How do I paste in a text paragraph into TwinCAD?

Can PASTECLIP command paste in a paragraph of text from MS-WORD? If it can not, how do I paste in Text information into TwinCAD?

By design, the PASTECLIP command can not paste in Text information from the clipboard. It is intended to paste in drawing (either created by TwinCAD or by AutoCAD) only. Thanks to that, its operation can therefore be simple and direct without any confusion. As for clipboard data with formats other than the drawing formats registered by TwinCAD or AutoCAD, you will have to use other commands to do the paste-in conversion. Currently, there is one command called PASTEXT, which is used to paste in Text information from the clipboard. You can use PASTEXT to paste in a paragraph of text which was cut from a Word processor such as MS-WORD. The PASTEXT command is an external command developed in TCL language. If you don't have this program, you can download it from our web site ( or You may copy this PASTEXT.TCL or PASTEXT.TCA (for lite mode) program into COMMANDS sub-directory to have this command support.

Can I repeat alias commands with space bar?...

Why some command aliases can be repeated with the space-bar and some can not?

Actually, none of the command aliases can be repeated by pressing the space-bar. The reason is that activating a command alias, just like activating a screen menu, will make the associated script be fed into the system and executed. So, they cannot be repeated by pressing the space-bar.

Of course, if the "script" associated with a command alias is just the name of a command, then you may repeat that command by pressing the space-bar. In fact, it is the last executed command that you are repeating, not the associated command alias script.

Measuring distance between two parallel lines...

I wanted to measure the distance between two parallel lines. So, I issued the DIST command and, intuitively, used two successive PER snap directives to snap on the lines. To my surprise, it failed. What should I do to measure that distance ?

If you are certain that those two lines are parallel, you may replace one of the PER snap directive with the NEAR directive to snap on the line, so that a specific LINE solution can be found for the DISTance measurement.

Basically, the DIST command will call out the internal 2-point LINE command to determine a line of which the length is of interest.  Since in the LINE command, you can not use PER/PER on two lines (parallel or not) on the same spatial plane to define a line, the DIST command would certainly fail in the same cases.

P.S.: The update version V3.0/R3 has included the support to treat this condition as a special case. You may use PER/PER to measure distance between parallel lines now.

Can I purge the un-used blocks in one shot?...

The PURGE command can not purge all the un-used blocks in one shot, why? How can I make sure that all the un-used blocks are purged?

This is because these un-used blocks are really in use before the purge operation. When you issue PURGE command, the PURGE command will start scanning the whole drawing database and mark all the un-referenced blocks for deletion. A block will be purged off when it is no longer in reference.

However, if there are two blocks, say A and B, and block A contains a reference to B while A is not referenced anywhere in the drawing, the PURGE command will delete A and keep B (since it is in reference). The block B will become un-referenced only when A is deleted from the drawing database with the purge operation.

You may issue the PURGE command again and again, until no more blocks are reported for deletion. Then, all the un-referenced blocks will be removed.

Stretch problem for Ordinate dimensions...

I use STRETCH command in ACAD to stretch the Ordinate Dimensions generated by TwinCAD (after DWGOUT), but it produces strange results. It has no problem at all if I stretch the ordinate dimensions generated by ACAD. Does this imply that the ordinate dimensions generated by TwinCAD is not fully compatible with ACAD?

You must be using R11 or R12 that supports ordinate dimensions, since the R10 does not support the ordinate dimensioning. So, the R10 DWG file produced by TwinCAD's DWGOUT command can not have ordinate dimensions in the drawing. TwinCAD must disguise them as some other dimensioning objects in the drawing.

In fact, as R10 does not support the Leader and Center mark as official dimension entities (it merely draws them out), and the Ordinate dimensions are only supported after R11, TwinCAD will disguise them as Angular Dimension entities in the DWG file. This would cause no problem at all if you load the DWG file in ACAD, since it is the dimension blocks that determine the picture of the dimension entities and the dimension entities in ACAD are merely records of the creation of the dimension blocks.

However, if you issue STRETCH command to operate on such entities, the ACAD will actually take them as Angular dimensions and try to re-produce the dimension pictures according to the rules of the angular dimension! This is the reason why you would have a strange result.

If necessary, you may stretch the ordinate dimensions in TwinCAD along the dimension line by using the CHANGE/ALL command, or using the STRETCH command to any orientation after V3.0/R3a. Or, DWGOUT the drawing file in R12 format by setting the system variable @DWGVERSION to 1 after V3.0/R3b.

Object selection affected by view window...

When I was selecting objects using window crossing, after indicating the first corner point, I issued a transparent command 'ZW to change the view window. After the view window was changed, I continued to indicate the second point for the object crossing window. Unexpectedly, the object outside the view window but actually inside the crossing window was not selected! Why? Is there any problem?

No, there is no problem at all. This is normal. All object selections or object pick-ups by means of the user screen interface are limited to those objects appeared in the drawing window only, no matter how the pick points are given.

In fact, the searching of objects crossed by a picking target box are not directly from the drawing database (if so, the search time would be terribly long), but from a display list that contains only those clipped drawing vectors seen from the screen, so that the search time is greatly cut down. This limitation is thus a natural result of the implementation.

DIVIDER.GIF (2170 bytes)


How to define a transparent alias command?

How to define a command alias that can be invoked transparently?


All you have to do is to add a single quote (') before the alias name in the command alias definition. This quote will tell the system to allow the command alias to be invoked transparently. Yet, this does not mean that the command script associated with a transparent command alias will be successfully executed in the transparent mode. The script activation of a command alias works the same way as the menu script which is activated from the screen menu. The only difference is the way to activate them, that is, one by the command word and the other by the graphic user interface.

Rule for BPOLY/Auto to search out the maximum area coverage.

The BPOLY/Auto is intended to search out the maximal coverage of area automatically from the selected boundary objects. What is that all about?

The BPOLY/Auto command provides a very useful feature in finding the maximal areas bounded by the selected boundary objects. The boundary objects are used to form networks, and the BPOLY/Auto will find out all the maximal area coverage of each independent network. Those independently created areas will become the base surfaces, holes or islands of the final regional area, according to their topological relationship determined by the even-odd rules. With this feature, the operator no longer needs to select the loops of area from the networks one by one, but simply enter the sub-command option "Auto" to determine a maximal regional area. The "independent networks" are defined as networks that do not connect with one another. If there exits any connection between them, then a single yet more complex network will be formed. For example, two concentric circles are independent networks, and BPOLY/Auto will locate two independent maximal areas from them. One is the outer circle and the other the inner one, forming a ring as the final regional area. However, if we draw a line across the two circles and divide each of them into halves, then they will form a single yet more complex network because of the connection. As a result, BPOLY/Auto will locate only one maximal area out of this network, i.e., the outer circle, which is the total combined area of those independent loops from the network. From the latter case, we can clearly see that there are 4 loops in the network. You may have C(4,1)+C(4,2)+C(4,3)+C(4,4)=15 kinds of choice to select those loops to form a regional area. The ring from the former case is only one of the possible combination. Obviously, from a complex network, the BPOLY/Auto will not guess how you want to combine those loops and make the pick. What it can do, however, is to choose the unique and undoubtedly one, i.e., the maximum one. If that is not what you need, then you will need to make your own pick manually. Based on this combinatory principle, if you have selected some loops from an independent complex network in advance, then it is assumed that the combinatory regional area of that network has been determined and should not be altered by the BPOLY/Auto processing. This states another important rule: that BPOLY/Auto will neglect the networks that contain previously selected loops.

Snapping on the center mark.

How to snap on the center point of a center mark entity? Why can't I snap the point by using INTersection directive?

You should use CENTER directive to snap on the center point of the center mark entity, instead of the INTersection directive. This is because the center point of a center mark entity is a geometric data of the entity, not an intersection point of two crossing lines.

However, the new release of TwinCAD update version has included the support for snapping on this center point using INTersection directive.

SLD file difference between TwinCAD and ACAD.

What's the difference between TwinCAD's SLD and ACAD's SLD files? Are they compatible?

Basically, the SLD format adopted by TwinCAD is nearly compatible with ACAD's SLD format, except for the following:

  1. There is no limit on the number of vertices for a solid-fill area in the TwinCAD's SLD file, while ACAD can not handle such solid-fill area with more than 10 vertices. Most of the desk-top publishing software do not have this limit.
  2. TwinCAD's SLD file format allows complicated solid-fill area with holes and islands by means of starting vertex checking among the vertices list, while ACAD does not support this extension. Some of the desk-top publishing softwares do support this extension implicitly.
  3. TwinCAD uses physical color (VGA palette number) for pen number, while ACAD uses drawing's logical pen number.
  4. TwinCAD uses logical drawing space with 1:1 aspect ratio for the vector image despite of the graphic device in use, while ACAD uses physical drawing space with a physical aspect ratio taken from the graphic device at the time the SLD is prepared.

In fact, TwinCAD can load and view the SLD files generated by ACAD without problems. And, if the slide files generated by TwinCAD do not contain complicated solid-fill areas, it can also be viewed by ACAD. Of course, the display color may look different.

Creating and modifying user variables.

How to create a user variable? Is the operator allowed to modify such user variables freely?

All new user variables must be created by explicit calls to the TCL uservar() function, either from a TCL application or from an expression entered directly to the command line. Once a user variable is created, it can be accessed from within a TCL expression as if it were a predefined system variable, as long as the access matches with its declared data type. The system also provides a USERVAR command to help the operator in viewing and modifying the existing user variables. It works in the same way as the SYSVAR command does.

The modification of the content of user variables by the operator, however, will depend on the data attribute assigned to the individual variable at its creation by uservar() function call. If it was set to READONLY, then it can not be modified in the normal way, including the USERVAR command operation. To modify a READONLY user variable, the uservar() function must be called explicitly for the job.

For details on uservar() function, please refer to the document "TwinCAD Command Language(TCL) Reference Manual V3.1"

Additional arcs on offset polyline.

I've already set @POFSTCANG to zero, why sometimes there are still unwanted arcs added to the offset polyline?

This is because the offset distance is too large for the polyline to have a proper offset path without introducing additional arc segments. It happens when two adjacent segments can not have a proper intersection after being offset with the given distance, and thus an additional arc must be added in between to make the path continuously joined. It always happens when at least one of the segments is a circular arc, making a sharp and concave corner angle, and the offset path is made outside of the corner. Offsetting the arc will shrink it toward its center, and make it smaller, which is farther apart from the other offset segment. As the offset distance increases, they lost their intersection eventually. To prove it, just explode the polyline and offset each segment to see if they can be joined together by extending them to the intersection point.

Problem in creating custom toolbars.

I tried to add a few toolbar definitions of my own in the MNU file. But TwinCAD failed to create them when the menu file is loaded at startup. Why? What should I do to solve this problem?

That is because you had added too many toolbar definitions to the MNU file, and there was not enough heap space for TwinCAD to accommodate them. You have to remove or comment out some of the unwanted toolbar definitions from the menu file, not just to turn them off from TwinCAD. Reducing button counts in a toolbar definition is also helpful in relieving the problem. Currently, TwinCAD allocates memory from the heap space for toolbar creation, and the heap space reserved for that purpose is limited in TwinCAD. The required size of the memory space for a specific toolbar definition depends on the number of buttons it contains. The size of the button or the size of the bitmap file used for the button face is irrelevant. P.S.: For version after 3.1.048 (inclusive), each toolbar will take up a fixed 100 bytes of heap memory space. The number of buttons contained in a toolbar is now irrelevant to the heap memory usage. This would allow more toolbar definitions in the menu file.

gotop.gif (1250 bytes)
Go to top