Most Reilable Method Of Creating Office Tool Palettes On The Network

[Coloradomrg]

Options --> Files --> Support File Search Path

I add each individual file path, I don't know if simply adding the parent folder will work.

[omorah]

On the other machine, I have tried the format of pointing to individual folder on the network.
Don't know what I am missing to do. When I pick the button on the ToolPalette, the block will not insert
from the network.

Thanks.

[Coloradomrg]

Double check the source file in the tool palette button... is it pointed at the network location?

[BlackBox]

Since they're also supported, though I've yet to test for myself, I wonder how much easier it would be to instead utilize the Autoloader mechanism to manage custom Tool Palettes (see the Whitepaper link in my sig), given that Autoloader conditionally 'upgrades' any/all resources used for a given 'app' based on the UpgradeCode XmlAttribute value (GUID) found within said app's PackageContents.xml file...?

[Edit] - Just modify ..\NetLogon\<YourLoginScript>.bat such that when user logs into domain, the network stored 'current' .bundle is XCOPY-ed to overwrite user's %AppData%\Autodesk\ApplicationPlugins\<YourAppName>.bundle, and done. Lemon squeezy.

[aks]

When dragging a block to a tab on a tool palette an xml text entry is made in the tool palette file, which is of course an xml file. The name of the block is an entry and the full path name of the autocad file from which the block was dragged off also becomes an entry. These are two entries out of a bunch of entries that correspond to that palette item. That full path name is hard coded in the palette file. Sometimes is makes sense to keep *.dwg files on the network in a protected area that serve as library files for blocks of various classification. In fact, unless you write your own lisp, VBA or .Net block placing applications, the library file method may be the only way to have dynamic blocks available as pick items on a palette. It is best to plan all the locations ahead of time so that you do not wind up in the situation where the block paths point to the wrong location. You can use an XML editor (Microsofts free XML Notepad 2007) to edit the palette files. I think it has a search and replace feature. The free application, SharpDevelop , I use will edit every file at a folder, and also all enclosed folders if wanted, all at once. In other words use SharpDevelop to replace all the wrong paths with the correct paths. You can have it do 4,000 edits in 10 seconds or so.

When building and editing palettes, it is not always apparent which palette definition file is receiving the edits. If you have three different palette files, say G, E and M, then it is best to maintain individual autocad profiles dedicated for editing each discipline class G, E and M palette. In other words the autocad profile E for E discipline maintenance has a only one palette path defined pointing to the E palette location. That path would point to the network location where only the E palette stuff goes. That is the way you would start off creating the segregated E palette material. That is how you create the tabs knowing for sure that tab is defined in the E palette. Once they are started with tabs and when there are more than one palette paths set in a profile, then any edits to the tabs are stored in the palette file that owns that tab. That fact allows you to copy an item or items from one tab to paste into another tab. By the way, do not use the same tab name in different palette files. You will find out the hard way yourself why not to when it comes time to distinguish one tab from another when organizing palette groups.

That is a method for managing the palette contents. How the palettes appear on a user's machine is stored locally for each user. This includes palette groups. Palette groups are palette tab visibility settings. An organized method for handling palette groups is to create the various palette file group setting within the discipline maintenance profile. Then export that group definition to the network folder that holds that palette. These can be used later to pull in the groups. Do that for each palette. Depending on the palette content it may be that it does not make sense to segregate the group settings. But what you do want to do is create one master group file that contains all the other group definitions you have created. The easy way to do this is to start with no palette groups, i.e. first delete all, and then import each of the network saved segregated groups. The result will be all groups being defined. Export this all groups setting on the network at the level where the separate palette file start to branch. The way to set (and reset) a user's palette group setting, assuming of course all the palettes are loaded by having all the paths set in the profile, is to first set the tool palette to show all palettes. Then invoke the customize palettes command. Then delete all the current palette groups. If the palette was not set to show all palettes as mentioned, then you will not be able to delete the group for the active palette. Then import the network saved groups file. After closing out you may notice all or some palette tabs do not have their visual setting the desired way. That is because that preference is saved in the local profile and the local profile may not know about that tab yet. The profile does this by remembering the tab GUID, which is one of the XML entries for a tab. Once you set the visual setting and once you set whatever group you want to see, that setting is remembered as part of the local workspace. Therefore you'll need to set the correct active palette group for each workspace if there are a number of different workspaces defined and if each workspace expects to see a different palette group showing.

Once a palette has been on a machine its tabs and item locations (order in the tab) are remembered in the AutoCAD registry forever until that is wiped clean. Therefore you cannot control the tab item order. All new tab items will appear at the tab bottom. The user must reposition the item. Restarting AutoCAD to see or have new palette edits is not necessary. Switching out of the current profile to another profile and then switching back will force AutoCAD to reload the changed palette.

[Revit MEP DR]

So along the same lines of this thread.....I am using AutoCAD 2014 and have created and distributed a standard set of tool palettes. After the palettes are loaded into Content Browser, and a user installs the TP, they do not have permissions to edit the dimscale, and rotate upon insertion properties. I normally agree with this behavior as the CAD Manager should be the one to manage these settings. However, I am changing jobs, and need to relinquish my control over the TPs. I had thought it was managed through my windows login, but has been proven mistaken. Any suggestions? I appears to be tied to my local installation of AutoCAD.

[Opie]

If the tool palettes are located on the network, then it would be a permissions issue. I have a specific security group assigned for CAD Administrators. This way, when a need to change members of this group ever arises, then it is a IT issue to assign the appropriate group to the right people.

[jasonp]

Tool palettes, when imported to ACAD have a guid associated with them. This GUID links to the machine that built them and some other stuff as far as I can figure out, and if you're using any vertical product, (i.e. MEP) and have them in a catalog, if you loose the source palette, you can't modify the shared ones anymore. The vertical products supporting catalogs doesn't function like the help files say, there's no "Import/Export" option on palettes like there is in Vanilla ACAD, you simply drag the whole entire palette to the catalog and it images it.

[dkoch]

Tool palettes, when imported to ACAD have a guid associated with them. This GUID links to the machine that built them and some other stuff as far as I can figure out, and if you're using any vertical product, (i.e. MEP) and have them in a catalog, if you loose the source palette, you can't modify the shared ones anymore. The vertical products supporting catalogs doesn't function like the help files say, there's no "Import/Export" option on palettes like there is in Vanilla ACAD, you simply drag the whole entire palette to the catalog and it images it.

If you are using the Content Browser in AutoCAD Architecture or AutoCAD MEP to share tool palettes, once the original palette is placed in the catalog, the "original" is in the catalog. In the Properties of each catalog, there is a toggle where you indicate whether or not items added from that catalog should be linked back to the catalog. If checked, then if you add a palette from the catalog via iDrop, that palette is refreshable from the catalog, and changes made to the tools in that palette can be made available in a linked workspace copy via the refresh button in the lower corner of the palette, on the "tab" side. You can also set the workspace copy of the palette to auto-refresh, so that it refreshes each time the program starts, but that can slow opening the program.

Each palette does have a GUID associated with it, so that ACA/AMEP can keep track of which palette in the workspace belongs with which palette in the catalog. (You can have multiple palettes with the same displayed name - the GUID provides a unique identity.) Updating a tool palette that is refreshed has to keep that in mind. You cannot delete an old palette from a catalog and replace it with a new one of the same name - the GUID will be different, and the refreshability of the "old" palettes in the individual workspaces will be broken. Instead, a user with write privledges to the folder where the catalog file is saved and who has a refreshable version of the palette in her/his workspace need to edit the properties of the palette and temporarily uncheck the Refresh from toggle and then select OK. This will allow that user to make changes to the palette: add tools, delete tools, edit the properties of existing tools. For the latter, you may need to clear the Refresh from toggle in the tool properties as well. When all changes are made (and without rechecking any of the unchecked Refresh from toggles), that person needs to drag the edited palette back to the same location in the same catalog. An alert dialog asking if the existing version should be replaced should appear - this is a good thing, and (assuming the changes are desired) the response should be to replace. If no such alert dialog appears (if you have the catalog set to "Always on Top" - minimize the catalog to see if it is hiding below the catalog), and a second palette of the same name is created, then something went wrong and ACA/AMEP did not consider the edited palette as being refreshed from that source.

If the alert dialog appears and the existing palette is replaced, the person making the update can then recheck any Refresh from toggles. This will trigger a refresh (which is why you have to copy the palette to the catalog before you recheck the toggles), and the palette can be inspected to verify the changes made are effective.