LarryO

A few things you may notice when migrating to VW on the Win10 from MacOS is text input functionality. 1. With caps lock on, holding shift key will drop to lower case for the western alphabet on Win10. 2. Keyboard sequences for entering certain accents, Greek and mathematical characters are now relegated to "Alt" based index calls to the active font table. 3. Win10 has not licensed complete fonts sets like the MacOS. So in Ariel font for instance you cannot call up the checkmark and others. Finding pi can be difficult etc. 4. After changing a class or entering a value into a text field via the info palette control is not transferred back to the main drawing window. This blocks the single character shortcut keys. So you will frequently find yourself having to press escape or clicking on the drawing window before you can initiate another tool or function via the keyboard. 5. Many keyboards developed for Win10 have extra keys between the control and alt keys that get in the way of one handed shortcuts. Those with smaller fingers can experience painful stretching exercises to active certain sequences. I am always hitting the contextual menu button with my left hand's thumb when trying to group or ungroup items. VW may not respond quickly enough to shut down requests from the WinOS resulting in stalled shut downs. My switch over to PC from a similar arrangement MacPro circa 2011 as yours resulted in greatly improved rendering times and screen redraws of 3d and pdf objects. No more having to go get a coffee while waiting for viewports to regenerate. I occasionally get artifacts in the printing process that are not there on screen like a diagonal line across the face of a rectangular steel tubing. We have been purchasing HP Z8 workstations with Xeon processors. This is not to say that these are better than other product configurations though. They were simply recommended by an IT consultant of business systems that we hired who installs and resells HP and Microsoft systems.

There was a time back in the late 90's early 21st century that MiniCad/Vectorworks would respond to the AppleEvent "Do Script" among others. With the development of the Windows version of VW's was/is there a similar means to send and do a script sent from another application? Will this continue in light of the deprecation of Apple Events in newer Macintosh operating systems? I was able to trigger menu items using AutoHotKey on the Windows platform but one had to make all the scripts part of the active VW menu. In both PC & Mac I utilized the function keys to trigger or send scripts that set multiple attributes and introduce office standard classes into imported files. We referred to them as Pen keys because it was like switching drawing pens (when no objects were selected).

I find that VW prevents the operating system from shutting down by not responding to the system request. I also find that closing down VW in general will frequently trigger the application is not responding notice before eventually closing. I'm running this on a new HP Z4 Xeon workstation. I'm also experiencing many more crash to desktop incidents than I ever had on the old (and slower 3d regen) Mac, plus occasional screen flashes to black when regenerating viewports showing 3d objects in OpenGL mode.

Is it normal on the Win10 platform to always be using the escape key to leave the attribute palette and the object info palette before one can use the 'X' shortcut to cancel the active function and return to the pick cursor? This was not the case on my old Mac platform. I am becoming very frustrated after editing the last object I created and then pressing X or another single key shortcut, that when I go to select or create something new I find that the previous function (lines, dimensions, circles, etc.) is still active.

This could be a paired plugin exercise with a placement script in Vectorscript. The plugin on one sheet would know the name of the plugin on the other sheet and vise a versa. The plugin itself could store the name/number of the sheet upon which it resides for the other to extract or the plugin could simply search for the parent of the of the other named plugin and extract the name/number from the parental sheet. When dropping one of these plugins on a sheet via a placement script, the script could automatically drop another plugin on the sister sheet that the user selects at that time. They would need to be event enabled to update whenever printing occurs and have a manual means to trigger the plugin to be executed for other situations.

hehehe, that is almost funny.

Yes, but is that a virtual core at 100% and the physical core only running at 50% capacity? I which case is it possible to acquire the whole processing power of a physical core (25% of the CPU) by disabling virtual core pairing to each processor?

Has anyone investigated if it is possible to disable hyper-threading? I have this higher end Xeon processor with 4 cores each split into 2 threads. This results in only 12.5% of the overall CPU processing power being available to do everyday basic hidden line rendering. I was thinking that if hyper-threading could be disabled then maybe a whole core would become available to do work. Getting 25% of our computer expenditure working for us! And then I wouldn't have time to write these posts and speculate on how to get VW2019 operating faster. Smile.

The concept of making changes and not keeping track of all the viewports that are affected is like cooking dinner and leaving the pots and pans for someone else to clean up after you. The technique of drawing, doing annotaion and page layout in the design space is the old school technique that was required prior to the introduction of sheets and viewports into drawing applications. the old school method often had the technician redrawing information multiple times; once for each level of detail required. Building plans often did not jive with room plans which did not jive with envelope details because when ever one was changed the others would not get updated "for efficiency and speed reasons". Moving annotation and dimensioning to the viewport annotation results in fewer instances of unreadable blobs of text that were not intended for 1:100 drawings and cut-off witness lines not intended for the detail views and giant sized grid bubbles, etc. all related to differences in scale between the design space and the layout sheet or viewport's scale. When developing a drawing in the design environment the notes and references I place there are not usually intended for the construction drawings. They are site measures, design constraints, source references (CCNs SIs details, email instructions etc.) These annotations are grouped into their own classes and are rarely turned on in the viewports. Details can be laid out over building plans and sections at their relevant locations and simply grouped or symbolized with a class attached to control their visibility. If you are using viewports and switching things around on the fly you are still going to need to go through all the relevant viewports and realign them, so there really is no excuse for forgetting to realign the annotation and dimensions too when you move the crop. There is no one true way of doing these things but some methods just make it more difficult for the junior drafters to keep your drawings error free after you adjust them. After all that is what office standards are really about. I think that was more like ten cents than two.

1. If you do any rendering of 3d objects what so ever you will need the machine that has an independent GPU with some dedicated video memory. Even wireframe only files (no walls, slabs, roofs or other 3d objects) benefit from an independent GPU because the responsiveness of the mouse, zooming and snap point selection can be sluggish without one. (Will the installer even proceed to install VW2019 without one?) 2. Launch, load and save times improve noticeably with SSDs and faster processors.

With hatches you can go to the resources palette and without any objects selected in the drawing environment right click to bring up the contextual and select apply. Henceforth that would become the hatch that would first appear when you switch from one of the other setting like solid or none to hatch. For some reason this doesn't seem to work for linetypes. At least not on the PC version of VW2013, but what does work is at the beginning of a project or when setting up an office template you draw your line. Leave it selected and change it to dashed, then change the dash style to the one you wish to be the default. Open the resources palette and delete the linetype that first appeared leaving only the one you intend to be the default. Now you can add any number of additional linetypes including the one just deleted and the intended default will "stick". At least until it is deleted from the file. I believe ISO-02 becomes the default dash type due to alphabetical sorting of the linetypes in the library file that comes with VW and is typically buried in a system folder. That library file is what gives you linetypes to choose from when there are none embedded in you working file.

This is from rusty memory of when I was working with both platforms, over seven years ago. When having trouble with curved shapes, you can start by exporting the objects from a clean file. A clean file has no drawing objects, symbols, hatches, linestyles, etc; it has been purged of everything that the purge command will remove. The only layer should be renamed 0 (that's zero). Set the units to inches or millimeters as applicable and scale at 1:1. Accuracy should be set to at least six decimal places for imperial units. If accuracy is set too low there is the potential for division by zero errors resulting in points that fly off into Autocad outer space. Make sure your polyline has a width other than zero. Copy your object(s) from a working file and paste into clean file. Export to DWG Autocad version 14 or 12. Then check the result by importing back into another clean file. See if your polyline has retained it's curve points or were they converted to other points. There used to be one type of curve that was not supported by Autocad. The translation process would approximate the curve using other types of points, usually hundreds of straight line segments. You might also include a straight line for the rotation axis (or two loci). Autocad supports solids. You should be able to do the sweep yourself and have it export cleanly. You may have to give the final object a solid fill.

I didn't realize that it was even possible to completely collapse all the columns. Thank you Thank you Thank you How it got that way doesn't matter now that I know that it's possible and the technique to return them to normal.

Just a stab in the dark here, but have you tried ReDraw or ReDrawAll? Or applying attributes to the rectangle before ending the floor statement (and then to the parent floor as you do already)?

And another but the layers tab, only showing a column of storys

Here take a look. not much to see anymore though.

What do users of the PC (Win10) version of VWs use to insert a Carriage Return/Line Feed into a field box of the OI palette? On the Mac I was using I could simply write my text using the text command and create a second line with the return key, copy into the clip board my two rows of text complete with the invisible CR/LF control character and paste it into one of the detail tag's title field and two rows of my text would appear above the tag's horizontal line. But all that emerges when I paste on the PC is the characters before the CR/LF; everything afterwards is missing. Existing tags with two lines of text created on the Mac display on the PC correctly and you can edit the regular characters either side of the CR/LF but you cannot paste the sequence of visible and hidden characters into another detail tag. Also noted that the info palette doesn't do a CR/LF in the field box on the PC whereas the MAC does.

Does anyone know if there are run-time/visual basic/c+libraries or something similar required for the Navigation palette to operate? The Navigation palette in my Win10 PC installation of VW2013 has stopped displaying the classes and layers of the open document. I'm wondering if an update pushed from Microsoft or Steam has removed or changed a required piece of software that supported the palette's functionality.

Excuse my ignorance if what I'm about to write doesn't apply to DLVPs, I don't (Xref) reference in outside documents/layers in my VW's work. Now what I was thinking is that the technique of group, copy, link/turn on layers (see below) may work in a similar fashion with DLVPs but by linking the original file's layer into the DLVPs that have been copied over to a layer in the new file. You could then un-reference them as suggested by Tamsin and copy the result back to where you need it. You probably need to save the new file at one point and revert to saved before unlinking the referenced layer(s). This would allow VW to properly load the DLVP data and links before attempting to 'explode' it. I'm still not sure that this un-referencing Tamsin has suggested will actually create what you are seeking. Yes it should bring in all the geometry into the new file on a layer but I think you were wanting to create an instance(copy) of the geometry but only that which is showing in the cropped area in lieu of the viewport at the viewport's location. There maybe a technique/command for that process too but I'm not familiar with it. Technique: With regular viewports on sheets the application generally prevents one from copying them to another file by popping up a message whenever one trys to do so. But if you take a blank file or existing one that has the same class structure(colour/LW/etc), you select the viewport(s) and group them. Copy to clip board. Paste in place in the new file on a sheet. Ungroup, copy over the line work from the original layer(s) and paste them in place on layers in the new file, edit the viewport layers to turn on the respective layers. They should now be showing evrything as before but in the new file. Now the important step. Save the file and then revert to saved before doing further editing using the viewports interface to access design layers.

Update: The issue with snapping doesn't seem to be file specific. Viewports on the same can be responding normally while others will not snap to points. This morning the problem I had yesterday in one viewport went away and showed up in another. Shut down the application and relaunch and all viewports with snapping failures are now responding normally, until they don't again.

That CadMouse does seem to be an improvement over my favorite, Razer's Death Adder (not wireless). I've had days where my scroll wheel finger has gotten muscle stress from pushing down and holding that button too much, which I lay blame on Adobe's Acrobat products and their panning technique. I've only worn out one Razer mouse in over five years. Possibly too much dirt or film build up inside made for unresponsive movements and jumpy scroll wheel. Oddly enough the worn out one continues to function when used with a mouse pad.

Does anyone else experience this problem. I cannot seem to get dimensions or lines to snap to any points associated with objects that have been grouped. Specifically the group of objects are on a normal layer and I am attempting to dimension to them while working within a viewport's annotation environment. I'm thinking that it must be some sort of setting that I'm overlooking because I cannot replicate it this evening on VW2013 here at home. This was happening to me on VW2019 at work. Both are Win10. While I'm here what could cause the navigation palette to stop showing the document's classes and layers? VW2013-Architect, Win10

Thanks @Jeremy Best, I'd forgotten about that extra functionality of preview. Unfortunately only a very small proportion of the pdfs we receive have their layer data exported. Whereas with a nice crisp image I can erase to my heart's content any undesirable content in a paint or Photoshop program. Acrobat has been a sort of nemesis of mine for years. I don't imagine I'm alone in saying that I can rarely recall how to locate and change various settings for the tools without google searching. Calling it an intuitive interface would be giving it praise from my experiences using it. hehe. Alas I handed off my 8 year old mac just last week to the junior draftsman in favor of an HP with a graphics processor that doesn't bog down regenerating views of 3d canopies.

This is a classic case for BIM integration. The information / data that everyone is referring to is stored in a record attached to the building object (in this case a door) not the display object (a tag). The BIM data can then be accessible to worksheets and any variety of customizable tags (a plugin object which incorporates a user defined symbol with linked text and transfers data from the building object's record to the display object's record of fields). One possibility is: the user creates their own page based symbol laying out the tag with text, linking each text to a field in an attached record. The symbols' field names match the field names contained within the record attached to the door object. If you don't want a particular piece of data in your custom tag you don't include that field name in your symbol's record. The tag creator also includes two additional fields in their symbol's record, one which utilizes a pre-defined (field) name that the Placement Tool identifies with which contains the name of the record or plugin object the Placement Tool would search for in the object ('door-record') you attempt to associate the tag with. And a second field which stores the unique 'serial' number of the door object (in this scenario). This serial number is essentially a permanent handle which is created and stored in a door object as part of the BIM information. The Placement Tool would request the user to select the desired tag from a tag list which the tool has created by searching the symbol library for symbols containing the pre-defined field name. The user would then attempt to select the object (a door) to link their tag to and then click where they want the tag placed. Any number of tags can be placed where ever the user desires and they link to the unique door instance. Update that instance and all tags linked to it have the ability to refresh their information. An alternate function of the Placement Tool could be to select the object (a door/a window/a cabinet) and the Placement Tool would then place the selected tag at every instance of the object which appears upon the layer which the selected object resides at the origin of each instance object. The challenge I see is ensuring that whenever a door object gets created, duplicated or pasted that it checks for the preexistence of its serial number and changes itself to be unique. And whenever a referenced object is deleted that the tag(s) linked to it realize their source is missing and delete themselves too. Actually I guess it would be the plugin instance which generates the symbol and loads it with data from the object that would have to store the serial number of said object; not the symbol object's record because the symbol gets reinserted and regenerated with each refresh of the plugin. The Placement Tool would set the initial serial number data into record of the instance of the tag controlling plugin. This is similar to a titleblock plugin I created that utilizes a page based symbol for layout and a special instance of itself for maintaining the same project name, client name, and project number through out a file. The plugin looks through all instances of itself for the flag that identifies the special primary instance to copy data from. If it doesn't find one it checks what sheet of layer it has been placed upon and compares it to a string contained in its script's definition. If the string matches the sheet name it changes its own flag to identify itself as the primary titleblock and makes those three fields visible for editing in the info palette. It works pretty slick because if you copy another primary titleblock into a file with an existing primary the regen process allows the script to turn off the flag of the instance being copied in and if the copied instance doesn't find an existing primary it is going to check if conditions are right to make itself the primary which retains the data brought over from the other file. But first Nemetschek is going to have to fix the scaling bug associated with page based symbols that are outside of the viewport being edited. When there is an instance of a plugin which is placing a page based symbol on a sheet and you are in annotation edit mode of a viewport also on that same sheet that symbol instance gets rescaled to the viewport's scale instead of maintaining the scale of the environment in which it is placed. It would drive one bonkers if there were more than one or two instances of the plugin on the sheet with all those useless snap points of the symbol instance potentially behind the view port you are attempting to add annotation to.

That is a shame. The pdf image before ungrouping is so much crisper and defined than the bmp created from it. I imagine there are other tools outside of VW that can create a quality raster image to permit editing out of extraneous data from a background plan.