Question A Bizarre Problem is Suddenly Occurring

[glasswizzard]

Hello, could someone help me with this perplexing problem that has suddenly decided to screw with me, I honestly have no clue how this happened, as far as I know I did nothing at all to cause this, it seems to me like Visual Studio is broken but I did repair it and the problem persists.

Suddenly in one of my projects my second form will not show properly. Here is a pic of what I made it look like (it has an empty listbox in the center):

It has always opened fine and looked like that but now when I open the second form (from the compiled program, not in the IDE) it looks like this:

The listbox control is not there, nor any of the properties I set for it, not even it's size. I'm not opening the form in any weird way either:

Form HistoryForm = new Form();
HistoryForm.Show();

I'm guessing you probably need more information but I don't know what that would be, just let me know and I'll post it.

Thanks

 

[jmcilhinney]

Look at the code. You are creating an instance of the Form class, not your own class that inherits Form. I'm guessing that your class is named HistoryForm, in which case your code should be something like this:

HistoryForm form = new HistoryForm();

form.Show();

Maybe you want to name the variable something more specific - maybe even historyForm - but at least use the correct type. Also, local variables like that really ought to start with a lower-case letter. Given that C# is case-sensitive, that would allow you to use the same name with different casing in the same context. That's generally not something you should do but in such a narrow context it is probably OK.

 

[Skydiver]

My first reaction to that was the "Ha! ha! Ha! The Windows Forms Designer corruption strikes again!". This is why Sheepings and I, having been burned too many times in the past, hand code our WinForms instead of the WinFoms Designer.

But on closer inspection, it is like jmcilhinney says above. Just happen to be instantiating the wrong class.

 

[jmcilhinney]

This is why Sheepings and I, having been burned too many times in the past, hand code our WinForms instead of the WinFoms Designer.

I find that totally bizarre. Any issues I may have had with the designer over the years would be an insignificant fraction of the time it would have taken me to hand code all my forms. I know that not everyone has the same experience but there is no WinForms designer problem as far as I've ever seen.

 

[glasswizzard]

Damn, I guess that serves me right for not paying more attention, that means that I manually changed it from what was correct recently and totally forgot. Yes it's a facepalm moment ?‍

Thanks for the naming tip too, I tend to expect the IDE to auto suggesting naming rules for me, but I'll drill that into my head.

 

[NoUserHere]

Just to be clear. There is also no known way to fix designer defects when they happen in Winforms, which is why I try to encourage people to move to WPF instead.

I know that not everyone has the same experience but there is no WinForms designer problem as far as I've ever seen.

You'd be mistaken. Just because you never experienced it, doesn't mean they don't exist. You can find many articles if you browse around for designer code corrupting a whole form with no fix. However, that can be avoided by handcoding your forms. This is also not the case in this topic though.

In regards to the way you are calling your form. This is correct if your form is actually named HistoryForm :

            HistoryForm form = new HistoryForm()
            form.Show();

This is not correct :

            Form from2 = new Form2();
            from2.Show();

Neither is :

            Form HistoryForm = new Form();
            HistoryForm.Show();

Your form not being correctly typed as Form2 form2 ... is confirmed to cause the issue the op is seeing.

Try calling your new instantiated object by its declared name, not its type, followed by its new instance name, and its instance as demonstrated on the second post.

 

[glasswizzard]

WPF does sound like the business doesn't it, this is the first I'm hearing of it. If I did switch, what would I have to relearn?

 

[NoUserHere]

Winforms vs WPF | Learn The Top 6 Most Awesome Differences

Overall, some of the ways you would invoke controls is done differently in WPF as it is in Winforms; for example in WPF, you will use Dispatcher.Invoke. While some aspects of Threading are also different. There is a vast learning curve to WPF overall and its not what you are used to in Winforms, and it does take some getting used too. Almost everything is different in WPF and it comes with a whole new design interface too. You construct your UI with Xaml and UI's are much faster, modern and stable than Winforms. Winforms is nearing its EOL, and there really isn't any reason why anyone should be creating Winforms projects while WPF is an option, and an obvious contender in my opinion.

 

[glasswizzard]

Hang on a minute, is that what is used when creating a UWP app? I've been playing around with that, following tutorials and such (but mainly focusing on WinForms) and if that's the same thing then I'm definitely up for learning it, I quite like it.

 

[Skydiver]

Although both WPF and UWP use XAML, the code that is generated from the XAML and used to drive the UI are two completely different technology stacks. WPF mostly uses managed code and the .NET Framework, while UWP runs native to OS.

The following maybe useful: WPF vs UWP

 

[vritik]

.NET WPF vs UWP
WPF is a part of . NET Framework and therefore runs managed code. UWP instead uses . ... Although it is still supported, no new features are expected for WPF in comparison to UWP that is currently in development. here you can get autocad learning

 

[Skydiver]

What's Autocad got to do with this thread?