does a singleton StatusBar controller sound corrrect?

[giddy]

hi ,

Does a singleton statusbas controller sound correct. I mean , is that
how its done?

I have a big app and i need to control the statusbar from within a
number of custom controls , dynamic menus and toolbars etc. So should
i have the aforementioend class? I'm thinking singleton so its
instance is globally accesssible?

Gideon

 

[Nicholas Paldino [.NET/C# MVP]]

Gideon,

You could, but honestly, I dislike the idea. By exposing the control,
you are really asking for some trouble.

What I like better is a static method which you expose, something like
"UpdateStatus" which takes a string and then updates the status bar
appropriately. This way, you don't expose the status bar and mistakenly
expose functionality you don't want which can be used to compromise main
window.

The option I like the most would be to have all custom controls
implement an interface, something like this:

public interface IMyApp
{
void SetStatus(string status);
}

public interface IMyAppCustomControl
{
void Initialize(IMyApp app);
}

When you create the custom controls in your app, you would call the
implemented Initialize method, passing the IMyApp implementation (which your
main app window would implement). This lets you abstract out the
functionality, in case you make major changes to the main window.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

hi ,

Does a singleton statusbas controller sound correct. I mean , is that
how its done?

IT does not sounds correct, as a matter of fact it DOES sound incorrect. The
statusbar is just another control in a form, you should let the form control
it.

I have a big app and i need to control the statusbar from within a
number of custom controls , dynamic menus and toolbars etc. So should
i have the aforementioend class? I'm thinking singleton so its
instance is globally accesssible?

you better define an interface (that your forms can implement) in such a way
that it return the instance of the correct statusbar. Then you can just call
a method (defined in the interface) to make the update.

 

[giddy]

HI Nicholas ,

thanks so much for that design =) . I can see why it makes sense , but
besides that it helped me code this taskpane which sometimes needs to
control certain aspects of the main form! =P

Gideon

 

[PS]

hi ,

Does a singleton statusbas controller sound correct. I mean , is that
how its done?

I have a big app and i need to control the statusbar from within a
number of custom controls , dynamic menus and toolbars etc. So should
i have the aforementioend class? I'm thinking singleton so its
instance is globally accesssible?

I think the other posts did not understand what you were going to do. A
singleton controller class is a good idea. I assume that the status bar will
monitor a Status type event and that the forms will call an OnStatusChange
method. Therefore there is no dependency between the form and the status bar
and the status bar and forms remain closed to direct modification.

PS

 

[Jon Skeet [C# MVP]]

I think the other posts did not understand what you were going to do. A
singleton controller class is a good idea. I assume that the status bar will
monitor a Status type event and that the forms will call an OnStatusChange
method. Therefore there is no dependency between the form and the status bar
and the status bar and forms remain closed to direct modification.

It does, however, make the assumption that there will only be one form
open at a time which needs status information. I'd rather pass around
something which encapsulates the idea of "when you need to indicate
status, use me" than put it in a singleton.

On the other hand, if there definitely *will* only be one instance of
the form, then it's certainly simple to use a singleton. It's just a
somewhat tricky assumption to undo later on.

 

[PS]

It does, however, make the assumption that there will only be one form
open at a time which needs status information. I'd rather pass around
something which encapsulates the idea of "when you need to indicate
status, use me" than put it in a singleton.

On the other hand, if there definitely *will* only be one instance of
the form, then it's certainly simple to use a singleton. It's just a
somewhat tricky assumption to undo later on.

Good point. I am working with the idea of one "main" form that is then
loaded up with controls that then load controls etc in a single document
interface style.

 

[giddy]

hi ,

Acutually i had only one idea in mind , controling certain aspects of
the Form. Like the other userControls should be able to
1. Add a tab to the main tab.
2. Send a document to the main print engine.(in the main form)
3. Set a label on the status bar
4. Set a progressbar on the status bar and change its progress.

fo i made something like:
public interface IControlableForm
{
void SetStatus(string text);
void SendToPrint(IPrintableDocument);
void AddTabPage(Control control);
void ShowProgressBar(); //not sure about these since i havent added
them yet?
void SetProgress();
void HideProgressBar();
}
So , probably if i have to make a new MainForm , i just need to expose
this interface!?

Thanks

Gideon

 

[giddy]

Whoops ,

interface for the usercontrols:

public interface IControlsForm
{
public IControlableForm
{
get;
set;
}
}

I just thought it would be better to have property instead of a
method like Nicholas mentioned?

Thanks

Gideon