I'm writing a simple console application, but I don't like the shape of the cursor used in the console.
I would like to change it to a vertical line as I did through the command line settings, but after using the
Console.ShowVisible = true;
it changes to the standard underscore.
I tried to find the solution on this site but didn't find.
This is from Price Mark.Js book about C# 10 and .ENet6
Setting options with arguments
We will now use these arguments to allow the user to pick a color for the background,
foreground, and cursor size of the output window. The cursor size can be an integer value from
1, meaning a line at the bottom of the cursor cell, up to 100, meaning a percentage of the height
of the cursor cell.
The System namespace is already imported so that the compiler knows about the ConsoleColor
and Enum types:
Add statements to warn the user if they do not enter three arguments and then parse
those arguments and use them to set the color and dimensions of the console window,
as shown in the following code:
if (args.Length < 3)
{
WriteLine("You must specify two colors and cursor size, e.g.");
WriteLine("dotnet run red yellow 50");
return; // stop running
}
ForegroundColor = (ConsoleColor)Enum.Parse(
enumType: typeof(ConsoleColor),
value: args[0],
ignoreCase: true);
BackgroundColor = (ConsoleColor)Enum.Parse(
enumType: typeof(ConsoleColor),
value: args[1],
ignoreCase: true);
CursorSize = int.Parse(args[2]);
Setting the CursorSize is only supported on Windows.
In Visual Studio, navigate to Project | Arguments Properties, and change the
arguments to: red yellow 50, run the console app, and note the cursor is half the size
and the colors have changed in the window, as shown in Figure 2.7:
3.In Visual Studio Code, run the code with arguments to set the foreground color to red,
the background color to yellow, and the cursor size to 50%, as shown in the following
command:
dotnet run red yellow 5
Although the compiler did not give an error or warning, at runtime some API calls may fail on
some platforms. Although a console application running on Windows can change its cursor
size, on macOS, it cannot, and complains if you try.
Related
So I updated my Visual Studio to the latest version today, and when I'm writing in C#, all the functions and variables are just white in color.
I'm so used to seeing functions in yellow and variables/properties in blue, so I would like to know if it's possible to get the colors back?
In VS 2019, go to "Tools" > "Options" > "Text Editor" > "C#" > "Advanced" and make sure in section "Editor Color Scheme" VS 2019 is selected.
Edit: looks like they changed the options there in an update. I remember that in this options-section in an earlier VS2019 version there was a switch named "Use enhanced colors for C# and Basic"
As johnmoarr suggested, try changing the default Color Scheme of the editor.
If that won't work, you can still apply colors for any element by hand. Therefore open Visual Studio, go to the Tools-menu and open the menu-item Options.
Within the Options window open Environment and then Fonts and Colors. Locate the User Members and User Types within the list of display items just like I did in the following example:
Apply the desired color to the items foreground or background. Example: set item foreground to white for User Members - Methods to display method names with white color:
A client asked me to build an inventory solution for them where they'd print barcode labels for all office equipment to keep track of them in various ways.
They gave me a Citizen CL-S621 printer (203x203 dpi resolution) to use for testing and after (the nightmare that was) configuring its drivers to print and fitting everything to the nonstandard labels they gave me to test, the biggest problem I'm still running into is that the printer is having trouble printing some bars in a straight line and instead prints them in dashed/dotted forms.
The C# Code below shows the basics of how I build the barcodes using this library :
public void CreateTheBarcode(string StringToEncode)
{
Barcode b = new Barcode();
b.LabelFont = new Font("Sample Bar Code Font", 24, FontStyle.Bold);
b.IncludeLabel = true;
b.Encode(BarcodeLib.TYPE.CODE128, StringToEncode, Color.Black, Color.White, 730, 140);
b.SaveImage(#"C:\temp\Barcodes\"+StringToEncode+".png",SaveTypes.PNG);
Print(#"C:\temp\Barcodes\"+StringToEncode+".png");
}
public static void Print(string FilePath)
{
Process printJob = new Process();
printJob.StartInfo.FileName = FilePath;
printJob.StartInfo.UseShellExecute = true;
printJob.StartInfo.Verb = "printto";
printJob.StartInfo.CreateNoWindow = false;
printJob.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
printJob.StartInfo.Arguments = "\"" + "Citizen CL-S621" + "\"";
printJob.StartInfo.WorkingDirectory = Path.GetDirectoryName(FilePath);
printJob.Start();
}
The hardcoded width and height are the best approximation I found of a good image size the printer would accept and accurately print onto the labels since I had to measure their size by ruler and between printer offsets and eye-measurement accuracy issues getting a size that worked proved troublesome.
In any case, I generated some barcodes and the images are crisp, clear and seem pretty good:
The lines are straight and clearly defined, the text is sharp, everything seems fine;
but when I go to print them I get:
Some of the bars print straight and clear while some have irregular edges and some are just irregular dot/slash/curved patterns. The text in all of them suffers the same issue. I have tried different font sizes and supposedly barcode-friendly fonts and the issue persists. The problem persists if I remove the text labels.
It strikes me as an image rasterization issue but I am not fully sure, nor do I know how to fix that.
I'm not yet sure if a scanner can read these or not, I receive one tomorrow, but any tips on what I may be doing wrong would be appreciated.
These printer settings should help:
Select the printer in Device and Printers > Printing Preferences > Graphics
Set Dithering to None
The printer is antialiasing your images. This is an endemic problem with barcode fonts. You have to either set your printer to not antialias (try Settings/Printer/Printing Preferences/Color Mode/Monochrome) or you have to set the image DPI to be identical to the printer DPI (typically 300 DPI).
If your printer renders to a rectangle and not to a DPI, you have to size your image so the image pixels are an integer multiple of the printer pixels of the same rectangle.
It's difficult to propose a solution to your problem because you have too many moving parts; you start with a font that goes to an image that goes to a file that goes to a shell command that goes to an application you haven't told us about that goes to a printer. Any one of those steps could anti-alias your image.
My suggestion is to remove these intermediate parts. What's calling CreateTheBarcode? An application you wrote? Try having that application print to the printer directly using .NET System.Drawing.Printing.PrintDocument. You can't do that and have to use the mystery application UseShellExecute calls? Study that application, maybe there is some way you can send printer commands instead of going through all that font to image to file rigamarole; many label printers have ways to output text like “test 123” directly as barcodes.
Edit: Maybe what you are attempting is flat-out impossible. What are the dimensions of the label you are printing to? Your “More numbers” example is over 500 px across and your printer is only 200 DPI. If the labels are narrower than 500/200 ≅ 2.5 inches there is no way the bars will fit even if you print at 203 DPI.
Same problem and this worked perfectly.
Option 1: Adjust Dithering Settings
Click the Windows button.
Go to Control Panel.
Go to Devices and Printers.
Right-click preferred printer.
Click "Printer Preferences".
Go to "Dithering" tab and select "None".
Click apply.
Let me start off by saying I tried to research this, but I'm unable to word it to where I wouldn't get irrelevant results.
So here's the issue. I have a button (actually, 6 buttons) which have a rounded corner appearance. They're saved as PNGs, and loaded into the button using button.BackgroundImage = [resource]. Five of them work perfectly fine. When they're clicked, the background image is changed and, again, looks fine - including changing back when the button is no longer pressed. Then there's the button in the screenshot below.
I have no clue where this green color is coming from - in fact, when I go pixel-by-pixel over the image using GetPixel, and check the ARGB values, they turn out to be purples with A = 0. Also confusing is that the green only shows up at run-time -- as shown in the image. According to PhotoShop and GiMP, the RGB is 46,139,86 .. GetPixel shows them to be various colors in the purple range, but as an example, at 0,0 it shows 164,119,182 A:0.
Here's the list of things I've tried (some pseudocode):
if (pixel.A == 0) { SetPixel(x,y,Color.Transparent); } -- No change
if (pixel.A == 0) { SetPixel(x,y,Form1.TransparencyKey); } -- See
through to desktop instead of form background (as expected).
Use a known good image (see screenshot) -- No change.
Delete control, copy and paste a known good control (see screenshot)
-- No change.
Add another control, hoping I could hide the flawed one and basically
just ignore it. -- All new buttons have this issue.
Move button to different area of form (long story). -- No change.
Set no background in designer, then set the background in Form1.Load. -- No
change.
Restart Visual Studio. -- No change.
Clean solution, rebuild. -- No change.
Restart computer. -- No change.
Anyone have this issue before, or know what's going on? I have a solution that works (use a panel as a button - I just tested it and the transparency is fine on a new panel) .. but I'd prefer to figure this out. Thanks in advance!
Here's the imgur:
I switched to VS 2012 yesterday from VS 2010 and all seemed to go well except this.
I have a button on my form that when pressed extends the width of the form to show additional controls. Press the button again and it reduces the width to hide those controls. Now all of this worked great in VS 2010 and also works fine when I debug in VS 2012 but as soon as I publish or compile the project and open the .exe when you click on the button it adds like 5 to the width instead of the 100+ it needs to. I click it again and it will then change it to 372 like it should and shows all my controls. I click it again to hide the controls and it hides the controls partially (goes to the 188 + the mysterious 5) I hope all of this makes sense and am hoping there is a better way to run the process I need to.
Here is the code I am currently working with and I didn't change anything between switching from 2010 to 2012. In fact, if I open this same solution in 2010 and publish everything works fine.
private void button1_Click(object sender, EventArgs e)
{
if (this.Width == 188)
{
this.Width = 372;
this.Height = 540;
progressBar.Value = 100;
copied_status.Text = ("Output View Enabled");
}
else
{
progressBar.Value = 100;
copied_status.Text = ("Output View Disabled");
this.Width = 188;
this.Height = 540;
}
if (this.Width == 372)
{
button1.Text = "<<";
}
else
button1.Text = ">>";
}
The width of your form hasn't been 188 pixels in a long time. Now with VS2012, Windows finally stops lying about it.
At issue are the fat window borders in Aero. They were an extreme appcompat problem when the feature was introduced in Vista. Very necessary because those two pixels where getting hard to hit with a mouse. But drastically incompatible with the way an application creates a window. It asks for a specific window size, the outer size, the nWidth and nHeight arguments of the CreateWindow() function. But what really matters is the size of the client area, the part of the window inside the borders. If Microsoft wouldn't have done something about it, old applications would have ended up with a client area that was too small. Which looks very bad, the window content would not fit anymore. A control towards the bottom or right side of the form would not be completely displayed for example.
So, sneakily, Aero makes the window larger by the extra width of the fat borders. And when the app asks for the window size, it sneakily says that it is smaller by the same added width. The app doesn't know any better than it is still running with the same window size it had on XP. This works pretty well, but is not exactly ideal. Hard to get window edges to align properly with that lie for example.
Whether or not Aero will lie about the window size is based on the target operating system recorded in the EXE header. When it sees a version older then 6.00, the Vista version number, then it will assume that your EXE is a legacy program that doesn't know about the fat border feature. So needs to be lied to. You've been running with that target version number set to 4.00 for a long time, it is written by the .NET compiler when it builds your program. You can see it with dumpbin.exe /headers yourapp.exe.
This finally changed in VS2012 and .NET 4.5. Which is a .NET version that is not available in XP. The compiler can finally make the hard assumption that XP is history and you are going to run on a version of Windows that supports Aero. So it sets the target Windows version in the EXE header to 6.00. Correspondingly, Aero will now stop lying about the window size. You get the real one, not the faked one.
So a quick fix is to change the target .NET framework version to 4.0. That's available on XP so you'll get lied to again.
Of course it is better to fix your code. Never use the Size, Width or Height property, they'll inevitably depend on the border and caption size. Use the ClientSize property instead, that's the stable one and the one you really care about. But be careful with that property as well, a form may rescale when it runs on a machine that has its video adapter set to more than 96 dots per inch. Another feature that's very accessible in Vista and up. Rescaling changes the ClientSize proportionally by the DPI setting.
The real fix is to use a bool field instead that keeps track of the window state. And set the ClientSize property based on the position of a control you want to hide or reveal. So roughly:
private bool enlarged;
private void button1_Click(object sender, EventArgs e)
{
enlarged = !enlarged;
int width = someControl.Left - 5;
if (enlarged) width = someControl.Right + 5;
this.ClientSize = new Size(width, this.ClientSize.Height);
}
Replace someControl in this code with the name of your controls.
I can't find a way to change that anywhere and CodeRush sets the foreground color to a very light gray that is nearly unreadable on my monitor's white background. It is hard to read the code when variable names (as well as unused method parameters and using directives) are this light.
The options, such as colors of the different code issue types underlining, are available inside the Visual Studio configuration dialog. From the main IDE window, go to Tools | Options…, then Environment | Fonts and Colors. In the “Display items:” list, you can find the Dead Code item. For this item, you can change the “Item foreground” and “Item background” color properties.
See more details here: CodeRush Code Issues configuration and options