Design questions

[logan]

I have a dialog based application that has two property pages over it. The property page has a list control, basically the app is a softphone and the list control shows the active calls and it's status. All call handling (making calls, recieving calls, etc) is done by a singleton class and I made another singleton class called CUIManager to update the status of the listbox, statusbar, etc. CUIManager holds a pointer to the list control and I make updates through it. When a call comes in, I start a thread and call the related function in my CCallManager singleton class, CCallManager then calls functions in CUIManager to update the status bar, list control, etc.

//CPropertyPage derived CCallsPage for showing active calls
BOOL CCallsPage::OnInitDialog()
{
	CPropertyPage::OnInitDialog();
	CUIManager::GetInstance ().m_pList = &m_List;

...
}

//This is how I make updates
void CUIManager::SetCallStatus (int nItem, COLOUMN col, CString strMessage)
{
	m_pList->SetItemText (nItem, col, strMessage);
}

Now my question to you people is that, is there a better way of doing all this? I'm using quite a few singletons, so does it mean that the design is poor (excess of everything is bad, I guess)?

Another question that I had is, there is a statusbar in my main dialog which shows messages and all. For now I use a timer to set the text of it to default after certain time. Is there any better way of doing this?

Please share your views with me.

Thanks.

[TheCPUWizard]

Based on the limited information posted.. .

1) Be carefule with your threading mechanism, remember only the UI thread that creates the control can legally access them.

2) There is nothing wrong (per se) with having lots of Singleton Patterns, if there truely can be at most one instance of the class legally in existance. In fact it is "proper". You may also want to consider the "Multiton" pattern, which I pusblished some articles on a few years ago. A trivial implementation is illustrated as follows:

disclaimer: I am typing this "raw" so there may be typos....

class HouseDoor
{
public:
   enum ValidDoors { Front, Read, Garage };
   static HouseDoor &Instance(ValidDoors selectedDoor);
...
protected:
   HouseDoor();
};

This extends the pure Singelton pattern to allow for multiple instances of the class, but it must be one of the "well defined" instances...

edit: Instance method needs to be static

[logan]

Thanks for the reply.

Are there any other ways to make the application thread safe? Or the only way is to send user defined messages to the property page, and ask it to update the list control?

Regards.

[TheCPUWizard]

Or the only way is to send user defined messages to the property page, and ask it to update the list control?

There are *always* "other ways" but this is the correct way

Depending on the application, it is often possible to define one single "UpdateUI" message. The UI thread can then compare current values of various items to the values it knows to be currently displayed, and then just update all of the controls which have changed values.

You do not want to blindly update all of the controls, as this will quickly cause a significant performance hit.

[logan]

Thanks, I will now fix it. Between, I'm not able to find your article on Multiton, can please give the link?

[TheCPUWizard]

The articles do not appear to be on-line anywhere, any more [they were publiushed well over 5 years ago [probably closer to 7-8 years ago]. I would have to dig into the archives. But the code sample should give you some idea.

Basically you protect construction [just like a singleton] but add some type of parameter(s) to the static accessor in order to control which specific instance is returned to you.

note: Going back to fix code sample....