Tips on runtime-customized UI

[Dave]

Hi,

In the past, I've designed single screen interfaces, without much need
for allowing the user to customize anything except the size/state of
the main form. However, I am redesigning the application and hope to
allow the user to both select and position elements out of a list of
possible ones. I have very little idea how to go about this. As an
example, I provide a list of 10 charts, a table, some gauges, etc. and
the user can decide which elements to display, and where to place them
on the form (along with size, etc.). My initial idea was to just use
different forms for each element, but that gets messy on the screen.

How would I go about implementing this? Should I use an MDI main form
with small toolbox type forms for each element? If so, how would I go
about allowing them to dock each form somehow to provide a clean
looking interface without each form having a toolbar or borders? Or am
I overlooking a really simple way to accomplish this? I'm willing to
entertain the idea of a 3rd-party control to do this, but I have very
little money for it.

Thanks,
Dave

 

[Dave]

Hi,

I should mention two other things:

1) How do I give each element a common interface so I can send it data
from the main form (or rather, a processing loop in a separate thread?
For example, I have a Data object; how do I force each element to take
in the same parameters such that each data processing interval I can
simply iterate over each shown form and pass it the data it needs to
update?

2) How would I best implement a plugin system that would allow us to
send a simple DLL to allow the user to extend the application with
elements that may not have been available at compile-time? Not looking
for specific code necessarily, just a general architectural overview.

Thanks!

 

[Ross Culver]

Have you tried working with a FlowLayoutPanel control? Or you could use a
collection of SplitContainer panels with the AllowDrop set to True.

Ross

 

[Andrew Faust]

Take a look at the code Visual Studio builds for you automatically and
places in the .Designer.cs class. Everything it's doing there you can do as
well to create dynamic objects on your forms.

1) How do I give each element a common interface so I can send it data
from the main form

Probably create some interface that exposes the methods you want. Maybe
something like GetData(). You'll then need to create controls that extend
all the controls you want to be able to use on the form and have them
implement that interface.

2) How would I best implement a plugin system that would allow us to
send a simple DLL to allow the user to extend the application with
elements that may not have been available at compile-time?

Depends on what your needs are. Do the controls they build merely need to
have a common set of methods that your code can call? If so then you can
create an Interface that all the plugin controls must implement such as:

interface IDataControl
{
void LoadDataSet(DataSet dataSet);
}

Your users can then create new controls that implement this such as:

public partial class CustomControl1 : ComboBox, IDataControl
{
public CustomControl1()
{
InitializeComponent();
}

public void LoadDataSet(DataSet dataSet)
{
throw new Exception("The method or operation is not
implemented.");
}
}

On the other hand. If there are any base operations that each of these
controls must do that you want to implement for them then you would need to
create a base class that extends from Control that has that common
functionality in it. Your users would then extend that class to build their
new controls.

I would recommend avoiding the base class for this usage, though. By using
the interface route you allow your users to easily leverage existing
controls such as combo box, list views, etc. Wheras requiring them to
extend from your class burns their base class and would force them to
implement their own brand new versions of combo boxes, list views, etc.