CODEWITHSUNDEEP
c#.netdriver
WildM
WildM

Reputation: 135

Modifying C# code to work both with and without device drivers

I'm currently working with a program that can interact with a peripheral device that our customers may or may not buy. This device has been a bit of a pain; the company that we are purchasing it from wants our customers to use the company's own executable to install the device drivers.

However, since not all of our customers will be purchasing the device, it would be useful if they didn't have to always run a second executable to get our software working. In order to make that possible, I would need to modify our program to work both with and without the drivers.

ActiveX controls are used to interface with the device. These need to be put into the GUI using Windows Form Designer; instantiating the control manually leaves it prone to crashing, irritatingly enough.

Is there any "best" way that one could set up a program to detect missing drivers and avoid crashing? The only ideas that I have thought of are:

  1. Instantiate the controls manually and use try/catch statements to detect and handle missing drivers, but I don't think that this solution is feasible.
  2. Create 2 versions of each form that may use the device. This is a poor idea because it would require careful copying when changes are made on one version of the form.

Upvotes: 0

Views: 185

Answers (3)

rare
rare

Reputation: 134

System.Management.SelectQuery("Win32_SystemDriver");

Upvotes: 0

Gregory A Beamer
Gregory A Beamer

Reputation: 17010

My method would be to determine driver or no on startup (install would be an option if the the device cannot be added later).

You then set up a "global variable" (I would aim for a Singleton for this type of application value) that states whether or not the drivers are present. You can then fork the code based on whether this value is true or false.

What I don't understand is why the User Interface is tied to the driver being present. You should be able to shape the data for the presentation layer deeper in the stack and avoid "the UI blows up when the driver isn't present". You may still need some logic specific to "the driver data is present", but that is fairly easy to handle without worrying about walking a minefield.

Upvotes: 0

Hogan
Hogan

Reputation: 70538

Typically the best choice in cases like this is to use a Facade or Adapter pattern, often in conjunction with a Factory.

Create an Interface to the device that supports the device not existing and then implement two versions of the interface, one which implements the functionality and one which reports it does not exist.

Then each UI which uses it will call a factory to create the instance object (one of the two choices above as needed) and query that to object via the interface to show controls or surface functionality.

The rest of the UI elements will stay the same and will not need to be maintained in two places.

Upvotes: 1

Related Questions