# Visual Basic > Visual Basic .NET > VS 2022 [RESOLVED] Inherit a Control

## Shaggy Hiker

I may have asked this before, but this question is possibly simpler:

I have this code:


```
Public Class FlickerPanel
    Inherits Windows.Forms.Panel

    Public Sub New()
        MyBase.DoubleBuffered = True
    End Sub
End Class
```

It sits in its own file with the name FlickerPanel. VS recognizes it as...well, as something, as the icon looks like it might be for a User Control, or some such. It acts like a User Control, as it shows a designer and prompts me to drag things over from the ToolBox, or to go to the Code View to add methods, which wouldn't happen for a normal class that would only have a Code View.

If I use this control in a form, by replacing a Panel in the .designer.vb file with FlickerPanel, it compiles without error. Furthermore, running the project shows that the panel works. A normal Panel in that form will flicker badly, whereas this one (which should really be called AntiFlickerPanel, but whatever) is as smooth as I could ask for. 

Unfortunately, the designer for the form won't show. The form designer error page is shown with the error message that the class FlickerPanel can't be found, which is clearly not true, because the code compiles fine and it is working as expected. VS recognizes the control, it compiles without issue, it works as intended, but the form designer suddenly has no idea what it is. One further thing to note is that this very code was displaying without issue in some earlier version of VS (certainly 2010, possibly 2017 or 2019).

Is there some registration step I have to take for the VS form designer to be able to find the control?

----------


## Shaggy Hiker

The plot thickens.

I followed this link:

https://learn.microsoft.com/en-us/do...orkdesktop-4.8

And performed the exact steps MS is laying out in that link. What I ended up with was slightly different from what I had before. For one thing, there was a .designer.vb file associated with the control file. So, the inherited control looks a whole lot more like a User Control, now. In fact, it showed up in the Toolbox. All is working well with it...right up until I tried to do the same thing with a control in a different dll, which worked, but then I went a step further. In that other dll, I was using the AntiFlickerPanel control as a component in a User Control. The User Control still couldn't be seen, so I added a new User Control on the assumption that I screwed something up the first time. I then tried to drag the AntiFlickerPanel control from the Toolbox to the new UserControl. It promptly said that there was something wrong with the control and that it would be removed from the Toolbox....which it was.

I then went back to the dll project where I had first fixed the problem, added a form, and tried to drag the control onto the form. It, too, said that there was a problem and removed the tool from the toolbox. Nothing I have been able to do can get it back in the toolbox, though I do know how to do that (make a new control, it will show up until it is first used, then be removed from the toolbox). 

I then took a look online to see whether or not anybody has had this issue. There's a fair amount about it, but all from over a decade back. This is VS2022, a solution from VS2012, or earlier, is a bit out of date.

It seems like nobody has had this issue. Recreating it is trivial, especially following the steps in the link I just provided, but with the code from the first post (you will be prompted to add an InitializeComponent() call to the constructor). For me, this creates a new control which promptly shows up in the toolbox. Any form can be built with the control and it works, but can't be displayed in the designer. Any attempt to add the control from the toolbox will not just fail, but will cause VS to remove the control from the toolbox.

This seems like a remarkably simple thing, and yet the behavior appears to be consistently broken.

EDIT: After a bit more searching, I found what might be a clue: This used to be an issue where the form designer ran as a 32-bit process and this very issue would happen when somebody tried to use a 64-bit control. I believe that VS has switched to being fully 64-bit in the last few versions. All of the code in all the dlls I have tried this in are compiled for x86, so they are obligatory 32-bit. Perhaps MS has flipped the script. Where it used to be that a 64-bit user control wouldn't show up in the 32-bit form designer, perhaps now a 32-bit control won't show up in a 64-bit designer. I guess I can test that.

SECOND EDIT: Yep, that appears to be the case. I created a 64-bit dll, added the exact same AntiFlickerPanel in the exact same way, and it can be used in the designer. It appears that the designer simply won't show anything using a 32-bit control, though the compiler has no issue with them and they run fine.

Can I just say how annoying this is? There was some reason why I built all of this as 32-bit. I don't know whether or not those reasons are still valid anymore, or not. That decision was made back in 2009, so the reason that was valid at the time may no longer be valid. Not being able to see custom controls in the designer in a 32-bit project is annoying, to say the least. Not a deal breaker, though. It just means that any work with them requires either putting a Panel on the form, then editing the .designer.vb file to switch from a panel to the user control, or just building it all either in the .designer.vb file or creating the control on the fly.

----------

