Thanks for the input. Looks like I've got some work ahead of me...
On 12/11/2009 9:23 AM, Doug Bowers wrote:
> I'm not Matt, but we endured the bad karakoe together at the final AU party
> last Thursday.
🙂 That was the lamest AU party I have been at in the 14
> years I have been going to AU.
>
> Anyway...
>
> You do need to rely on the users to pick the refresh button to update their
> palettes, but I found that sending users an e-mail notifying them do it
> worked very well. Once your get the palettes set up, they really don't
> change very often. When I did update a palette, I just e-mailed users and
> asked them to update the appropriate palette by picking the refresh button.
> It was never an issue for us.
>
> Do NOT have the palettes set to auto-refresh! That makes the palettes
> refresh every time you open AutoCAD Architecture. While that sounds like a
> good idea, it can make it take several minutes to open AutoCAD Architecture,
> depending on the number of palettes you have.
>
> Another thing to consider in the speed of using palettes is where styles are
> stored, which you note right off. When you pick on a style tool on the
> palette (such as a wall tool), the speed at which the tool is executed will
> be affected by the size of the drawing where the style is stored. If you
> put all of your custom styles in one master drawing file, it will take
> longer to execute the tool that pulls the style from the master drawing. it
> is better to make a few different master style files to store your custom
> styles if you have very many. Notice how Autodesk has divided up their
> styles, especially having multiple wall style files. This can really make a
> huge difference in tool execution time.
>
> As you can tell from my posts on this, my preference for using palettes is
> to use them with the Content Browser.
>
> Doug
> www.dougbowersconsulting.com
> blog: http://aectechtalk.wordpress.com
>
>
>
> "Anthony Mason"
wrote in message
> news:6303566@discussion.autodesk.com...
> Thank you for that information, Matt. Our tools are horribly slow to
> execute. I thought it had to do with the fact that all our content is
> in a single style template drawing (which I plan on splitting out when I
> get the time). This post is the most compelling thing I've read to
> persuade me to go back to the Content Browser system. The drawback I
> still see is that you have to rely on the user to keep it updated, or do
> it yourself at each station. Is it truly as simple as clicking the
> refresh button, or do users need to often drag in content from the CB?
>
> On 12/10/2009 8:04 AM, Matt Stachoni wrote:
>
>> The issues I have with centralizing Palettes on a locked down folder is
>> that the
>>
>> Tool System is based on XML (which is slow enough as it stands now), and
>> each
>> Palette file is open, read and edited many times during a drawing
>> session - even
>> when no changes are made. Having ACA constantly hit that server resource
>> and be
>> denied from writing to those files is just additional overhead and can
>> generate
>> redundant and possibly confusing error messages.
>>
>>
>
>> You can easily do this by SHIFT+R/Click on a Catalog> Export to Registry
>> File to create a .REG that, when imported on the user's machine, adds that
>> Catalog to their CBL. When I set up ACA on a user's machine I have a batch
>> file
>> that imports the .REG that adds each standard shared Catalog.
>>
>> Using iDrop is the mechanism by which the system is designed to function.
>> The
>> Categories in the Catalog iDrop down to become Palette Groups.
>>
>> Matt
>> matt@stachoni.com
>>
>>