My program is writing a string with multiple lines of just █ to console. This is done with a
Stringbuiler and its ToString().
However there is a yellow line bleeding through the same place every time and only when drawing a lot of █:
Image with yellow line bleeding, CursorVisible set on true temporary
It's hard to see in the image and hard to explain, but different parts of the lines are phasing in and out while the program is running. It makes me believe it's not the code but the console itself.
Colours are not being used or changed except for the background colour. But that will be set to Black again.
Changing the window size while it was writing to console helped to move it to a place where nothing was being written, thus making it dissapear but leaving a big empty void.
It reappears in the same spot if you maximise the console window or when changing the size back.
This is related to the WindowSize and BufferSize. I had to fill in the empty space with the ASCII for SPACE and then the artifacting went away.
It's weirdly inconsistent in when this yellow line artifacting appears. As I was not able to always reproduce it. I'm unsure if this is a permanent solution to this problem, but so far testing hasn't been able to get this yellow line again. That's why I'll be marking this as solved.
Related
I have a simple WinForms window in which the user can modify their user settings.
Sometimes (but not always) the app appears frozen while the window takes many seconds to open.
The Form contains a single TextBox.
After profiling I found that up to 19 seconds are spent in the constructor of this textbox,
specifically in System.Drawing.Font.FromLogFont.
https://learn.microsoft.com/en-us/dotnet/api/system.drawing.font.fromlogfont?view=dotnet-plat-ext-7.0
A GDI LOGFONT, or logical font, is a structure that contains 14 properties that describe a particular font.
I have tried using a different or the default font, but the problem seems very arbitrary, sometimes the window opens in less than a second, sometimes it makes you wait for half a minute.
This is about as far as I got with profiling, what are ways to further debug this problem?
I tried using different fonts, or the default fonts. The problem is sometimes there, sometimes not.
The expected result is that the window opens seemingly instantly, not making the user wait.
I was writing the code normally and then I fear I have accidentally pressed some shortcut that made my code all highlighted green, I tried to press some combos but nothing changed, I deleted the script from Unity and pasted the code into a new script, and it gave me the same issue. If I press anywhere it doesn't change anything and it only disappears for a moment when I edit the code and then it goes back to being green. I imagine this feature has a purpose that I'm not understanding but at the moment it's not doing anything for me except making the code less readable. Does anyone know what caused this effect, how can I remove it, and what is it's purpose? Thanks for your help.
You can also check the theme here:
Maybe you turned on "Toggle Code Coverage Highlithing" under Tools menu.
If it looks something like this then you've probably added the files to your project without adding them to git. The green indicates added but unstaged changes. Do you see plus signs in the ruler?
When I run my console program, it stops on the line depicted in the screenshot, and points a little arrow at it.
Here is the line
Details: I have tried to run the program without it, to see if it is the definitely the source of the problem, but it still stops running, and points that arrow shown in the screenshot at the NEXT line. If I continue commenting out everything the arrow points at, I eventually reach the curly bracket at the end of the method, which the arrow then points at... I don't even know what it's supposed to mean.
Any help to fix this would be highly appreciated.
Click on the red circle in left side of your code to remove it, then start your program again! It’s gone :)
Just Press F5 to run the whole code or F10 to run the code line for line
It stops bcs you set a breakpoint in line 132, like elgonzo commented you already.
Press again F9 in line 132 to remove the breakpoint, or just click on the red dot/circle while ur code is NOT running.
Youtube also has a lot of awesome tutorials or read a C# book.
Summary
I'm using C# .NET 4.0 Framework on 64 bit Windows 7 to write to the registry, and one of the values I write seems to change when I log off (or on, I can't tell), but only the first time I log off and back on.
Please help me understand what I'm missing.
Full Story
Before we begin, there are valid reasons to do this, so please don't tell me "AH!! NEVER DO THIS!!" I understand that in the general case, this is not something you want to do to someone's computer. This is a controlled, limited distribution bound for specific machines that run embedded systems.
With that caveat, I'm trying to programatically change the DPI to 96 and the window border width to very small. It seems I can do one or the other successfully, but doing them both stomps on each other.
For testing, I use the Control Panel tool shown in the screenshot below to modify the DPI to the wrong settings, then run my program, snippets shown below.
Here is the code:
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "AppliedDPI", 0x60); // fix the DPI.
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\FontDPI", "LogPixels", 0x60);
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\0000\\Software\\Fonts", "LogPixels", 0x60);
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\0001\\Software\\Fonts", "LogPixels", 0x60);
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Hardware Profiles\\Current\\Software\\Fonts", "LogPixels", 0x60);
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop", "LogPixels", 0x60);
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "BorderWidth", "-15"); // fix the border width.
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics\\", "PaddedBorderWidth", "-15"); // fix the border width.
Now, in order for Windows 7 to actually apply these changes, I have to log off and back on. Prior to logging off, if I look in the registry, I see the values above all show up as I want them to. Once I log off and back on, PaddedBorderWidth has somehow become -60 instead of -15. I don't think it has to do with PaddedBorderWidth being the last in the list. I tried it first with the same results.
I think Windows 7 has some other Windows Theme thing that still has a hold on the window border width and is causing this on log on or log off. Once I log back on, if I run my C# program again, this time the setting sticks. Again this points me at a Windows Theme still holding on.
I don't know why nor how to stop this. Can someone point me in the right direction?
UPDATE
Experimentally I have determined that the border width changes only when I change "HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels and then log off and back on. Unfortunately, this is one of the keys I really need to change. It seems that changing LogPixels triggers some sort of border width default. Any thoughts?
Again, I know this is a very non-standard thing to do, but such is life.
Workaround Update
I worked around this issue by creating a small executable that sets these registry values when run as an elevated user. In the help file, the user is told to run this if the GUI doesn't look right, then they must log off and back on. If it still doesn't look right, they have to do it again, at which point, the settings will finally stick.
While this "solves" the issue, it leaves me feeling extremely unsatisfied, as I feel there should be a nice, clean technical fix so the user never has to do this, but I'm out of time and have to ship. If anyone comes up with a better way, please speak up. I'd love to fix this for the next rev.
Hopefully sometime in the future we can just fix the GUI to be DPI-aware, but that's much easier to say than do with this legacy code.
I've had a report from the client who had issues printing (my) charts in WPF with a large number of data points. On the screen everything is visible. Here's a screenshot
But when he prints it the part of the graph disappears in a pretty strange way. Here's a screenshot from printed PDF (same thing happens with actual printer)
The printing is done using simple PrintVisual code
PrintDialog dialog = new PrintDialog();
if (dialog.ShowDialog() == true)
{
dialog.PrintVisual(chart, "Chart");
}
I've tried to debug this but it seems that none of my rendering code gets called on printing (or at least no breakpoints get hit in Visual Studio) so I'm out of ideas of where to look.
If number of data points is relatively small everything prints out as expected.
Any ideas?
Thanks!
If found out that this issue is cause by the use of OpacityMask in the rendering process (which is not needed most of the time). If I don't use OpacityMask everything works just fine.