Application design related question

Background:
I'm just writing a small home project at the mo, which contains the following classes:

1. Windows form for input and to call processing methods.
2. SubtitleFile abstract base class
3. SRTSubtitleFile class which inherits the above, but is specific to a *.srt subtitle file.

The project shows the form/UI allowing a subtitle file to be chosen. This form in turn instanciates the SRTSubtitleFile class and runs some of it's methods.

Question:
Though I don't really need to extend this any further, I wanted to do things properly. :p So I was wondering, could I have everyones thoughts on the best way to expose the formats/types of subtitle files I'm supporting here please?

Currently I have an open file dialog control and I'm setting it's filter property to a hardcoded string to limit the files to those with a *.srt extension, but I really wanted to move away from this hardcoded implementation.

Thoughts so far:
Below I've listed a few thoughts I've had, but perhaps there's a common practice for this idea? Thanks everyone! :bigyello:

1. 1) To add an Enum to the form (downside: if moving the subtitle bits to their own project in the future, the file types aren't exposed by any of these classes)
2. Exposing an enum of file types from the SubtitleFile abstract class (neater, but downside means remembering to maintain this file rather than just adding in a new class/classes representing the new subtitle format)
3. Exposing a property from the SubtitleFile abstract class which (maybe through reflection) evaluates and presents a list of all inheriting class names or property values (it just doesn't seem good practice to expose this from the SubtitleFile abstract class to me).
4. Creating a separate SupportedSubtitleFormats class, and performing the evaluation and exposal of the formats from the classes inheriting SubtitleFile (utilise the inheriting SubtitleFile classes, or use the next point)
5. Creating a separate SupportedSubtitleFormats class, then creating separate SRTSubtitleFormat SUBSubtitleFormat etc. classes which expose the format name and filetypes (utilise the inheriting SubtitleFile classes, or use extra classes and split off the file type information)

At the moment I'm thinking the last one, and I guess trying to take a look at reflection to get the inheriting classes & their details which might be overkill. Then whether to expose these child SubtitleFileFormat classes via the related child subtitleFile classes. Any and all comments/ideas/thoughts/opinions/random suggestions are warmly welcomed! Thanks again. :)

Thread Moved

If the whole point is to be able to alter the user interface depending on each different class that inherits from SubtitleFile, I would change the design so that SubtitleFile is a user control with the needed elements on it. Each different class that inherits from SubtitleFile will implement its own look and feel and the form would just need to show the control.

I'd do #1 or #2. I wouldn't spend too much time dwelling over this issue because I don't want to end up with a configurable configuration configurating configurator by attempting to 'OOP' everything (from previous gen-dev discussions if you recall).

Just about any choice can be justified... so I'll justify #1 or #2 by saying that the enum allows me to enable or disable certain SRT files. :D

Thanks for the replies guys (and :afrog:'s)!

@NTG: - Yep this was a GUI question at the moment. :) Basically the UI just allows for a subtitle file to be chosen, a +/- number of seconds to be chosen and the each subtitle of that file offset by the specified number - nothing fancy really. So the user control idea isn't really appropriate for this particular situation, but thanks for the helpful suggestion.

@:afrog: - Normally I'd go with the first one myself, was just trying to think along the lines of all the processing's done from the non-form classes, all the form needs to do is allow a verified file (*.srt for the moment, maybe *.sub in the future) is chosen then hand everything off, so perhaps it's code and design of the form could stay static and it could evaluate the list of files from another source (class, or if I turned the subtitle processing classes into their own project in future etc.). However very valid point on the whole OOP overkill warning. I was trying to think a better, more professional design/OOP way as I'm not really constrained by time or cost (for a nice change) but this point still holds true for a home project I imagine also & maybe I should stick to the enum. :p

Again thanks for the suggestions and advise guys, it's great to get other professional's opinions here. Much appreciated! :) :thumb: