1

I have currently an application that have various forms that are basically about scanning some barcode/RFID tags and displays the List.

As such I have some generics components and even a generic sub forms used by others forms.

Basically this form contains :

  • A top bar with some labels about how many objects were scanned
  • A customized ListView in the center
  • A bottom bar with a "cancel" and "save" button.

Currently this forms take in his constructors two delegates, each of them is called when clicking to the corresponding button in the bottom of the form.

By doing that, I'm entirely delegating the cancel/save action and the closing of the current form to the parent form. Note that the condition for the save button to close the form and save the data change depending of the caller.

This application is basically my first step onto the C# world. I know about events and use them in others part of my application but it doesn't seems to match this specific requirments. However since I didn't/Read a lot about C# I am not sure about the approach that I choosed, but obvisouly that deson't seems the standard way of doing it.

So here is my question :

  • Does using delegates instead of events for this specific requirment is how it should be handled ?
  • At a higher level, is my design about the generic forms called from many specific form good or did I miss something ?

Note :I have very specific constraint : it is for embedded devie with compact framework (a subset of classic NET 3.5 Framework where I don't have all the classes and the available classes don't have all their classic methods/attributes available).

Improve this question
7
  • Are you using a Model-View-Presenter pattern?
    – RubberDuck
    Oct 12, 2017 at 9:23
  • No, I have business object with services that handles the stuff like loading them from files and sync with a servers and several forms to interact with the users. Usually any basic actions requires often 2 forms, one for some specific metadata, and the other which is the form I am talking about.
    – Walfrat
    Oct 12, 2017 at 9:30
  • 1
    If you're just using the code behind, then you have an okay solution with your delegates. It's not common, but not bad either. I would recommend looking into the MVP pattern though. That paradigm tends to be much cleaner and that case would use events. Another important thing to remember is that events are just fancy, inverted control, delegates.
    – RubberDuck
    Oct 12, 2017 at 9:34
  • I have a components is a customized ListView, it is basically a ListView made specifically for what I am looking with some specific set of rules, one of them for instance is not ignore duplicates because if you scan with UHF RFID multiple times, you will see the same value multiple times. The generic form is an higher layer using that generic component. The model is hold by the caller form (usually showing some fields for metadatas to select/type) that pass his datas, co,nverted eventually to that generic form.
    – Walfrat
    Oct 12, 2017 at 9:44
  • I have read the basics about MVP and even MVVM but I have neither practiced them thoroughly. If you think that I am a bit vague, it's because I have more than one of the generic forms built on the top of a customized Control so I try to stay generic.
    – Walfrat
    Oct 12, 2017 at 9:45

1 Answer 1

Reset to default
1

WinForms and CE devices are some of the more arcane bits of the .net framework.

However, I think that passing in delegates like that is an unusual approach for c# and .net. Not to say it wont work or is bad, but just that I think it would be more usual to have the form or control raise an event to which the parent object binds.

Also I would consider not having generic forms and calling the code from the ButtonClicked() method. Obviously if you have a generic control you want to reuse lots this isn't a good method. But it would be the 'standard, hello world' way for WinForms.

Improve this answer
1
  • I'am definitively asking this because I felt it wasn't the standard way of doing it, but : In fact I'am now realizing that I was trying to intercept the classic onClose event and eventually cancel it when I could just have custom events. Note that my generic forms inherits the basic System.Windows.Forms.Form object, but if I switch to event based solution, I think I should go for a composition over inheritance solution, so I only expose my events and mask the form to the caller (just expose my events and a Show/Close proxy methods).
    – Walfrat
    Oct 12, 2017 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.