1 Replies - 659 Views - Last Post: 24 April 2014 - 05:50 AM Rate Topic: -----

#1 TheGrovesy   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 56
  • Joined: 17-October 13

Creating controls which act differently depending on mode

Posted 24 April 2014 - 12:51 AM

Hi all,

I am creating a C# windows application which allows it to connect to our devices and communicate with them.

Often we need to customise this application and I have made this easier by defining its appearance and actions within an XML file which gets read in every time the application starts up. This is working really well.

However editing this XML file can be pretty laborious and often requires many cycles to get everything correct again. So I have started to create a graphical editor which allows for the XML to be generated.

The problem I am facing is that I am using the same controls in the final program and the editor so my question is how should I structure the code so that each control knows when it is in "Normal" mode and when it is in "Edit" mode?

I have started using a simple boolean flag to indicate its mode, however this now means that within every function I need to check this flag and run code appropriate to that mode, this seems a bit over the top. Is there a better/standard way this sort of this is done?

Many thanks

Is This A Good Question/Topic? 0
  • +

Replies To: Creating controls which act differently depending on mode

#2 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6216
  • View blog
  • Posts: 21,461
  • Joined: 05-May 12

Re: Creating controls which act differently depending on mode

Posted 24 April 2014 - 05:50 AM

Sounds like the perfect place to apply the Strategy pattern. When you instantiate the class, you only check once whether it should be in Runtime mode or Designer mode, and then instantiate a class that contains the appropriate implementation for that mode.

As an aside, the old-style MFC and ActiveX controls from before 2005 typically had the same type of code you have now where a flag is checked every time for each little bit of functionality. Most ASP.NET WebParts still do things that way. On the downside, it does make a major mess of the code, but on the upside, you get to see both sides of the behavior in one place instead of having to jump between files.

(I spent three weeks trying to unravel a web part which features a 3000 line method that acts differently between runtime and design time. Needless to say, I started applying the strategy pattern when I started rewriting it from scratch.)
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1