Why would you not want to have a dedicated control for this?
Because a dedicated control is not necessary, and doesn't promote separation of UI from business logic.
Today I need a combo box. Tomorrow I may need a listbox, next week I may need a listview, treeview, etc..
Am I supposed to write (how many?) dedicated controls of different types for each circumstance? Or, should I use generic controls, and put my business logic in a separate layer that can be easily reused by many different types of generic controls, and thereby avoid replication of the business logic.
Your example violates one of the most fundamental principles of good design, which is that it fails to separate business logic from the UI layer, and I'm not going to explain that in detail, because you can find plenty of discussion and explanation about that all over the internet.
So, it is not just one 'dedicated control', it is potentially many dedicated controls of different types.
If you hold a myopic view of the problem, you will only find yourself throwing code out and rewriting again many times over (or worse, copying and pasting it here and there) because you didn't anticipate future or varying requirements.
I'm sure there are generic controls out there that you can put images and text into them in all sorts of flexible ways, but would it not be easier to have a control that is designed to draw the Block, Linetype, or Layer exactly the way it should be?
I can draw those things exactly the way they should drawn using well-designed generic controls. They're just bitmap images, nothing more special about them in that regards.
Where do you put the implementation to gather up all of the images and text for the Symbol Table Record and give it to your generic control in just the right formatting?
That question would seem to suggest that you've yet to discover data binding.
I'd suggest you research the concept of data binding, because it eliminates the need for dedicated code to 'gather up all the images and text', and also eliminates the need to manually load items into list-type controls as well, and makes the entire process generic. When you use data binding, the control itself gets the items to display in the control, and the data that is displayed for each item, with no code required on your part.
When you use data binding, you just give the control a data source that exposes a collection of the objects whose data will be displayed in each item in the control, and you give the control the names of the properties which the control will use to get the data from each item (e.g., the Name and BlockIcon properties of the BlockTableRecord would be the ones that would be used if one is directly binding to BlockTableRecord, which is not wise for reasons I cited earlier).
The reason why data binding is preferred for providing data to the UI is because all types of controls support data binding to data sources
in a consistent way, and that is what allows the same business logic to be re-used with any type of control that supports data binding, with no need for special or control-specific code.