Will using "toolbars" effect the way Civil 3D works ?

[Anonymous]

I have been using AutoCad for a very long time. Years back I created/wrote a "ton" of toolbars. I still like using them, but I am getting some flack that they are causing Civil 3D not to work properly. I have also created/wrote an additional toolbar that has Civil 3D commands within it & it works great. Has anyone had issues with using toolbars instead of using the ribbon commands ?

Thanks, 

David

[J.S.H.]

No, I believe they work similar to the ribbon commands, and have not seen or heard of any issues. Unless you are having an issue with it, I wouldn't worry to much about them, do what works.

[Kevin.Spear]

Starting commands from the ribbon or a toolbar will probably not cause an issue. But you will need the ribbon visible as various tools use it (section editor, pre-selecting object contextual tab, etc.).

[Anonymous]

I shouldn't, as long as the commands are still loaded in the CUI.

[Anonymous]

There's a younger guy in my office that has several of the upper management convinced that the "toolbars" are causing issues that make Autocad crash. I'm not the only one that has drawings crash, but they do especially as I am using feature lines to build proposed surfaces. I've been using the toolbars since I started with the company & also use the ribbon, pull downs, etc.  Just cannot seem to get my thoughts thru that toolbars just don't seem to be the cause ???

Thanks

[Kevin.Spear]

You may need to work in the default workspace to prove your point.

[Anonymous]

What do you mean? Detach my toolbars & not use them ?

[Kevin.Spear]

Don’t use your custom workspace. Use the default civil 3D workspace.

[Anonymous]

I am using the civil 3d workspace. 

[copper.chadwick]

@Anonymous,

Welcome to the Civil 3D forums, your post on "...toolbars effect the way Civil 3D works"; customization of the User Interface or 'UI'/'UX' is a really great candidate for further discussion. I wanted to chime in on this from a support perspective.

In short there is a conditional answer to your question, "yes" and "no" depending on how/ what your toolbars are referencing and how you have attributed their existence. The conditionals I speak of refer, in part, and are not inclusive to the gross affected behavior.

Yes -

• If your Autodesk Profile is altered it can cause corruption, and change the behavior of the software.
• If your Autodesk Installation is altered, it can cause corruption, and change the behavior of the software.
• If the operations "scripted" within the macros of the toolbars no longer exist or the system variables have changed since the version they were written for.
• If the macros refer to changing system variables that would create issues within the CUI file.
• If the scripts called, are not referencing the correct modules of the software to be used.
• If the CUI has been modified to not load the tool palette or ribbons, as those modules would need to be present for the software to work, regardless.
• If you have modified the stock Civil 3D Workspaces. (See corrupt profile)

No - 

• If the factory version / installation has not been altered in any manner (truly compartmentalize the customization).

Different iterations of AutoCAD verticals (Civil 3D 2016 vs Civil 3D 2018) , change operational characteristics and can change the behavior of macros inside of toolbars in certain cases, and lastly, profile corruption is a big cause of anomalous software behavior. So, I am really writing this reply to give reinforcement to the things @Kevin.Spear and @Anonymous had said. I do not personally recommend customization for a couple reasons:

• Technical support cannot help if they cannot reproduce the issue due to customization.
• You're entitle to technical support if you have a subscription, etc. but it will have to be facilitated through "Out-of-the-box" behavior and User Interface, not on systems that have been customized.
• Customization can and often does cause the software to malfunction. ( I expect the have rotten vegetables thrown at me here) 
• Knowing the workflow of the factory version, means that the billable hours lost can be minimized, by getting the factory image reinstalled very quickly and getting the user back to production should something have changed in the user profile (generally, only happens when customizing or non iterative updates hot-fixes are applied).

I used to make all sort of customized toolbars and write AutoLisp routines, and they can save a great deal of time in making drawing objects. I spent a great deal of time on creating the customization to make for a efficient user environment, and I never had anything really go wrong with my customization, but that is not always the case.

I hope that I have helped, at least guide a hand in a gentle fashion about why customization would be carefully considered and implemented. Your co-worker is correct, and so are you, with arguments/ conditionals on both sides of the debate, but, if technical support is needed the customized parts of the software will need to be returned to the factory styling, and as @Kevin.Spear said, the factory workspace or a profile cleanup should be tried first in order to isolate the anomalous behavior. In the end, @J.S.H., is also correct, "Do what works" really is the best way for each user.