Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Mbuck

  1. Petri,

    Now now - no need to personalise your frustrations, I will acknowledge when someone is correct but remember I have paid for and worked with Minicad / Vectorworks since purchasing my original copies way back at Minicad for mac version 2 (maybe even version 1 but I cannot find the old mac disks to verify that fact). Like you, I think I have something to contribute in making Vectorworks not just a good product but a great product. For example have you seen the latest capabilities of DWG/DXF translator in VW 11 - compare NNA?s effort with the translation capability to Revit and ArchiCad and you will be surprised. Furthermore; VW viewports, although late in coming, most would concede are a more powerful and more flexible implementation than those found in AutoCad?s (what other program has multiple model spaces that link to multiple viewports) these are features and flexibility didn?t just happen by accident.

    I honestly believe that NNA listens and unlike you it seems, I accept the fact NNA has limited engineering recourses, much like every other software company in existence - maybe only Microsoft is the exception. NNA wish list must be huge and I would not like the task of prioritising it for them and since it is there company it?s their call. It must be acknowledged that most times I think they get it right - this is irrefragable since NNA are still in business and continue to expand their user base.

    Sometimes, like you, I do get frustrated with NNA because they come so close to hitting CAD software?s sweat spot, yet at closer inspection a new tool has an serious Achilles heel - maybe the wall tool is a good case study of this tendency ? they should have spoken to more users before having to finally rewrite the entire code in order to implement cavity joins correctly, but then again everyone is wise in hindsight and NNA eventually seem to get it right. That said, like you I am still waiting for the time when NNA get the DTM code right ? which by the way also has come a way since version 9.

    Lastly, and on a personal note if you have 500 good quality vectorscript tools why don?t you put them on Vector Depot and sell them ? I will buy them if they are as good as what you say they are. You never know NNA may get so embarrassed about Vectorwork?s current limitations that they are left with only 2 possibilities: First, NNA shameful of how they have behaved in the past immediately knuckle down and make all of vectorwork?s current limitations simply disappear or alternatively they send their private jet to Melbourne pick you up so that you can start working for them on Monday.

  2. Kevin;

    What I am talking about is a tool called offset wall that when used brings up a dialog asking the user what is the required offset amount for the selected wall. Typically in Australia for older domestic construction (alts and add type work) walls are typically 270 mm and 110 mm masonry. Therefore the general formula for the offset would be:

    wall(2) / 2 - wall (1) / 2 = +/- required offset dimension.

    Granted this is 2 step process but it is still very quick.

  3. Well Petri it seems things are looking good for you since you relocated permanently to the cultural hub of Downunder i.e. Melbourne.

    I suggest if you are now doing projects as complex as the ones that you describe then you must do yourself a favour and upgrade to VAA 11 (more recently version 11.0.1.) I thought you knew that the Australian version of vectorworks architect allows walls to be offset from their internal or external edge or dare I say ?from their centre. Alternatively you can dynamically stretch a wall to the position you desire and key the offset dimension in the data bar, all whilst maintaining a dynamic connection to other walls.

    See sometimes even a humble ?BS? engineers can teach an architect a thing or two, but I must say, in my experience, must architects have some trouble in writing cheques especially for software upgrades.

  4. Why is resizing from the centre of a wall so bad; at least wall cavities keep their centreline / alignment. Presumably you?re not changing the cavity size? Also, Vectorworks 11 has the capped wall join mode which allows a thicker wall to abut upon a less thick wall - so I cannot understand your problem! Unless you are trying to keep the room internal room dimensions the same i.e. the same room area before and after. However, something has to give i.e. the room area decreases in size slightly or an external wall gets closer to the property boundary. I not an architect though; so maybe Petri can give all of us fascinating discourse on why this limitation is so bad and maybe NNA will change the wall behaviour if the need is so great.

  5. Robert;

    A belated reply since I have been away. Although, I don't claim to be an expert in these matters my experience of using different digital terrain modelling programs tells tell me that something is eschew with the current Vectorswork.s DTM code kernel. As has been said by me and others the DTM module oftentimes gives unreliable; and to the uniformed dare I say, misleading information - be it in repect of either it calculated 2D or 3D data representaion. This cannot be user base mass delusion; it is not true to say that given certain data set that the triangulation (TIN) and hence the contour representation will be unique. Sparse data by definition must be interpolated and herein lays the problem with the algorithms currently in use ? the current implementation just does a bad job at interpolating and weighting the 3d point data. For example look at differences one can achieve using different algorithms.

    figure10b.jpg- [/img]

    Contours based on linear triangle based interpolation


    Contours based on Clough-Tocher interpolation of the data points


    Contours based on natural neighbour interpolation and extrapolation of the data points.

    This tells the storey and I suggest your programmers read this article at this web address.

  6. Robert;

    The only problem is that there are many varieties of Delaunay triangulation algorithms for two and three dimensions. The particular algorithm used depends largely on the situation for example - is the terrain convex or concave? What is the shape of the enclosing polygon? and so thus some DTM code is ?smarter? than others code but no code will get it right 100% of the time. Each algorithm some of which are list for example:

    ? Octree= randomized insertion algorithm using an octree for locating the enclosing tetrahedron

    ? DeWall = Delaunay wall algorithm without searching structure

    ? Matrix = with sparse matrix

    ? Gitter = with regular grid

    ? Insert = randomized insertion algorithm

    give very different results depending on the situation.

    What I am talking about is that the surveyor is the one who truly knows how to form the triangles of an existing terrain ? Petri?s "real world data". It is he or she that knows which triangles need to be flipped and which don't. Which triangles are too thin and which are not. This is by reference to their field notes. Triangle flipping is a basis feature in almost all DTM packages yet VW11 DTM doesn't have this flexibility.

  7. Robert,

    I tend to agree with Petri and I accept the fact that Vectorworks was never intended to be a dedicated digital terrain modelling package, although the name "Landmark" gives a certain market impression which to some prospective buyers may infers that level of functionality. I personally don't believe that NNA intended to deliver that message but probably in hindsight "Vectorworks Landscaper" or similar would have been a better choice of name. Despite this, I personally like Vectorwork's simplicity and don't particularly want all the functionality that is present in market specific DTM packages. These programs usually having very clunky and complicated user interfaces, but do a vast array of clever things that I and many other users no doubt will probably never use; including: modules for collection and translation survey instrument data, interfaces to hydrological models and specialized software tools which handle the automated production of roads and civil works documentation. I do have the strong conviction that even if VW Landmark's is has the most basic DTM contour modelling functionality, it should still produce correct information, i.e. that which is consistent with natural landforms and not distort those landforms in anyway, but as you know I have given many fine examples to NNA of distorted Vectorworks DTM output. Many inexperienced users unfortunately use this package and probably never question the veracity of its output. This is evident if you look at the NNA's bulletin board. A typical query goes something like this: "I finaly was able to get the 2d polys turned into 3d contours, and use those to modify the surface. The problem is that when I go to AEC\Site Model to update, it works but the surface and contours it generates aren't close to what I want. What I am doing wrong or leaving out."

    NNA often answers but sometimes misinforms their users thereby perpetuating the myth that it is indeed a user related problem or misunderstanding. I am suggesting is that maybe NNA has a legitimate basis on which to jump ship to another but more robust DTM kernel.

    NNA must in the interim give their users viable workaround strategies. The ability to simply insert a 3D TIN produced by a surveyor within VW 11 and then generate from this an accurate 2D contour, would be a good first start - from my understanding this functionality does not exist. The importance of feature cannot be understated; it must be understood by all, that the survey TIN produced by a surveyor is the only true basis on which to form a 2D contour. It is they that know the true nature of the landform, since they have surveyed it. Therefore it is only they that know where to put all the relevant break-lines and the like. In addition most times they are using more sophisticated DTM packages to produce the final TIN. Robert if I am incorrect in my assertion please send some time and educate me and Petri.

  8. Some time back I listed a dozen things that annoyed me about the VW 2D interface. I am please to note that some of these limitations have been lifted in VW11. This proves that NNA does listen to it users - this has always been NNA?s major strength. I take pleasure in updating my list with reference to some of the new features in VW11, I have also added some of my current thoughts on possible enhances to VectorWorks toolset and user interface. No doubt NNA has already many of these issues in its gun sight but one can never assume anything and hopefully these squeaky wheels gets oiled in VectorsWorks 11.5 and 12.

    1. A new preference setting which prevents dash line styles, which are applied to polylines, polygons or just lines, from ending with gaps at their corner points.

    VW 11 now has this feature although it is not optional.

    2. The ability to use previous view (zoom previous) whilst in pause/boomerang mode.

    VW 11 still doesn?t allow this.

    3. The ability to lock onto nearest points by giving the user additional functionality (say pressing the P key) to dynamically toggling between a series of the nearest lock-on points.

    VW 11 still doesn?t allow this but I think NNA should look very seriously about the whole issue of object selection and user feed back as to when and if an object is selected. The old mac type selection handle idea is now ancient history and just doesn?t give a user enough visual feedback. A model that may be worth assessing is the way Intergraph SmartSketch 4 handles this issue. There are also some other very good ideas in that program that could be borrowed. I like the idea of being able to rotate, lock and mirror and object without having to evoke special tools. Also the connector line tool is a great idea this is a cross between NNA?s wall tool and Microsoft?s Visio?s connectors i.e. line work which interacts with symbols (they are automatically flipped according to the line orientation) and the lines can auto connect when moved something like NNA walls but with more flexibility in the way they create displacement offsets and the like.

    4. Changing the position of the fields L (Length) and A (Angle) data display bar. These parameters should be in the initial tab positions, and X and Y should be last.

    VW 11 has not implemented this but shift tab with VW1 data display bar makes the data display bar much easier to use.

    5. The Callout tool should have an option which allows the user to dynamically change the shoulder length of the leader.

    VW 11 now has this feature but unfortunately they have deleted numerical input as an option.

    6. Since hatch patterns are an editable characteristic, which oftentimes need to be redefined on the fly, this need is no different to editing symbols and groups. Why then doesn?t the new double click feature (which is fantastic) open up the hatch dialog so that the hatch can be redefined with the least amount of effort.

    VW 11 still doesn?t allow this but I see the double click as consistent user interface behaviour for example at present double clicking on the text when using the callout tool opens a text edit box, a user in my opinion would expect that double clicking on an object?s graphic attributes should behave in a similar manner.

    Double click on a wall brings up the wall stye editor;

    Double click on the hatch pattern brings up the hatch style editor;

    Double click on the gradient fill brings up the gradient settings; and

    Double click on the image fill brings up the image settings; and so on.

    7. A new preference setting which sets the resource browser background colour to black when using a black background to draw.


    VW 11 still doesn?t have this feature.

    8. The trim tool trims around cuts a line to the boundary edge of a closed object, say a rectangle tiled right at 45 degrees. Change this object to a symbol and the line is cut not to the bounding edge but to the bounding box or rather the symbols handle extent. This tool should always cut a line to the objects bounding edge and it should not matter if it is a symbol, group or closed object.


    VW 11 now has this feature.

    9. 2D User defined coordinate system.

    VW 11 still doesn?t have this feature.

    10. Consolidate the custom selection tools in to one more intuitive tool who amongst us really understands the custom selection 2 tool is for.

    When will NNA deliver us a simple yet very powerful magic wand selection tool?

    11. Build Katerina Panagiotakis?s Class Utilities utility into VectorWorks 11 interface also extending its functionality to layer control.

    VW 11 still doesn?t have this feature.

    Maybe the new magic wand tool could also feature the following

    ? Classes All On - Turns all classes in the drawing on.

    ? Class Current - Sets the active class to a selected object.

    ? Class Delete - Deletes the class of a selected object and all objects in that class.

    ? Class Gray - Grays all items in the class of a selected object.

    ? Class Hide - Hides all items in the class of a selected object.

    ? Class Isolate - Turns off all classes except the class) of selected object.

    ? Class Select - Selects all objects in the class of a selected object.

    ? Object Hide - Hides a selected object.

    It must be said that the class and layer visibility pallets go someway towards this end but are a interim and not a final solution.

    12. Layer linking I can?t explain why exactly but it?s a pain, especially if one layer is in plan view, but unbeknownst to the user, some other layers are in top 3D view and one wonders why he cannot select or snap to objects in on those layers. This must be very confusing for a new user because it often trips me up.

    Probably VW least understood feature but thankfully we now have viewports which makes the 2D application of this feature obsolete.

    My final wish which was not part of my original 12 is that somehow VW the 2D and 3D interfaces can be harmonised. The separation of the environments is both Vectorworks weakness and its strength. The hybrid environment is good for plan presentation purposes, but many new users, especially former ACAD users, must ask themselves as I do - ?Why can?t I??

    ? Use a dashed styled 3D polyline?

    ? Why is there no 3D text?

    ? Why are there no 3D dimensions?

    ? Why do smart walls become dumb walls when moved or manipulated within the 3D environment i.e. the auto-connect feature and other wall tools are rendered useless in the 3D environment?

    ? Why can?t I simply stretch a 3D wall or move a 3Ddoor or window within a 3D wall?

    ? Why do I have to use specialised 3D tools why don?t the tools simply know they are now working within the 3D environment?

  9. DWF can be translated to a DWG, which can then be read into VW. The only problems for MAC users particularly, and others is that you have a copy of AutoCAD 14 to 2002 and purchase the "dwfin" AutoCAD plug-in from IntelCad. Once loaded the dwfin command reads the DWF file into AutoCAD. The dwfin AutoCAD plug-in is the only program in the world that can do this. IntelCad has reversed engineered the DWF file format (refer to link below), but I am sure John Williams and his team are smart enough to emulate this functionality within VW; but don?t hold your breath, implementing AutoCad?s new 2004 file format translator no doubt would be enough challenge at present.


  10. In landmark there is a command which converts 3D polys to 3D loci, this command places a 3D loci at each vertex along the polyline/polygon. I have the need, however, to place 3D loci at the midpoint of the polyline. Has anyone got a simple vectorscript which would do this which they are willing to share?

    This need has arisen, because of an unfortunate turn of events when attempting to translate the DWG survey data points, which unfortunately are not being translated as 3d points but rather as small polylines the midpoint of which would be the centre of the cross. Using the 3D polys to 3D loci command appears to gives me 5 points (I suspect there are coincident points) one in the centre of the cross and 4 loci at its extremities, there are thousands of these points therefore, manually deleting these extra 3d oci woul be a real pain, can someone help? "VectorScript to the rescue".

  11. The standard arrow head types, set by the attribute default menu, although probably practical, are now very boring, increase the arrow head style choice or make the current selection more user configurable.

    Has anyone after importing an AutoCAD drawing wondered why the text, although mapped to the same font type, appears never to precisely match the look it would have if viewed in AutoCad, i.e. usually the text line is wider spaced in VW, oftentimes overflowing beyond the boundary of its title block or graphic text box. The reason I have found is that AutoCad text (non truetype fonts, usually) also have a style definition which contains the amongst other things the % horizontal text spacing. For some reason most AutoCAD users set this to at about 75% to 80%. If VW also had inter-character word spacing (also know as tracking) this could be avoided. Word and many other programs have this feature so it must be fairly easy to implement i.e. licence some code to do more with text. Implementing subscript and superscript would also be much appreciated.

  12. 1. The ability to convert polylines to site modifiers. One should be able to draw site modifiers using the polygon tool - first get the polygon geometry correct and then convert these polygon(s) to site modifier objects. Reason: you cannot use VW offset tool to offset a fence away from a pad. No big deal when the objects fence and pad modifiers objects are square or rectangular; but when they are constructed of a many sided polygons this very time consuming if you are using a pad and fence combination as breaklines.

    2. The batter width, slope and height created between pad and fence objects should be user definable. In other words once the pad is created the user should be able to simply rise or fall and the VW determines automatically the correct offset for the fence site modifier; conversely draw the fence define the batter slope and the correct pad level is determined. Reason: circumvents trial and error required.

    3. The contour label text needs to have parameter, which allows the user to define how often they would like the text repeated along the particular 2D contours. Reason: Control over the look of the topo plan.

    4. The 3D triangulated view should allow the user to distort/scale the z-height to give the user a better conceptual feel of the topography of the site. Reason: Obvious.

    5. The cut and fill extents should be able be to be more easily visualised. I suggest cut should have a graduated ?red? fill (light red shallow cut strong red for deep cut). Likewise fill should have say a graduated ?green? fill (light green for swallow fill and dark green for deep fill). Reason: Obvious

  13. I assume that you mean a fence modifier that is coincident with the pad modifier. This I have tried on many previous occasions but the method always proves unsuccessful. Today, once again, as per your advice, I tried it with this much larger DTM and once again, as per my previous experience, it was unsuccessful -VW DTM algorithm(s) seems to get confuse and VW simply hangs requiring a restart. I suspect that the DTM module is trying to force a batter to be calculated between the fence and pad and because these entities are coincident it cannot calculate the transition; hence the need for a true breakline entity for future versions of VW. If you think this is not the case please let me know a possible alternative solution. Note that offsetting the modifiers will produce a batter between them, which in this case is not intended as one is in effect, trying to create an internal shear cliff face.

  14. I understand that VW Landmark does not important feature, which in many DTM packages is referred to as breaklines. Am I therefore correct in assuming that the ?Pad site modifier? is VW's equivalent. If this assumption is correct, then why in many cases am I seeing that such closed polygon site modifiers constraints are being ignored i.e. triangulation continues to cross this bounding constraint. Recently, for example I have a large site approx 9,000 data points but in the centre of the site there exists an old quarry (a deep hole 200 m in depth), which is obviously not developable land; and as such has no point data within that area. Although I have put a pad modifier around that area in an attempt to excise that portion of the site; when I generate a proposed contour the pad modifier boundary is largely being ignored, i.e. the DTM triangulation continues to cross this pad boundary. What condition(s) trigger this? Or is it a bug? If so would it not be more sensible to have another but more robust site modifier/constraint called a breakline which could achieve this end.

  15. Ok Jan15, here is just one simple example which demonstrates Vectorworks ?clear consistent logic in action?, this is a very simple task, forget about ?complex drawing file with powerful control features? for a moment and follow this example. Make a simple drawing containing just one layer, call this layer ?ground floor? then define one class called it ?stormwater disposal?. That class will have the following attributes: (colour= blue, pen weight=0.7 mm, line style=dashed) and set ?use at creation? option to be on. The entire text notation relating ?stormwater disposal? class will also have to reside within that class, so that this class can be isolated form other services on the drawing for the purposes of enquiry or plotting etc. To do this make the ?stormwater disposal? class active and use the ?Callout Tool? to start noting up the stormwater service lines. Oops! - note that the text is green and leader line a dashed 0.7 pen, but I wanted white text and a 0.25 continuos line for the leader line. No problem you say; every time you put down ?Callout text? simple select the text and leader and changes if from the default class attributes, unfortunately I have to do about 50 times. Simple I hear you say, just turn off the ?use at creation? graphic attributes setting and change the default class attributes to (white and 0.25), the only problem is that I also need to update the stormwater line at the same time to suit a new architectural layout that has just arrived, therefore I want the ?use at creation? option on. The reason for this less than intuitive mess is that the callout tool base objects are in the none class and the PIO is adopting the attributes of the container class ?stormwater disposal? but I want it to be in the stormwater disposal class but not to adopt the ?stormwater disposal? class attributes. The only work around that I have found is to make the callout tool into a symbol and assign that symbol the ?stormwater disposal class? and then to set the applicable graphic attributes intended for the callout tool and then set the convert to plug-in object insertion mode. Jan15 will know doubt tell me that this demonstrates the power and flexibility of Vectorworks. I say all it does is demonstrate how unintuitive class manipulation can become even to handle such a simple task as this. I am sure others have had similar experiences, if a "class viewable scope" is not the answer maybe "iboymatt style sheets" need to be explored further.

  16. P Retondo; thankyou for thinking about this issue more deeply than perhaps others have; I am not sure your solution; however would work in a general sense. I will give you an example to clarify my proposed methodology, and hopefully this will explain what I meant when I said;?this concept needs to re-focused towards what users are trying to achieve when using classes?. For example, say that one had 3 layers. Layer No. 1, being a project detail sheet layer which comprises of say 3 building details in this case named detail ?a?, ?b? and ?c? which are all resident on that layer a layer scale of 1 to 20. Layer 2, is then an architectural building layout at layer scale of 1 to 100. Layer 3 is a title block sheet and its layer is also at a scale of 1 to 100. In this example Layer 2 is the active layer. In terms of the ?scope? of the classes the Layer 3 object, namely the ?title block? must be viewable in respect to layer 3 (its layer of origin) and layer 2 (i.e. the title block on layer 3 needs to frame the building layout on layer 2). Therefore the ?viewable scope? relative to the current active layer means that the title block objects should extend through 2 layers i.e. the layer of object origin and layer 2 the architectural building layout (the active layer) the title block object therefore would require a ?group viewable layer scope attribute?. Layer 2 on the other hand only needs a viewable to itself (local viewable scope) i.e. it would not be seen if you switched to layer 1 ? the title block layer. Now things get a little tricky, relative to the current active Layer (Layer 2) we may need to see only ?detail a? of the three details resident on layer 1, therefore using new class scope paradigm one would assign a class with the ?group viewable scope attribute? to only ?detail a?, leaving the other details: ?b and c? to having only ?a local viewable scope attribute?; therefore they would only be viewable on the layer of object origin i.e. when layer 3 is the only active layer. This sound very complicated, but in my opinion much less complicated than the current implementation. To make things simple when starting off, all classes would have the default ?the globally viewable scope attribute? and it is only when one wants to mix and match layers and classes that the other scope attributes come into play.

  17. Undoubtedly one of the most powerful and I would suggest one of the most unique software concepts extant within Vectorworks is the ?class?. At first a difficult concept to grasp due to the fact that not many other CAD packages have such software constructs, whereby an object visibility is controlled both by layers and classes settings. Although, an immensely powerful concept, I would suggest that this feature would be the most off-putting feature VW presents to new users. The often heard complaint is - why are whole objects, and in some cases, parts of my objects disappearing on the screen? Another; why is this object on this layer and not on the other? Most AutoCad switchers would be very perplexed when they encountered such situations. These experiences are frustrating and on the surface counter intuitive and therefore are at odds with NNA stated aim to make VW operation and user interface simple, clean, and intuitive. NNA philosophically, I would suggest is not much different to Apple?s who as a company espouses a metaphor which states that in no case should the primary user interface or tool be a reflection of the true complexity of the underlying implementation. Yet I would suggest the class concept breaks with this tradition. I am not saying, however, that class concept is flawed, but rather that the power of this concept needs to refocused towards what users are trying to achieve when using classes. It is important not to overwhelm the beginning user with too much detail; yet, classes seem to do just that. Valuable insights can be gained by simply watching other people attempt to use the class feature, when I did this I realised that classes where somehow missing something, and I now think I know what that ?something? is ? classes need scope. In a programming parlance a variables scope is an identifier which declares what portion of a program to which the variable?s identifier can be referenced or accessed. In many programming languages the scope can be local to the procedure, local to a group of procedures or globally accessible i.e. accessed at any point within the program. My suggestion therefore is to adopt a similar scheme for classes. Within the class definition, which includes such options as setting colour, line-weight, dash style and the like, have a scope identifier option, i.e. let the user decide if the scope of a class. What I understand to be a classes? scope is its visibility in respect to layers with which it is active. A local class's scope setting would mean that the class is only visible within or on a particular layer, or if global preference setting is used, the class would be visible to all layers. The group class scope is where things get tricky - How does one reference layers which may not yet exist? I didn?t say I had the total solution just an idea. What do others think? Maybe this concept needs more fleshing out, or maybe I am the only VW user who has had problems with using classes?

  18. Robert; thank you for your reply,

    Maybe I did not explain my intent with sufficient clarity, so I will try again by giving you a specific example. In building services engineering, each type of reticulated piping system has its particular line style required by Standard. For example; the Standard may require that a reticulated fire sprinkler piping be drawn with line attributes having the colour: red, dash style: continuous and the pen weight: 0.7 mm. To take another example, cold water supply may require the attributes of colour blue, a dash style of ?dash dot dash? and 0.5 pen weight. In order to make the drawing process efficient, before I begin drafting, I usually set up a series of user defined classes each with its particular graphic attributes. In other words, the class definitions hold the line style legend, which is required for each particular type of piping system. In addition, the class dialog tick box is set to "use at creation". Obviously, one can then simply select the correct ?piping system class? and begin drawing a line to represent that system, the attributes of which are set according to Standard legend. This is where VW auto-classing power comes into play and all would agree this is a very efficient way of doing that particular task. The problem of inefficiency arrises; however, when I try to add notes to the particular piping system. Logically those notes pertain to the particular piping system and must therefore be assigned to the same ?piping system class? as those lines and text describe that particular piping system reticulation. The inefficiency becomes apparent when I try to add the text notes. For example add text to say the "SprinklerPipe Class" obviously the text is auto-classed so as to be set to red but I want the text to be set to yellow. No problem I hear you say; each time you put down some text, use the attributes pallet to change the text colour to yellow, i.e. override the auto-class attribute. Unfortunately this process is very inefficient, but maybe if I have to, I could live with that particular inefficiency.. The real inefficiency occurs; however, when using the callout tool. In the particular example that I describe both the text and the leader lines would be auto-classed to a red colour and the leader line set 0.7 mm which is the active class setting. However, 0.7 mm leader line is too thick, no problem you say, just select the text and leader line change to the colour to yellow and then set the leader line weight to 0.25 mm - the required thickness of leader line. If one does, for every time one invokes the callout tool, must reasonable people would agree that this is a very inefficient way of doing things. You suggestion of setting the default attributes won?t overcome this inefficiency as text or the callout tool attributes and leader lines are auto-classing by particular user defined ?piping system class? i.e. the active class. My current work around was to set the ?none class? to be yellow with line weight of 0.25 pen. This strategy overcomes the problem to some degree because the callout tool?s sub-objects are assigned to the ?none class? and thus auto-classed according to the ?none class? attributes. But as you previously pointed out, this then also affects all PIO?s which may be an unwanted artefact of this approach. Hence my request for NNA to incorporate a default text class, in this new regime the standard classes would be none, dimension and text. The text and callout tools would adopt the attributes of the text class by default. An even more powerful way of doing this, in my opinion, would be for NNA to incorporate a new feature whereby each class could have a default text colour, font, size and style and leader line weight these settings would be all part of the class setting dialog. This I believe would give users the ultimate flexibility in this regard.

  19. Hence the need for a new default text class for text related PIO's or the ability to set the default class for text related PIO's. This is very important for speedy 2D drafting. For example, one should simply be able to auto-class the text (colour) and leader (line weight) and arrow head (angle and length) in one action i.e. use the auto-class attributes preference. The only logical place to do this is to setup these attributes in the ?none class? but as you have rightly pointed out this will affect other PIOs on the drawings. What is needed is a way to note up a drawing without having to change the "container class" of the PIO each time. Why? Say one was noting up a building services drawings where each individual service line style is auto-classed (line style, line weight and colour), the notes relating to the particular service should be able to be placed upon the active service class but not automatically be allowed to adopt the attributes of the active class if the sub objects of that PIO were placed in a new default text class this could be accomplished.

  20. How can I change the callout tools default insertion class i.e. the entities ?content class? to something other than "none"? The callout tools PIO properties don?t seem to have a default class option. Is there a work-around? It seems logical to me that the text and leader of the callout tool should be assigned to the active class and be able to adopt the colour and line weight of the active class. I know one can simply change the text and leader by changing its ?container class? but the ?content class? remains as "none". I use the ?none class? for other objects which are auto-classed with a preset pen weight and colour, unfortunately the callout tool is inheriting these ?none class? attributes, this problem should be able to be avoided but how?

  21. Why does one have to have both the "none" class and the user defined class name (the class name on which the callout tool is invoked)active to display the text and leader lines which are created by the callout tool. I thought VW default was to auto-class to active class, in this cas the user defined class name. Is this intentional or a bug? Ia anyone else seeing this?

  • Create New...