Should every class be a singleton?

Question

C++ / C#

For example, there are two classes, the first class implements the main menu, the second - the auto selection menu, between these two menus, of course, interaction is necessary, and in order to organize it, I know one way - using a singleton. And in general, such a situation is that all classes that must interact are obtained by singletons, that is, almost all of my classes are solid singletons. Maybe there are other ways for such interaction?
No, I'm not against singletons, I just don't know if this is the correct / optimized approach?
By the word "interaction" I mean the use by one class of the fields of another class, but so that the field values ​​are the same for all instances, which is what the above pattern actually does.

Answer 1

The task is not fully formulated. Is the auto select menu a main menu item ? If yes, then you can include one in the other. If not, then organize interaction through events and subscriptions.
In general, the practice of "sigletonirovanie" - vicious. In fact, you are transferring the logic of namespaces to a pattern that is not intended for this at all. Although, of course, a lot depends on the logic, the point of a singleton is not only to have access to it, but that it should be the only one for the entire application . That. the connection to the database for the server is a singleton, and the menu on many pages cannot, by definition, be a singleton.