Graphic User Interface redistribution

Hi Brian,

Unknown said:

I would like to duplicate a Graphic User Interface (tool bar layout) on all my PC's

The right way is to share dgnlib file with GUI customization. Create your standard GUI customization in dgnlib, share it in your network and set MS_GUIDGNLIBLIST to point to this dgnlib file.

Unknown said:

It would also be nice to make the individual interface for each user available when they move from workstation to workstation.

It's pretty the same as the standardized GUI, only store it in a different file and define the variable in different configuration file.

It can look like:

• MS_GUIDGNLIBLIST > X:\shared\standard_gui.dgnlib, defined in e.g standards.cfg
• MS_GUIDGNLIBLIST > X:\shared\username_gui.dgnlib, defined in a proper user configuration file (.ucf)

The exact solution depends how you workspace is set, your network configuration and also if users use own ucf files or they just login to Windows under different account (or both).

But the general concept is for sure to share dgnlib with GUI customization and a proper MS_GUIDGNLIBLIST (or MS_DGNLIBLIST) definition.

[Edited] There are some other files, that store current GUI configuration (what is docked where), but I am not sure if they can be easily shared without problems.

With regards,

  Jan

Unknown said:

[Edited] There are some other files, that store current GUI configuration (what is docked where), but I am not sure if they can be easily shared without problems.

What about the Config-Vars

MS_USERPREF
MS_USERPREF_APPS
MS_USERPREFSEED

for distributing the "GUI-files" (*docking_xml a. o.)  to a local user directory and pointing this variables to that!

Hi Frank,

of course I know the mentioned variable. By sharing without problems I meant these files are, as far as I know, not intentended to be shared by more users in read/write mode, because simultaneous write can cause problems or even a file corruption. I guess there can be also problems with the docking file if it's shared between computers with substantially different display configuration ... but have had no time and change to test it ;-)

But in general, you are right, these variables can be used to extend GUI customization sharing, at least between different computers for the one user.

With regards,

  Jan

Unknown said:

for distributing the "GUI-files" (*docking_xml a. o.)  to a local user directory and pointing this variables to that!

Is the XML file you refer to the one I can EXPORT from the DGNLIB?

It is possible to move the entire workspace folder to a server and still have the UPF and other files that must stay local, do just that. In fact, it is much harder to migrate those files to a server than it is to move the workspace to a server.

We have the interface and user folders on a server, so if a user sits at a different PC, as long as that PC sees our server based workspace, they can select their user on interface and all of those settings follow them.

What is really nice, is a the support person, I can look at their UCF file and if I see something in there that is not desirable, I can edit them. Or I can start a session with their user and interface to see what they are having issues with.

I also can open a session where I am editing a shared dgnlib that once I add a menu, task or tool, everyone else has access to it when they start their next session.

I use the mslocal.cfg file to get in front of MicroStation, but in it, I test to see if the network location is found and use the local one if it is not. This allows the use of MicroStation even if the user is not connected to the network.

All of these point to folders of my network workspace. Some of these have "companion" variables that add to these paths and since I start with a copy of the local workspace, it finds all of the subfolders too.

_USTN_SITE

_USTN_PROJECT

_USTN_USER

_USTN_USERINTROOT

I also have a no project project, which when selected, is really MicroStation with no local customizations. This lets me test if an issue is workspace related or something else.

Note that the _USTN_HOMEROOT, _USTN_HOMEPREFS and many of the others that use the "Documents and Settings" folders (XP) are left as-is. When we started getting Windows 7 boxes in, I had nothing to change for those to work as well.

Unknown said:

still have the UPF and other files that must stay local

I do not agree in this case, we have a number of customers where we even move the whole user home to a network drive. The only thing that might make problems here, is when you mix up versions, or when the network is poor and often looses connections. The pro's are as you described above, central management, central testing, even central backup, and restore in case of any damage ;-). We rarely need to do the last thing, and in 99% of those cases, we even need to restore the dgn, because the damage was caused by a broken network connection.

The one and only thing I always let stay at the local system is the (workspace\)system folder of the current version, which has different reasons, one of them is speed, another version security (and we often have different (language) versions at one computer)

Nevertheless I would not suggest the thread opener to do such changes by himself, but let someone with enough experience make the first change, and let you show what he/she has done. I've seen to many crashed systems, in best case a simple ('could not find include file") when people play with configs.

Michael

Unknown said:

still have the UPF and other files that must stay local

I do not agree in this case, we have a number of customers where we even move the whole user home to a network drive. The only thing that might make problems here, is when you mix up versions, or when the network is poor and often looses connections. The pro's are as you described above, central management, central testing, even central backup, and restore in case of any damage ;-). We rarely need to do the last thing, and in 99% of those cases, we even need to restore the dgn, because the damage was caused by a broken network connection.

The one and only thing I always let stay at the local system is the (workspace\)system folder of the current version, which has different reasons, one of them is speed, another version security (and we often have different (language) versions at one computer)

Nevertheless I would not suggest the thread opener to do such changes by himself, but let someone with enough experience make the first change, and let you show what he/she has done. I've seen to many crashed systems, in best case a simple ('could not find include file") when people play with configs.

Michael

Michael Stark said:

I do not agree in this case, we have a number of customers where we even move the whole user home to a network drive. The only thing that might make problems here, is when you mix up versions, or when the network is poor and often looses connections.

Mark, it is true that keeping the whole user preferences folder on a centralized network share can make it easier for backup purposes and for accessing your own setting when often logging in on different PCs, but keeping the the .upf on a network can increase the risk of it getting corrupted, for the same reasons you mentioned above, and can cause performance issues too. For these reasons working with a upf file over the network is not advised.

One way around it is to keep the .ucf on a centralized network folder and the upf local. User can easily create their own upf seed from ma new fresh, save in their user folder on the network and and use it as a upf seed, while keeping the "working" upf local. This way you can still backup centrally all user preferences and user can easily re-create their own preferences from that seed after a disaster recovery or simply if their "live" local upf gets corrupted and need to be recreated.

I won't go into more detail on this here as it would become OT for this discussion :) 

A new discussion can be started if this is an area of interest of course.