checking preferences via ACL

cleccese · ‎Aug 01, 2014

How would one checkthe value of apreference setting with ACL? I assume there is some kind of prefix required.
For example, I want to know whether peservices is on or off and

message peservices

doesn't work.

TomLeoboldt · ‎Aug 01, 2014

Hare you tried:
response(preference('peservices'))

naglists · ‎Aug 01, 2014

I use:
response(option('peservices'))

Or I will do something like:
chgtrk = option('changetracking')
set changetracking = off
Do my wonderful, magical, and sometimes tricky stuff here.
set changetracking =$chgtr

Help says not all set options are preferences, preference() will return no
value for one that is not. fwiw.

On Fri, Aug 1, 2014 at 10:06 AM, Leoboldt, Thomas <-<br/>> wrote:

> Hare you tried:
>
> response(preference('peservices'))
>
>
>
> *From:* Caroline Leccese [

ClayHelberg · ‎Aug 01, 2014

Forwarding my response to the list, got bit by the reply address thing...

cleccese · ‎Aug 01, 2014

Thanks, guys. Just what I wanted.

cleccese · ‎Aug 04, 2014

I have the following in my custom/init folder: (5.4)

response(option('peservices'))
if ( option('peservices') == "off" ) {
set peservices=on
}
response(option('peservices'))
set peserverurl=http://.../e3/servlet/e3

Regardless of whether peservices is on or off, I get first response "off" and second "on". However, if I manually turn off peservices via either the command line or the preferences dialog, peservices is still off when I restart AE, even though I get the second "on" message. The url is always correct (I have a similar file in the custom/init folder for 6.0)

If I source the acl file from the command line, it works as expected. I assume because all the PE stuff is already loaded. It didn't fire when placed in theeditinit folder or the doctype folder.

Does anyone know if I can turn on peservices automatically at startup?

naglists · ‎Aug 04, 2014

I do not know of a way to force peservices = on "at startup." We set
peservices = on "at startup" using an ACL in ../init (although we don't
even bother to test its state, we just set peservices = on).

Is there a reason you need it on earlier than that?

I work around some startup timing menu issues by the APTRC (user startup
file environment variable) in the batch file we use to start Editor. Maybe
this would be useful with your need, if there is one, to establish
peservices = on earlier in the process.

On Mon, Aug 4, 2014 at 10:06 AM, Caroline Leccese <-<br/>> wrote:

> I have the following in my custom/init folder: (5.4)
>
> response(option('peservices'))
> if ( option('peservices') == "off" ) {
> set peservices=on
> }
> response(option('peservices'))
> set peserverurl=
> and second "on". However, if I manually turn off peservices via either the
> command line or the preferences dialog, peservices is still off when I
> restart AE, even though I get the second "on" message. The url is always
> correct (I have a similar file in the custom/init folder for 6.0)
>
> If I sou...

cleccese · ‎Aug 04, 2014

Hi Paul,

No, it doesn't matter when peservices is turned on, as long as it's on when AE is finished loading. My problem is if someone turns it off manually and forgets to turn it back on, the script in the init folder doesn't turn it back on when AE restarts.

If you have the time, could you turn off peservices and restart AE to see if your script turns it back on? I would be grateful.

naglists · ‎Aug 04, 2014

Ah, that. Overriding the user preferences file (arbortext.wcf in 6.0).
Yeah, this makes it trickier.

You're right. Called from ../init, set peservices=on will not override the
peservices setting saved in arbortext.wcf when a user changes peservices it
through the Preferences interface.

I tested setting it from a user start up file (specified by the APTRC
environment variable). That will work. It appears to add a little time to
Editor opening but I haven't tested enough (by including other users) to be
sure it's not just something with my machine today.

I found an old note in the adepters archives that suggests calling it from
instance.acl might work ... that the processing order of startup files puts
that later than .wcf processing. I didn't test this. Diving into the
documentation about startup files, order, etc. might suggest other ways to
handle it at startup.

You might also consider providing users a way to set peservices off for a
session so "peservices=off" doesn't get ever get written to the wcf. And/or
a way for users to turn it on that would overwrite the setting in the wcf
so it would be available going forward. Menu items? Hide it in existing
code say for Editor Close so it is always saved as ON at the end of a
session.

On Mon, Aug 4, 2014 at 11:45 AM, Caroline Leccese <-<br/>> wrote:

> Hi Paul,
>
> No, it doesn't matter when peservices is turned on, as long as it's on
> when AE is finished loading. My problem is if someone turns it off manually
> and forgets to turn it back on, the script in the init folder doesn't turn
> it back on when AE restarts.
>
> If you have the time, could you turn off peservices and restart AE to see
> if your script turns it back on? I would be grateful.
>

LynnHales · ‎Aug 04, 2014

I got bit by that 'reply' issue with this message. It only went to clay, so
here is a response (sic) that is a bit dated right now.

Lynn

cleccese · ‎Aug 05, 2014

Thanks, Paul and Lynn!

Instance.acl seems to work, when put in the doctype folder.

largyres · ‎Aug 05, 2014

I use a "belt and suspenders" approach to keeping users' desired preferences set.

if (doc_type()=='chapter'||doc_type()=='section') {

_docload::chapter_menus();

} else if ...

from the command line to check them.

lou.argyres@ceb.ucla.edu | ceb.com

UNIVERSITY OF CALIFORNIA • STATE BAR OF CALIFORNIA

In Reply to Caroline Leccese:

Thanks, Paul and Lynn!

Instance.acl seems to work, when put in the doctype folder.

ClayHelberg · ‎Aug 05, 2014

Also, see the help center topic for write_preferences() for information on how to push programmatically defined preference values into the user preferences file.

--Clay

naglists · ‎Aug 05, 2014

I always wanted to prepare an anti-presentation to Charles' Tips and Tricks
that demonstrated all of the countermeasures we "environment
administrators" can take to prevent our beloved authors from getting into
trouble (especially the kind that triggered 3-a.m.-production-run support
calls).

Removing access to the Preferences Dialog is a perfect example of same.

I had a cute name in mind for the preso but apparently those neurons are on
break ...

On Tue, Aug 5, 2014 at 9:07 AM, Lou Argyres <->
wrote:

> I use a "belt and suspenders" approach to keeping users' desired
> preferences set.
>
> Use a blank menu file from which Tools.Preferences has been removed;
> that's set by an APTMENUFILE environment variable. (There's also an init
> "map all shift-control-alt-0 ... { source showprefsdlg.acl }" back door for
> showing Preferences dialog . The init file also turns off the Command
> window based on APTRC.)
>
> A central script sets all user preferences and is called from relevant
> instance.acl files. Further menu/environment settings are located in an
> editinit ACL and called by the preferences script based on doctype.
>
> if (doc_type()=='chapter'||doc_type()=='section') {
>
> _docload::chapter_menus();
>
> } else if ...
>
> It's important to note that preference modifications by command are not
> necessarily reflected in real time in the Preferences dialog, so use smthg
> like
>
> response(option("changetracking"))
>
> from the command line to check them.
>
> Lou Argyres
>
> CEB / Continuing Education of the Bar
>
> lou.argyres@ceb.ucla.edu | *ceb.com*

DavidS.Taylor · ‎Aug 05, 2014

Isn't the problem that you likely need to give authors the ability to control some preferences but not others?

It's unfortunate that preferences can't be divided into 'personal' and 'environment' categories, the first being accessible to the authors and the second to just the system administrator.

Having all preferences lumped into one file seems to be the issue.

David

David S. Taylor

Project Manager, Production and Marketing
Building Regulations | NRC Construction
National Research Council Canada
Building M-23A, Room 114 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
David.S.Taylor@nrc-cnrc.gc.ca<">mailto:David.S.Taylor@nrc-cnrc.gc.ca>

LynnHales · ‎Aug 05, 2014

Charle's and I did a 'Tips and Tricks' at one AUGI. He gave the Arbortext
line and I gave the work around. It was fun. 😄

Lynn

LynnHales · ‎Aug 05, 2014

True, but like so many other things, which preferences would go where? So
unless the individual program admin could determine it might be difficult to
implement.

Lynn

naglists · ‎Aug 05, 2014

I would have liked to have seen that!

On Tue, Aug 5, 2014 at 10:25 AM, Lynn Hales <->
wrote:

> Charle's and I did a 'Tips and Tricks' at one AUGI. He gave the Arbortext
> line and I gave the work around. It was fun.