Here is my previous question, if you want some further information regarding my current problem:
WinForm: Inherited Panel wont Autosize
If you don't want to read through it, I'll give you some general information:
I'm not working directly via the programme, I'm just editing a specific DLL, that is used by this programme
That means, that I don't have any access to the source code of this specific programme
That also means that I have to fix this problem via some changes in the DLL, that is - as I mentioned before - used by this programme.
What I found out so far:
It works without any problems, if I attach the programme to the DLL's source code in VS2015.
But it has some glitches if I build the code and then copy the DLL into the programme's folder - that's also my actual problem: it somehow shrinks the tableLayoutpanel to half its actual size and I get some weird glitches in the other half of its actual, in normal start somehow not used, size.
What I tried out:
I changed the size manually, not via "Dock = Fill" or "Autosize = true" and it worked. But that's, as you all may know, not the best solution and we only want to use it, if there is absolutely no other way around it. No one likes to hard-code.
I tried to inherit its Parent's Size via:
this.tablelayoutPanel.Size = this.Size;
and
this.tableLayoutPanel.Size = new Size(this.Height, this.Size);
So do you guys have any ideas?
Okay, I did not figured out why the debuger worked and the release/debug build not. But I just forced a redraw on the tableLayoutPanelMainwith with Application.DoEvents(). I never tried this out before, because Invalidate() + Update() or Refresh() did not work - I was like: okay, that wont be that easy, so just forget about that.
But after some trial & error and a lot of time...well, I was working for two weeks on it...I tried the simpliest thing out and YEAHY, it worked!
Anyways, thank you for your help, guys. I appreciate that.
Related
Basically, it has been 3 days since I'm trying to resolve this issue. I'm coding a sort of Mail Client in C# - everything was working pretty much good, while I started getting this unhandled exception... I would like to post a code section, but I do not know exactly what it causing this problem. A good fact is that the project is pushed over Github. Over internet it is said that maybe some variables used on some loops may cause the problem; I've already tried to edit some parts, but unluckily nothing worked...
Latest edit:
Added a Bunifu.Framework.UI.BunifuFlatButton over a UserControl. On click event, this happens:
MessageBox.Show(settingsControl.FLAG.ToString());
- I was testing if this would print me the int FLAG variable taken from another UserControl called settingsControl.
Every suggestion is appreciated. Thanks!
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.
Most simply explained, when I edit, delete, or add code into my XNA project, it does not respond. This is to say that I can comment out the entire Update method of my game and it will run as usual. This also means that the game is stuck at a certain time in development, and can not be edited. I've tried reopening my project and it does not help. I've had this problem before and it is incredibly infuriating and frustrating.
http://puu.sh/1kD6P
This is an image where I have commented out the Update method and would normally never be able to run with 66 errors. But it does run.
In the past I have had to create new projects and drag all of my art assets over and copies of the code. That is the only way I know to fix it, but this has happened with every one of my projects (even on a different computer before).
Anybody know what's going on?
Have you tried rebuilding it from the build menu, not just clicking the debug button?
So, I made a program in Visual C# 2010 Express. Finished enough to work, and pretty darned good for my first attempt at the language. But then I foolishly decided, "Hey, this program needs a close confirmation dialog before I send it out!" So I write the function, and then I go into the auto-generated code to bind said function appropriately.
KABOOM!
Now, the form designer shows a blank form, and all those shiny components have all been erased from both the designer and the auto-generated code. Which, in such a simple program, is about 80% of the work I put into it.
Now, in NetBeans, I would right-click the file's tab, and just go back to a previous version, maybe losing about 15 minutes of work. This is a pretty obvious concept, I'm just not sure where to find file history in Visual Studio. So, where is the equivalent so I can get my work back?
(I've also managed to get my code back by just undoing a whole bunch - but the designer doesn't see it, and neither does the compiler, so it still builds to a blank form.)
Sadly, you've just learned a couple of things.
One is to never, ever modify designer-generated code. In fact, C# has a concept called partial classes which allow you to modify a generated class without having to modify the generated file.
Second, that Visual Studio in and of itself has no built in source code control -- you need to choose the one you like and be diligent in using it. Some of the most popular are git, subversion, mercurial, and Team Foundation Server. I personally use svn, but the others are good too. Avoid something called Visual SourceSafe (VSS).
From the sound of it, I'd say you tried ctrl-z until some point in your code, but not in the designer?
Performing multiple "undo's" in the code-behind file where you put your code is one thing, performing "undo's" in the designer is another.
Hopefully, you have not closed visual studio yet, and viewing your now blank form in design view, and trying a bunch of ctrl-z presses there, might do the trick.
Actually the controls are not lost from Design code or Initialize
Component() ,make sure that whether check
Initialize Component() { this.controls.add("Where the control was ")
}
Example:
1-this.Controls.Add(this.panel1.label1); 2-this.Controls.Add(this.panel1.label2);
either in form you can write like below
should write in the Initialize Component()
this.Controls.Add(this.label1);
I had a similar effect: the code wasn't lost because the project compiled perfectly but I only got a blank form in designer.
This was because the form was inherited from another form, and I added in the Load event of the base form the line: this.MdiParent = Application.OpenForms("BaseForm");
After deleting this line (and recompiling) I could access the design of the descendig forms again.
One thing you could do, it won't help you this time, but may be a good idea for the future - if you copy your code alot (like I do), get one of those clipboard savers - like ClipTrap (which is lightweight, simple, and great).
Then, if you realize you can't undo what you did, then you get a second chance by running through the "trapped" text to see if what you want might just be there.
Another good option is to try something like AutoVer, which will save a copy of any changed file (or files in a folder) every so often as you like. This could provide you with a backup of your codefile, or even the entire project - every five minutes, or every minute as long as something has been changed. Awesome program. This is a certain fashion of source control, or at least source backup.
(And no I'm not the authour of either application)
However, for your particular problem, if the code is still there in your designer.cs page - maybe you just erased a reference or a namespace. Make sure the namespace matches, and make sure your in your form's code file, that the InitializeComponent(); function is being called (that's what places all the designer's controls onto the form, you know).
In the code behind file click 'undo', not in the designer window. Accept the warning, and when the code comes back, the form should be back to normal, Visual Studio 2015.
When I run my application, do some work on it and click the language button on the Windows taskbar and change the input language, my C# application freezes displaying an hourglass cursor. Does anyone have any idea on what may be going wrong? I have absolutely no clue where to start...
First of all, your problem is hard to follow, since we don't know what is going on in your application. Neither we know which exactly code in your application freezes.
For others, the problem in your application is not clear. So having this quite weakly defined problem, it's hardly possible that someone can help.
You can do the following in order to resolve the issue:
Try to build a minimal test case, which reproduces the problem. Usually you'll need to start with a copy of your source code, and remove features until the bug is not reproducible any more.
After this, you will most likely see yourself, where the problem is.
If not, you can post the example and the changes which make the bug happen. Please kindly try to remove as much as possible from the example, leaving only essential part.
This way you will most likely have your problem solved.