Polymorphism

[robinbloke]

You can get stuck in your ways, as I've rambled on about more times than not lately, and this year continues to be one of new experiences.
Finding something out new and trying something new are different types of experience however. The latter is proactive, you go out and try something you haven't before - although it may be that the former is involved as you have to think of this new experience in some way before you can try it.

However, gaining new knowledge or new insight about something is entirely different, if it's a bit of "Well I never knew that" or a "I really should have guessed that". It's a little spark or 'blimey' that pops above your head, lightbulb fashion.

Todays "I really should have guessed that." was brought to me by Polymorphism, MFC and the humble function statement...

m_ctrlEditText.UpdateData(TRUE);

It went a little like this...
"I just want to update the text for the edit box," thinks I, "Not the whole dialog"
"Then, erm, just do that" my brain replies, "It's polymorphic, the functionality will be included in the text edit object."
"Bloody hell brain, you may be right."
"I am right, you just never thought of that before."
"You're right, I hadn't."
"Sometimes I wonder where you'd be without me."
"Who knows?"

Todays bonus lightbulb is the humble 40W SES Candle bulb.

Comments

[deliberateblank.livejournal.com]

m_ctrlEditText.UpdateData(TRUE);

Does that actually work? UpdateData (on CDialog) uses the DDX map to transfer data between dialog class variables and dialog items. Child windows don't usually have their own DoDataExchange() member (well, they have the default one, which is empty).

Usually, to do this, I have written helpers which i) set the dialog class variable, ii) called SetDlgItemText/Int/CheckDlgButton/CheckRadioButton as appropriate to update the single control. To retrieve the data you can just call GetDlgItemInt/Int/IsDlgButtonChecked/GetCheckedRadioButton. Not as powerful as the DDX_ macros, but good enough in many cases. If you need the improved data type support of the DDX mechanism then updating the whole dialog really isn't *that* expensive.

[robinbloke.livejournal.com]

Well no, it doesn't ;)
I had to change the code anyway; but since it's a control it won't have any effect on any attached CStrings (etc) aye. Well spotted, heh.

My problem comes more from when you what to extract only a single item from dialog controls without nuking any other values you might have already in them, rather than time to update them. Lazy, me?

[deliberateblank.livejournal.com]

Yeah, that can be a real pain. The problem is that the dialog data mechanism has a very clear workflow: initialise local variables, updatedata(false), repeat { updatadata(true), test/modify variable, updatedata(false) }, updatedata(true), destroy window. If you're doing anything slightly different from a data entry page then this model starts looking distinctly unwieldy. Like many aspects of MFC (doc/view is another common example, very good for writing clones of Word but god help you if you want the document to be database backed rather than file backed, or completely synthetic), you either play entirely by its rules or enter a world of code maintenance pain.

The trick here is that local variables bound to dialog controls do *not* belong to you anymore, and you should *never* modify them outside of the above workflow, otherwise you'll either lose data or end up with masses of extra code to force things back into sync. If particular controls don't gel well with that you don't have to put them in your DDX map though - just treat them as normal controls and do it manually.

[puddingcat.livejournal.com]

Todays bonus lightbulb is the humble 40W SES Candle bulb.

I've just bought 8 of them. I didn't get any bonus, at all. I feel cheated.