Develop Reference

Hide or add new line to variable

Let's say I have this variable in my C# Code
string longVariableStuff = "hsduifgnw8e7rty83rfgediguidogy7834rghf7834ghf170934hf7034hgf734gf8170g437fg73408g1f784g1387fg4731gf7g13fg18347gf78134gf7834gf780134gfuhsdjkfhsdjkafhldsj";
Every time I'm coding, it gets a bit annoying when I scroll back it with the keyboard and my screen jumps to the right.
Is there anyway to just minimize it? Or maybe add a new line in the middle so I can view the whole thing without scrolling right?

Sure, you can just break it up:
string longVariableStuff =
"hsduifgnw8e7rty83rfgediguidogy7834rghf7834ghf170934hf7034hgf7" +
"34gf8170g437fg73408g1f784g1387fg4731gf7g13fg18347gf78134gf783" +
"4gf780134gfuhsdjkfhsdjkafhldsj";
This incurs absolutely no performance penalty, because the strings will be concatenated back into one string at compile time.

If you have really long strings it could be easier to manage them as string resource.
Right click on the project > Properties > Resources. Select Strings from the combo box. Enter a resource name and the string.
After saving, you should be able to access your string with
string s = Properties.Resources.MyStringName;

#Blorgbeard probably has the better answer, but there is a second way
string x = #"abcd
abcd
abcd
abcd";
Will get you "abcdabcdabcdabcd". The other version is much cleaner though so you should probably use that, I'm just adding this as an alternative.
Second idea that technically solves your problem but is a little clunky:
You can use a region to hide it in visual studio so you don't have to look at it when you don't have to.
#region my long string is in here
string longVariableStuff = "hsduifgnw8e7rty83rfgediguidogy7834rghf7834ghf170934hf7034hgf734gf8170g437fg73408g1f784g1387fg4731gf7g13fg18347gf78134gf7834gf780134gfuhsdjkfhsdjkafhldsj";
#endregion
Visual studio will allow you to collapse it so you don't have to look at it, and it won't affect horizontal scrollbar as you move the cursor over it.

Using the c# verbatim operator
MSDN
string multilinestring = #"my-
multiline
string";

StringBuilder is the performant way to concatenate long strings together.
String interpolation is another performant way. $"{a}{b}"

AutoCorrect in WPF Richtextbox

I read on MSDN that .NET 4.6.1 supports auto correct now.
The files in %appdata%/Microsoft/Spelling// were created automatically and I added the following line to the default.acl (file is still UTF-16 with BOM):
tramampoline|trampoline
I have set the project to target 4.6.1 and enabled SpellCheck on a RichTextBox:
<RichTextBox SpellCheck.IsEnabled="True" Language="de-DE"/>
While it highlights the word when typed wrong in the usual manner, there is no autocorrection happening.
What am I missing here?
I don't quite understand the note:
Note: These new file-formats are not directly supported by the WPF spell checking API’s, and the custom dictionaries supplied to WPF in applications should continue to use .lex files.

I know this is old, but as far as I know you need to handle AutoCorrect on your own (if I'm wrong please correct me with an example). You can do this as follows:
var caretPosition = richTextBox.CaretPosition;
// Make sure you're passing a textpointer at the end of the word you want to correct, i.e. not like this ;)
errorPosition = richTextBox.GetNextSpellingErrorPosition(caretPosition, LogicalDirection.Backward);
if(errorPosition == null)
{
return;
}
var errors = richTextBox.GetSpellingError(errorPosition);
// Default would be to only replace the text if there is one available replacement
// but you can also measure which one is most likely with a simple string comparison
// algorithm, e.g. Levenshtein distance
if (errors.Suggestions.Count() == 1)
{
var incorrectTextRange = richTextBox.GetSpellingErrorRange(errorPosition);
var correctText = error.Suggestions.First();
var incorrectText = incorrectTextRange.Text;
// Correct the text with the chosen word...
errors.Correct(correctText);
}
// Set caret position...
An important note would be not to use the RTB's CaretPosition, but rather to use a textpointer at the end of the word you wish to correct. If your textpointer/caret is in a weird spot (e.g. the end of 20 whitespaces), the GetNextSpellingErrorPosition method may take up to 60 seconds before it returns (depending on the hardware/number of words in your RTB).

Get visible lines in Scintilla.NET component

How can I get the first visible (top) and last visible (bottom) lines number for Scintilla component in C#? For example, if I scroll the text and I am able to see lines 5-41 (no folding, it is the number of lines which are shown by the component at the moment; the rest, you have to scroll to them), how do I get those numbers programatically?

If you ever want to find out how to do something with Scintilla, your first stop should always be the core Scintilla Documentation. It is comprehensive, and usually kept fully up to date.
The correct way to do what you want is to use the SCI_GETFIRSTVISIBLELINE message to get the first line, and then use the SCI_LINESONSCREEN message to calculate the last line.
There are probably Scintilla.NET wrapper methods for those messages. But the Scintilla.NET documentation seems very poor, and doesn't provide a complete description of its API - although I suppose you could always use the SendMessageDirect method (which is documented) to send the messages directly if you can't guess what the wrapper method is called.

For ScintillaNET 2 it would be:
scintilla.Lines.FirstVisibleIndex
scintilla.Lines.VisibleCount
In ScintillaNET 3 names were refactored to be more like core scintilla:
scintilla.FirstVisibleLine
scintilla.LinesOnScreen

Using Excel.XlLegendPosition.xlLegendPositionCustom in C#

Has anyone any idea how to use Excel.XlLegendPosition.xlLegendPositionCustom to specifically position the legend of a chart? Currently, I'm using
chart.Legend.Position = Excel.XlLegendPosition.xlLegendPositionBottom;
which does exactly what one would expect. Right up until the time when you try and print the chart. THEN it places the legend pretty much where ever it wants -- which isn't where I need it to be.
I've checked the MSDN and every other site I could think of. The best Microsoft can come up with is as follows:
xlLegendPositionCustom: A custom position.
There are no examples that I could find that show how to use this.
Thanks for any help.

Okay, it doesn't seem as if anyone has encountered this particular issue -- or needed to use the command. No worries, I appreciate folks taking the time to look at the question.
I did find a workaround that allows you to position the legend using points. It appears if you use the preset positioning options (like Excel.XlLegendPosition.xlLegendPositionBottom), Excel positions the legend based on whatever magic MS uses to figure these things out. Since I couldn't figure out how to use the Excel.XlLegendPosition.xlLegendPositionCustom, I played around with the other commands and found these:
chart.Legend.Left = 375;
chart.Legend.Top = 450;
Those commands will take an int (I used 374 and 450) and using them, you can force the position of the legend to anywhere on the chart.

I don't think you can set it to xlLegendPositionCustom, it's read-only, i.e. when you 'ask'(Debug.Print ActiveChart.Legend.Position), after setting ActiveChart.Legend.Left/ActiveChart.Legend.Top you get -4161 which is xlLegendPositionCustom.

Word 2007 throws an exception for interop code that manipulates shapes but works fine in Word 2010

I'm having big problems with a code that should add watermark pictures (used as stationery) to a document before saving it as PDF. Inserting the picture to all relevant headers is no problem. But as soon as I try to strech the picture (shape) to the whole page width and height, Word 2007 (SP3) throws an exception. The same code works fine in Word 2010 (SP1). It doesn't matter if I use the Office 12 or Office 14 interop assemblies (always used with "Embed Interop Types" true).
The exception thrown is the following:
System.Runtime.InteropServices.COMException (0x800A122C): Falscher Zeichnungselement-Typ für diesen Befehl.
at Microsoft.Office.Interop.Word.Shape.set_RelativeHorizontalSize(WdRelativeHorizontalSize prop)
at BEKO.PDB.AuxiliaryServices.Documents.WordCreationService.AddWatermarkToHeader(HeaderFooter header, String watermarkFilePath)
I don't know exactly what the english error message would be, but the translation is something like "Invalid painting type (or maybe shape type) for this command".
The weird thing is that it doesn't always error on the same interop call. If I remove the line that sets the RelativeHorizontalSize property it fails when setting another property, like WidthRelative (with the same exception). If I add a line that sets shape.LeftRelative (to the "do not use" constant) it even fails on a line that otherwise works like shape.Top (again with the same exception).
The code I'm using is from a macro that was recorded in the failing Word 2007. I'm also correctly switching to the header SeekView before executing any header related code because I already needed that for some other header/footer code.
Here is the full code that adds the shape. It should just insert the picture and strech it to the full page size. Note: This method is only called for headers that are actually existing (headerFooter.Exists) and that are not linked to the previous (!headerFooter.LinkToPrevious).
private static void AddWatermarkToHeader(HeaderFooter header, string watermarkFilePath) {
header.Range.Editors.Add(WdEditorType.wdEditorEveryone);
Shape shape = header.Shapes.AddPicture(
FileName: watermarkFilePath,
LinkToFile: false,
SaveWithDocument: true
);
shape.WrapFormat.AllowOverlap = (int)MsoTriState.msoTrue;
shape.WrapFormat.Type = WdWrapType.wdWrapNone;
shape.RelativeHorizontalPosition = WdRelativeHorizontalPosition.wdRelativeHorizontalPositionPage;
shape.RelativeVerticalPosition = WdRelativeVerticalPosition.wdRelativeVerticalPositionPage;
shape.Left = 0;
shape.Top = 0;
shape.RelativeHorizontalSize = WdRelativeHorizontalSize.wdRelativeHorizontalSizePage;
shape.RelativeVerticalSize = WdRelativeVerticalSize.wdRelativeVerticalSizePage;
shape.WidthRelative = 100;
shape.HeightRelative = 100;
shape.ZOrder(MsoZOrderCmd.msoSendBehindText);
}
Please give any advice how to fix this so that the code works with both Word 2007 and Word 2010.

I realize this does not fix the code to run on both versions of Word as requested, but have you tried using absolute sizing for the image instead? Keep relative positionning, but use absolute sizing. Do you actually need relative sizing (i.e. do your documents contain multiple page sizes?).
shape.Width = page.Width;
shape.Height = page.Height;

From Word 97 through to Word 2003 there has been a little known bug in the Word Object Model that causes WdRelativeHorizontalPosition.wdRelativeHorizontalPositionPage and WdRelativeVerticalPosition.wdRelativeVerticalPositionPage to retrieve the incorrect information if the magnification of the active Word document in not 100%. I suspect that this issue still exists in Word 2007 and may be causing your exception. Here are two threads (both dealing with the same issue in VBA) that refer to this issue:
Points-returned-by-Information-wdHorizontalPositionSubroutines
Word 97 wdHorizontalPositionRelativeToPage
I suggest adding code after the addition of the shape in the header (and prior to retrieving the relative horizontal and vertical positions to the page) that changes the Active Document's zoom to 100% and the View Type to the Print Layout view. (You may have to experiment with which part of the Word document is displayed when the code for changing the positioning and sizing of the shape is executed. Sometimes it will be necessary for the Active Document to display/be able to edit the main document instead of the header.)