I just upgraded to ReSharper 8.1.23.546 and it added a new key to our team settings file:
<s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ESettingsUpgrade_002EMigrateBlankLinesAroundFieldToBlankLinesAroundProperty/#EntryIndexedValue">True</s:Boolean>
What is this, and why did it add it to the team settings file? Will it cause issues with other developers when this is stored in version control and they haven't upgraded to this version yet?
This is an indicator that ReSharper has migrated some settings that have changed from one version to the next, and is used to not run the migration again.
In this case, ReSharper 8.0 introduced some new formatting options - number of blank lines around property/auto-property, and number of blank lines around single-line property/auto-property. I don't know for sure, but looking at things, it's reasonable to assume that ReSharper 7 used the number of lines around a field when formatting properties.
If you've got a fresh install, introducing these new options is no big deal - everything will be default, and nothing will get written to the settings file. But, if you've previously customised the number of blank lines around a field, then introducing these new options will change the existing behaviour, because the formatter would use the new default options, rather than the old, customised value. So, the migrator runs and checks to see if the number of lines around a field is anything other than the default. If it is, it checks to see if you've already edited the number of lines around properties. As long as they're still set to the default, it overwrites the (default) value to be the same as the number of lines around a field - it migrates the previously used field values to overwrite the default values for properties. It then adds the migration indicator to make sure the migrator doesn't run again, else you'd never be able to have default formatting for properties and non-default formatting for fields.
As for why it's in the team settings, I presume that's because the customised field value is also in the team settings file. Since this file is shared, it makes sense to only migrate the values once, so the indicator should also be in the shared file. There will be no danger in sharing this with the team.
Related
Sorry, I'm not familiar with typo3...
I have a typo3 6.2.14 installation (cannot be updated due to needed extensions) where the constants for click-enlarged images had to be adjusted.
I've cleared the cache, but nothing changed. What do I need to do?
plugin.tx_kjimagelightbox2.lightBoxMaxW = 1600 //(was 800)
plugin.tx_kjimagelightbox2.lightBoxMaxH = 1200 //(was 600)
Nothing changed. Thanks
Wow,
that's some very old TYPO3 with loads of security issues and outdatet PHP as well! Consider forking the extensions and make them work in at least 8.7.
Back to your question.
Where did you set this? Do you use files or do you just edit in the backend? You might need to gather some more information about the order your extensions are beeing loaded.
You might set your values too early and the extensions' defaults overwrite your "changes" (which have actually been declarations)
Maybae you could provide some more information of your setup.
the problem is:
the maximum sizes for images can be influenced in multiple places with multiple values.
Even if you have set the correct value, this value may be overwritten later with the smaller values.
1st:
are your original images at least big enough? normaly there is no enlargement of images.
2nd:
inspect the values in the TSOB. Are your values active in the setup?
your changes in constants may be overwritten in the setup easily and only setup is relevant for rendering.
3rd:
there are global maximum values about image rescaling in content elements. maybe these also influence your image rendering in that plugin
I'm building a website using brython and I came by a problem that has nothign to do with it.
My problem is with Mezzanine or TinyMCE editor (I'm not sure which). To make brython work I need the script tag to be "text/python". But the editor filters it automatically to "text/javascript".
I disabled the filtering already, both in the admin panel and in the actual source code, I tried adding "text/python" to the RICHTEXT_ALLOWED defaults in the mezzanine configuration too.
Just to be clear, security is not an issue, this particular feature won't go online in the final version of the website.
Although the HTML specification does allow one to put any value other than "text/javascript" in script's type attribute, few projects do that, and Brython is one of those few. It is likely the "text/javascript" value is simply hardcoded in the editor and it won't allow you to change that.
(There is probably a big chance of having an issue closed as "won't fix/not a bug" or equivalent if you try to report this to the editor's issue tracker).
I think the workaround in this case is to write some javascript to change the text on the attribute on the relevant script tags to "text/python" prior to calling Brython. i.e., instead of triggering Brython on your page with
<body onload="brython()" >
Do something along
<body onload="function (){var x = document.getElementsByName("python"); for(var i=0; i < x.length; x++){x.type="text/python"};brython()}()" >
(and of course, add the attribute name='python' to all your python script tags)
I am new to VBA and am currently still studying the most basic ideas of the language. I haven't gotten that far in my VBA Code studies to write the code I need by hand, so, in the mean time, I have been using the VBA Editor to enter Property Values via the Properties Window. This has been proving far more difficult than I anticipated. My Goal is to create a drop down list for a VBA Form. I understand one of my options is to reference a range of cells in my excel worksheet by inputting it into the value field located right of the ControlSource Property. My attempts to input the desired range always comes up with the same error:
Could not set the ControlSource Property. Invalid Property Value.
I have tried looking in the VBA Help files and even searched online. I haven't had any luck finding the proper syntax to enter into this field.
I am assuming I may run into similar issues as I try to set other property values through the Property Window. Thus, I am diligently studying my VBA courses so I can simply write the raw code. But that takes time and I need this form to work as soon as possible.
Is there anyone out there that wouldn't mind lending me their brain for a moment? I would be most grateful. Having this working would bring a lot of stress off of me.
Thanks for reading!
What tigeravatar mentioned, works fine for me, for the ComboBox as well for the ListBox.
If I enter =a1:b5 into the ComboBox' RowSource, I see the values of the cells if I open the form and the Combobox. Tigeravatar's notation with $ and sheet! may be more reliable for the productive version.
The RowSource is where the boxes get their displayed items from. The ControlSource is where the chosen value finally is linked to. So if I write just A10 to the ControlSource, then open the form, then pick a value, close the form, I see the chosen value filled to the Excelsheet field A10.
Sometimes it helps to start a fresh UserForm and to add some simple fresh controls. If you seek around, you will probably alter property values that influence the behaviour in an unexpected way, and then you get lost. I have tested with Office 2010. If you have another version, it may be important to forum readers to know.
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.
If i make a label in TFS, and later make a new label with the same name... then the old label is replaced by the new one.
How do I prevent TFS from overwriting a label?
The following MSDN article covers using the Scope of a label to try and minimize the occurrences of these mishaps:
Using the /Child Option to Avoid Labeling Mishaps
If you issue a label command together with a pre-existing label name and an itemspec that includes files that are already marked by the same label, the value of the /child option determines whether the marked files are updated with new revision information. That is, the files are labeled by the same name, but have different scope.
Thanks, that led me on the right track.
It seems that the label overwrite is a "feature" and not a bug. It's working as designed
sixletter's link above explains it, and below are two more with info about it.
http://msdn.microsoft.com/en-us/library/ms181439(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms181440(VS.80).aspx
Apparently TFS labels are not a snaphot of a point in time like in other VCS's , though i do not fully understand the explanation.