Coincidentally, I am working on a WinForms project that is patterned after MVC. I wouldn't call this a perfect answer, but I will explain my overall design and hopefully this can help you come up with your own.
Based on the reading I did before starting this project, there seems to be no "right" way to implement this. I followed simple OOP and MVC design principles and the rest was trial and error as I developed a workflow.
Is MVC simply an inappropriate architecture for this use case?
No..? There is not enough context in your question to provide a direct answer to that. Why are you using MVC in the first place? What are the non functional requirements of your project? Is your project going to be very UI heavy? Do you care more about security and would rather a layered architecture? What are the main components of your project? Perhaps each component needs a different design pattern. Find out why you want to use this design pattern in the first place and you might answer your own question ;)
My reason for using MVC: its a fairly simple design pattern to understand in my opinion and my design is based heavily on user interaction. The way MVC allows the developer to seperate concerns is sufficient for my application as well. This makes my code alot more maintainable and testable.
I also suppose I am using more of a hybrid design. Usually, the ideal concept presented in software engineering does not actually play out in practice. You can modify the design to suit the needs of your project. No need to get caught up in what is right or wrong. There are general practices, but rules can always be bent or broken as long as you don't shoot yourself in the foot.
My implementation started with a high level design which gave me an idea on what components I will need. Its best to start this way and work your way down in the architecture. Here is the package diagram for the project (created in StarUML):
Notice every single layer except the presentation layer depends on the Messaging System. This is a common "language" which the lower layers and sub systems of those layers use to communicate with each other. In my case, it was a simple enumeration based on operations that can be performed. Which brings me to the next point...
Think of operations or commands as the basis for your implementation. What do you want your application to do? Break it down into the most fundamental operations. For example: CreateProject, WriteNotes, SaveProject, LoadProject etc. The GUI (or Form classes) are going to have some event occur (like a button press). Every operation has a controller method associated with it. In this case something like Exit is too simple. The application can simply be closed from the Form class. But suppose I wanted to persist some application data to a file first? I will call the "Save" method from the respective controller class within my button press method.
From there, the controller will call the correct set of operations from the Service classes. The service classes in my application act as an interface to the domain layer. They will validate input received from the controller method call (and thus from the GUI) and manipulate the data model.
Once validation and the corresponding object manipulation is complete, the service method will return a message code to the controller. For example, MessageCodes.SaveSuccess. Both the controller and service classes were based on the domain objects and/or the general set of operations that can be grouped together.
For example: FileMenuController (operations: NewProject, SaveProject, LoadProject) -> ProjectServices (CreateProject, PersistProjectToFile, LoadProjectFromFile). Where Project would be a domain class in your data model. Controller and Service classes in my case were non-instantiable classes with static methods.
Then, the controller recognizes the operation as completing un/successfully. Now, the controller has its own messaging system which it uses to interact with the presentation layer, hence the double dependency between the Service and Presentation layers. In this case a class called ViewState in the ViewModels package is always returned to the GUI by the controller. This state contains information like: "is the state you tried to put the application in valid?", "a human readable message about the operation you tried to perform and why it was or was not successful (error messages)" and a ViewModel class.
The ViewModel class contains relevant data from the domain layer that the GUI will use to update the view. These view models look like the domain classes but in my case I used very skinny objects. Basically they have pretty much no behaviour, just relay information about the lower level state of the application. In other words, I am NEVER going to give away my domain classes to the presentation layer. This is also why the Controllers and Services packages split the service layer into two parts. Controllers will never handle domain classes or validate their state. They just act as a boundary converting GUI relevant data into domain relevant data the services can use and vice -versa. Including the service logic in the controller would lead to very fat controllers, which are harder to maintain.
I hope this gives you a starting point.
Best Answer
The Controller should be just as dumb as the View.
So in this case, we need to ask about responsibility.
Views are responsible for UI elements and displaying things. Controllers are responsible for connecting Views with Models and providing data for the View to display.
A Controller should be dumb about what the View has within it, buttons included. So the View should be responsible for enabling / disabling the button.
Keeping the Controller oblivious of the View allows you to more easily decouple the View from the Controller and have multiple types of Views reuse the same Controller.