That's the standard pattern. If it's not working, there's something you haven't told us and/or are not showing us.
The code listed in the first reply is the way to do it, so long as the controls were created on the UI thread and your long-running code is on a different thread, be it directly launched with the Thread class, a Task or in a BackgroundWorker.
one of the console applications I wrote is about to get modified to do a similar job to the one it was first designed to do.
Its command-line parameters parsing works. But I never have been really happy with it. This example
tool.exe SetDo FirstLed On
should make an attached device switch its first LED on, obvisously. And it does so.
What bothers me is that SetDo has to be the first parameter, FirstLed the second and On the third. No way for the user to put an option before SetDo.
Since the modifications will change the possible actions anyway, I thought of finding a more standard library instead of using my own parsing.
First I checked the GNU getopt .NET port[^] and found using it horrible. You have to specify a format string, only for one-character options and a switch statement that matches the format string. Then you can attach long options that use a short option to determine what action they trigger.
That approach appears to be inspired by sprintf's format string[^], which we all know about and that it works. It just is so unintuitive to use from a programmer's point of view.
My second try was Mono.Options[^]. It doesn't require a format string. You just have to fill a generic list with one object per supported command. Short and long option names are supported in the object's constructor, along with a description of the command (for the auto-generated help screen) and a method to call during runtime.
Now I recognize that there's still a lot of work to do by hand since not all my options are boolean switches. The example I gave above uses two enumerations, one that holds all possible digital outputs to manipulate, the other for the state that should be the result of the manipulation. It doesn't look like there is an easy way to get that into the auto-generated help file, nor that the parser can handle situations like "Option A must preceed one of enum B's values followed by enum C's values", does it?
Does anyone know of a command-parsing library suitable for that?
Or should I rather tweak the working one into having my options position-independent?
Yeah, we have no idea what else he's got to control, nor how he has to refer to them. The LED=n might work for him but it really depends on the complete list of items he needs to control and the verb and value options available for each of those. When he knows that, then he might be able structure a standard format command line if there are a lot of possibilities or, if not, simplify it to what you've said.