How to get the command line to stay docked after a civil3d session?

[JamesMaeding]

I have icons for both acad and civil3d, with /p switches so each has a different profile.

I always dock the command line.

I am seeing that every acad session after a civil3d one will undock the command line.

Happens on versions 2015 to 2019 at least.

Ya, it takes 4 seconds to dock it, but I have 100 users dealing with it.

Is anyone else noticing this?

I have all the automatic workspace stuff off, and no workspace switches in icon. Lets just say I have shut down everything related to workspaces, as they have never been stable.

Anyone suggesting I leave the command line undocked will be cursed with tendencies to forget where you parked you car after work, for 7 years!

[Alfred.NESWADBA]

Hi,

>> Is anyone else noticing this?

Sorry, no.

I run AutoCAD and Civil 3D mixed (never parallel), I always have the command line docked, and it never starts undocked, independent of which product I start.

- alfred -

[pendean]

For 99.99% of us:
Dock it.
Save your workspace.
it never moves until someone does so deliberately.

Since you seem to never touch your workspace(s), that's probably the culprit.

[JamesMaeding]

@Alfred.NESWADBA

thanks for feedback. Do each of those sessions use different main menu?

If you have followed CUI use through the years, the acad side says to use custiom.cui as main, then partial load acad and others.

The Civil3d team says to use c3d menu as main, which means you will be modifying the OOTB menu with workspaces and anything you edit. That is not workable in an office with 100 people, as you cannot update the c3d menu if needed, which I do need to about every 6 months as bugs are dealt with or changes are needed.

Anyway, we use one menu as main for both sessions - custom.cui - so whatever partials a user typically likes, gets loaded into each. Then we load vertical menus with enterprise menu, as that is per session.

I have a feeling there is a bug with doing that. The acad and c3d teams never coordinate on menu issues, so we get these problems.

[Alfred.NESWADBA]

Hi,

>> Do each of those sessions use different main menu?

Definitely yes, I always have well separated product configurations.

The main menu's/CUIX are always the original CUIX that are loaded with the product (ACAD.CUIX for AutoCAD, C3D.CUIX for Civil 3D) without any migration.

For applications (which need menus) their CUIX are only loaded as partial menus.

HTH, - alfred -

[JamesMaeding]

@Alfred.NESWADBA

Do you see that using acad or c3d menus as main is a difficult method for companies with multiple users though?

If I discover anything needing a tweak, I cannot send a new acad or c3d menu to all users, it would wipe out their workspaces and any custom things they did.

That was the whole (and good) idea of making custom.cui as the main.

At my place, the OOTB menus are controlled, and copied from a server every login if different.

The users love this, as I can fix something like a badly changed mnemonic by adesk back to how a previous version had it. There are many things that come up and the freedom to fix is critical.

Not asking anyone to change or say anything is wrong, just explaining the advantage of using custom.cui as main for all sessions.

[Alfred.NESWADBA]

Hi,

>> Do you see that using acad or c3d menus as main is a difficult

>> method for companies with multiple users though?

Not really, but our customers by default don't change between products. The users working on Civil projects (or GIS-projects in case Map3D is not available) always start Civil 3D, the ones only needing AutoCAD always start AutoCAD.

That means for a network setup package we usually create a setup for AutoCAD, a separate setup for Civil 3D ... on one test workstation. There we create a default profile and workspace (including the applications for the users loaded by plugin technology or partial menu loading) ... and from that setting we start with creating the setup package.

In a few cases (depending on customers) we have a script (login script by Windows Domain users) which updates partial menus, tools or applications, PC3/PMP/CTB/STB on the local system from a central (admin controlled) network path.

- alfred -

[JamesMaeding]

@pendean

By golly, that is currently working in 2018.

I think I have tried that before, as its the obvious thing to try, and then it stops working at some point.

Its not a bad workaround though, to just re-dock cmd line and re-save the workspace.

I'll see how long it holds. You get a like at least!

[JamesMaeding]

@Alfred.NESWADBA

If you never have had to change the acad or c3d menu for multiple users, I can imagine you would not care if its the main. I might also suspect that the reason you don't ever tweak their menus is you effectively cannot if its the main.

My company refines and improves too much to not have that ability.

Some of my buddies at other companies ask if we customize too much. My answer is yes, and we make too much money off it.

[cadffm]

You will see how long it holds?
Pendean answered this questions also:

"it never moves until someone does so deliberately.

[JamesMaeding]

@cadffm

Right, if I don't modify anything for a while, lets see what happens.

Some workspace issue happen immediately, then some seem to take a while.

So far, I'm hearing people with simpler environments have no issues.

Before the CUI system, I think ver 2006, the menu system of one main, and then others loaded BY THE PROFILE, not daisy chained to the main, was far superior. They should have kept that and added ribbon and whatever.

Anyway, until someone can explain why the command line detaches, this remains truly unresolved, but easy to work around I guess.

[cadffm]

I would say: The question WHY is solved (User, in what kind ever), until you see it with your own eyes.
Docked command line, save Workspace,
close Acad
*whatever*
Re-Open Acad without or the right /workspace switch
Commandline is undocked..
Then i would start searching.

Why do you mean there is a problem without user action?
Or better: When commandline is undocked,
is the saved workspace changed too or is the workspace commandline properties are still right?
If undocked and you set the workspace current again, is the commandline docked or not?

Provided the automatic saving of the workspace is disabled.

Tomorrow i will see what is also possible as source of this.

[cadffm]

if I remember correctly, away from acad, I have the undock- problem in combination with clearscreen (ctrl + 0) fir example.
We will see, tomorrow.

[JamesMaeding]

@cadffm

I would say the why is not solved.

If the command line is docked, it should stay that way whether I save a workspace or not.

The command line undocking does indeed happen on its own, though like I said its behaving for the moment for me.

If I was using /W in startup icon, that would be different, but we are not.

The point of my thread was to see if this was common or not, and its apparently not.

The comment by @pendean was a bonus, as its an easy enough workaround.

I really have not done the troubleshooting I should to narrow the issue down.

We have some good people participating in the forum these days, but a lot of the crowd I would like to read this does not hang out too much anymore.

[JamesMaeding]

I think I just figured out the issue.

I was starting 2018 and 2019 back and forth for unrelated reasons, and noticed 2018 always had its command line undocked after 2019.

I tried docking the command line in 2018, and it did not want to dock.

I went to pick something in windows taskbar, and it was below the acad 2018 window.

I unmaxed acad window, then remaxed and it properly, the was able to doc the command line.

So there is some defect in how 2018 and maybe 2019 starts up. Its not full screen, I think, but bigger than it should be and that freaks out the command line. I'm running common dell hardware, though I do have 3 monitors not all the same size. No 4k, and no font scaling going on.

There is no workaround for this, its just bad behavior.

[rkmcswain]

@cadffm wrote
@pendean answered this questions also:

"it never moves until someone does so deliberately.

Except that isn't true. I have a user right now who docks the command line, shuts down Civil 3D, restarts it (same icon, same profile), and the command line comes back as a single line floating palette. Every. Time.

Tried adjusting the settings in the CUI, tried LOCKUI, reviewed the data in the XML file (Profile.aws) - everything appears to be set right. This is a brand new install of C3D 2018 on a brand new PC. 

The real question here is "What does AutoCAD use to position the palettes at startup?" The data in "Profile.aws"? The data in the CUI (workspace)? And what variables could affect this? Such as the things  @JamesMaeding  says above.  This _is_ computer science. There is an answer to this madness. Things just don't randomly happen in computing. There are instructions somewhere that are being followed. If these sort of things were published, we could all quit guessing and solve this and issues like this with real answers.

[bryan]

This will fix the command line if it is caused by switching monitors or resolutions.

Shrink your undocked command line to a narrow width.

Do not dock it.

Close Civil 3D.

Reopen Civil 3D.

It should return to docked. (or be able to be docked and stay.)

Any other versions of Civil 3D installed will also be fixed. (Weird).

[JamesMaeding]

@bryan 

That's not the subject though. We are talking about things all settled, and not remembering their dock state. This issue seems to still happen on at least 2019.

If you are changing resolutions or monitors, that is like turning the world upside down to acad so many more problems than this 🙂

[bryan]

This is about the command line not staying docked. The user unhooked from his workstation monitor and was working remotely with just his laptop screen. His command line was docked when he was working remotely. When he returned to the office and hooked his laptop up to an external monitor, the command line was floating. He docked it and closed Civil 3D. When he opened Civil 3D back up it was floating again. Dock, close, open, floating, dock, close, open, floating, ad infinitum.

I thought this might be due to his switching monitor setups (as that can screw up palette location and the like) and had him narrow down his floating command line to see if the location where it opened made a difference. We closed Civil 3D with the narrowed command line thinking the command line was sure to open if it was in a location on the monitors that existed when he was working remotely and the next time we opened Civil 3D it was docked. We opened and closed multiple times and every time after that it stayed docked.

This may not be a solution for all instances of palettes not retaining their position or docked state, but it was a solution in this case and it works.

[JamesMaeding]

@bryan 

Well, that is called hijacking a thread when you change the issue being addressed.

Trust me, I do it more than you 🙂

All along, we are talking about same monitors and so on, nothing changing in that regard.

So while your solution might help you, its not related to what I am reporting on.

I get that a lot when threads are long, and someone jumps in way after the discussion.

The end result is people in future think "hey, its solved" because someone solved the wrong thing. No worries, but the original issue is still unresolved.