Some how my projects (many) are formatting strangely when I ask for a code cleanup (CTRL+SHIFT+F)
Is there a way to clear all the project prefs, establish a global one, and that apply everywhere?
Formatting policies are not global, they are per solution. The global preferences are only used for new solutions or solutions that somehow do not have a formatting policy (e.g. created by Visual Studio).
If you want, you can use the "Custom Policies" dialog to create a new named policy set, and apply that to existing solutions.
Related
From various other questions here on SO etc. it is clear that one of the main reasons for websites being able to detect Selenium/ChromeDriver is being used, is the javascript property
document.$cdc_asdjflasutopfhvcZLmcfl_
Is there anyway to prevent this property being created (that does not involve a custom build of ChromeDriver)? Like for example disabling this cache somehow? It would really be preferrable without a custom build. Perhaps with a configuration option of randomizing the property name.
Or would it be possible to somehow through the driver something like this:
delete document.$cdc_asdjflasutopfhvcZLmcfl_;
Initial testing seems to indicate that this does not work. Perhaps because a new cache is created just after executing this script, or similar.
I have read some of the basic Google Apps Script documentation/tutorials. I have not found any explanation of the "scope" of code execution.
Here is what I understand so far:
All code consists of one or more statements
All statements must (?) be contained in a "function"
(a slight different from non-google javascript? - is this a false assumption?)
All functions reside in a container called a "file"
Each "file" is part of a "project" container (or library)
Each project container is stored in a "spreadsheet" container.
These are the "physical" (edit access) boundaries.
My question is what is the "logical" boundaries of statements
during execution?
I started by assuming all variables/objects were global in scope,
similar to the way that JavaScript operates in a web-page. I did not think that
"edit access" containers limited the scope of variable/object definitions.
I was wrong.
I thought that a "library" structure is similar to a PHP "include" operation.
By that I thought it would save me from having to copy the same set of
code into every application (spreadsheet container), in which I needed to
use the already "tested" code. I assumed the resources available to the
included project were the same as those available to the including
project common resources). In short, I was wrong. The "properties" were stored in the defining spreadsheet, and are considered to be "owned" by the containing project.
From playing with it, I now understand that the "project key" just adds
a new "namespace" to the spreadsheet container. What happens in each
namespace remains in that namespace. The only (simplest) communication
between the namespaces is via function parameters and return value.
In particular, User, and Project properties are scoped to and remain in
their containing spreadsheet document. Each project within the spreadsheet
document has separate set of User and Project properties.
The same project/library name can appear in multiple spreadsheet files
and are totally independent.
Is this documented somewhere? And are there other things I need to know
about scoping (communication across threads from different applications
sharing the same project/library?
Also, if a function passes back a reference to an object defined in the
library scope, will it persist in the calling's project? Can I pass/return
a variable that points to a project's UserProperties "sevice" object and have access
to that data in another project?
This is documented towards the end of the User Guide in Libraries:
https://developers.google.com/apps-script/guide_libraries
When deciding how to scope things, we tried to think really hard about the most common use cases, and try to reduce surprise as much as possible, but we weren't perfect.
Regarding your question on whether you can use parameter-passing to share ScriptProperties objects between the library and the project, that's currently not possible. You can always expose getters/setters for particular properties.
If you have an interesting use case in mind which is impossible to achieve without the requested behavior, please file a bug in our issue tracker. Thanks!
I too have wrestled with this. While the documentation is very good, it is a bit confusing.
The shared and not-shared concept took me a bit of trial and error to get.
I did want to mention that UserProperties exist at the user level and is not tied to just the Project or Library. No need to pass UserProperties as you would with ScriptProperties when using a library.
Neat stuff all around :-)
Jim
we use FxCop in current project. Warning CA1822 appears for every unit test method in test projects. So I would like to disable it for test projects.
Is it possible to suppress it for whole assembly?
In VS2005 & 2008, go to the Code Analysis tab in Project Properties and uncheck that rule.
In VS2010, create a custom ruleset with that rule disabled, then select it in the Code Analysis tab in Project Properties.
If you're using stand-alone FxCop with multiple assemblies in a .fxcop project then, no, there's no way to disable specific rules for only a subset of the analysis properties. Because of CA1822, I usually create two separte .fxcop projects: one to contain all the "real" code assemblies, and a separate one for the test assemblies in which CA1822 is disabled entirely.
Since MathWorks release a new version of MATLAB every six months, it's a bit of hassle having to set up the latest version each time. What I'd like is an automatic way of configuring MATLAB, to save wasting time on administrative hassle. The sorts of things I usually do when I get a new version are:
Add commonly used directories to the path.
Create some toolbar shortcuts.
Change some GUI preferences.
The first task is easy to accomplish programmatically with addpath and savepath. The next two are not so simple.
Details of shortcuts are stored in the file 'shortcuts.xml' in the folder given by prefdir. My best idea so far is to use one of the XML toolboxes in the MATLAB Central File Exchange to read in this file, add some shortcut details and write them back to file. This seems like quite a lot of effort, and that usually means I've missed an existing utility function. Is there an easier way of (programmatically) adding shortcuts?
Changing the GUI preferences seems even trickier. preferences just opens the GUI preference editor (equivalent to File -> Preferences); setpref doesn't seems to cover GUI options.
The GUI preferences are stored in matlab.prf (again in prefdir); this time in traditional name=value config style. I could try overwriting values in this directly, but it isn't always clear what each line does, or how much the names differ between releases, or how broken MATLAB will be if this file contains dodgy values. I realise that this is a long shot, but are the contents of matlab.prf documented anywhere? Or is there a better way of configuring the GUI?
For extra credit, how do you set up your copy of MATLAB? Are there any other tweaks I've missed, that it is possible to alter via a script?
shortcuts - read here and here
preferences - read http://undocumentedmatlab.com/blog/changing-system-preferences-programmatically/
At the moment, I'm not using scripts, though this sounds like a very interesting idea.
Unless there are new features that you also want to configure, you can simply copy-paste the old preferences into the new prefdir. I guess this should be doable programmatically, though you might have to select the old prefdir via uigetdir. So far, this has not created major problems for me. Note also that in case of a major change in the structure of preferences, any programmatic version would have to be rewritten as well.
I'm adding paths at each startup, so that I don't need to think of manually adding new directories every time I change something in my code base (and I don't want to have to update directory structures for each user). Thus, I also need to copy-paste startup.m for each installation.
If I had to do everything manually, I'd also want to change the autosave options to store the files in an autosave directory. If I recall correctly, Matlab reads the colors and fonts from previous installations, so I don't have to do that.
I have a small solution that i provide to several people. The solution consists of amongst other things an existing SsisPackage (default.dtsx). I modify this according to some settings in my application to prepare it for transfering data from a datasource to a datamart. I add a sequence container, add a foreachloop and add a dadtaflowtask. Each of these are added (i know i can see them in the package explorer) and the package can execute without problems.
My problem is that when i look at my package i cannot see the elements i added, they are invisible, they exist in the xmla and are visible in the package. Anyone got a possible solution for this - it makes the package almost impossible to maintain for the receiving developer.
EDIT / SOLUTION: For posterity i will document my findings :-)
I have been conparing the underlying xml structure to find this solution so here it comes. The problem is due to the fact that im modifying an already created package. When the package was first made in BIDS layout information was saved within a xml tag called <packagevariable> - all elements have their layout written in encoded xml in the xmla file.
When i go and modify the package through C# and add new elements the layout information is not updated! So when the package is loaded within the BIDS for modification the BIDS recognizes that some layout information is available, so it will use this information to layout the ENTIRE PACKAGE. This means that while we have no layout information for the elements we have added, they are not layed out.
My next step will be to investigate into removing the layout information - then the package will layout the package in a default manner. I will investigate into how to remove it using the API (first priority) else i will have to open the file at XML/Text and make a manual removal (hopefully i will avoid this).
Enjoy!