I have a standard dialog resource which has some radio controls on it.
At the moment it is all done the normal way so the first radio is mapped to a int variable.
DDX_Radio(pDX, IDC_RADIO_DISPLAY_EVERYONE, m_iDisplayMode);
DDX_Radio(pDX, IDC_RADIO_SELECT_EVERYONE, m_iSelectMode);
Here is the thing ... I have these associated enumerations:
enum class DisplayMode { Everyone = 0, Brother, Sister };
enum class SelectMode { Everyone = 0, Elders, MinisterialServants, Appointed, Custom, None };
Therefore, whenever I need to do some comparisons of the mapped variable I have to do it like this:
Example 1:
m_iDisplayMode = to_underlying(DisplayMode::Everyone);
m_iSelectMode = to_underlying(SelectMode::None);
Example 2:
if (m_iDisplayMode == to_underlying(DisplayMode::Everyone))
bInclude = true;
else if (m_iDisplayMode == to_underlying(DisplayMode::Brother) && mapPublisher.second.eGender == Gender::Male)
bInclude = true;
else if (m_iDisplayMode == to_underlying(DisplayMode::Sister) && mapPublisher.second.eGender == Gender::Female)
bInclude = true;
The to_underlying function is a helper function that has been suggested previously to me here on SO and has been invaluable:
template <typename E>
constexpr auto to_underlying(E e) noexcept
{
return static_cast<std::underlying_type_t<E>>(e);
}
What I want to know is whether it is possible to map those radio controls directly to the DisplayMode or SelectMode objects? So instead of mapping to 1 etc. it maps to DisplayMode::Everyone etc. This would simplfy the code in this context and avoid the need for all the to_underlying calls.
This is the MFC source for DDX_Radio:
void AFXAPI DDX_Radio(CDataExchange* pDX, int nIDC, int& value)
// must be first in a group of auto radio buttons
{
pDX->PrepareCtrl(nIDC);
HWND hWndCtrl;
pDX->m_pDlgWnd->GetDlgItem(nIDC, &hWndCtrl);
ASSERT(::GetWindowLong(hWndCtrl, GWL_STYLE) & WS_GROUP);
ASSERT(::SendMessage(hWndCtrl, WM_GETDLGCODE, 0, 0L) & DLGC_RADIOBUTTON);
if (pDX->m_bSaveAndValidate)
value = -1; // value if none found
// walk all children in group
int iButton = 0;
do
{
if (::SendMessage(hWndCtrl, WM_GETDLGCODE, 0, 0L) & DLGC_RADIOBUTTON)
{
// control in group is a radio button
if (pDX->m_bSaveAndValidate)
{
if (::SendMessage(hWndCtrl, BM_GETCHECK, 0, 0L) != 0)
{
ASSERT(value == -1); // only set once
value = iButton;
}
}
else
{
// select button
::SendMessage(hWndCtrl, BM_SETCHECK, (iButton == value), 0L);
}
iButton++;
}
else
{
TRACE(traceAppMsg, 0, "Warning: skipping non-radio button in group.\n");
}
hWndCtrl = ::GetWindow(hWndCtrl, GW_HWNDNEXT);
} while (hWndCtrl != NULL &&
!(GetWindowLong(hWndCtrl, GWL_STYLE) & WS_GROUP));
}
I am trying to use the code in the answer but get this error:
MFC supports mapping between data (class members) and UI state. The standard mechanism is called Dialog Data Exchange (DDX) which the code in the question is using already (DDX_Radio). The data exchange is two-way, triggered by a call to UpdateData, where an argument of TRUE translates the UI state into values, and FALSE reads the associated values and adjusts the UI appropriately.
There are a number of standard dialog data exchange routines provided by MFC already, but clients can provide their own in case none of them fit the immediate use case. The question falls into this category, and conveniently provides the implementation of DDX_Radio to serve as a starting point.
The implementation looks a fair bit intimidating, though things start to make sense once the code has been augmented with a few comments here and there:
CustomDDX.h:
template<typename E>
void AFXAPI DDX_RadioEnum(CDataExchange* pDX, int nIDC, E& value)
{
// (1) Prepare the control for data exchange
pDX->PrepareCtrl(nIDC);
HWND hWndCtrl;
pDX->m_pDlgWnd->GetDlgItem(nIDC, &hWndCtrl);
// (2) Make sure this routine is associated with the first
// radio button in a radio button group
ASSERT(::GetWindowLong(hWndCtrl, GWL_STYLE) & WS_GROUP);
// And verify, that it is indeed a radio button
ASSERT(::SendMessage(hWndCtrl, WM_GETDLGCODE, 0, 0L) & DLGC_RADIOBUTTON);
// (3) Iterate over all radio buttons in this group
using value_t = std::underlying_type_t<E>;
value_t rdbtn_index {};
do {
if (::SendMessage(hWndCtrl, WM_GETDLGCODE, 0, 0L) & DLGC_RADIOBUTTON) {
// (4) Control is a radio button
if (pDX->m_bSaveAndValidate) {
// (5) Transfer data from UI to class member
if (::SendMessage(hWndCtrl, BM_GETCHECK, 0, 0L) != 0) {
value = static_cast<E>(rdbtn_index);
}
} else {
// (6) Transfer data from class member to UI
::SendMessage(hWndCtrl, BM_SETCHECK,
(static_cast<E>(rdbtn_index) == value), 0L);
}
++rdbtn_index;
} else {
// (7) Not a radio button -> Issue warning
TRACE(traceAppMsg, 0,
"Warning: skipping non-radio button in group.\n");
}
// (8) Move to next control in tab order
hWndCtrl = ::GetWindow(hWndCtrl, GW_HWNDNEXT);
}
// (9) Until there are no more, or we moved to the next group
while (hWndCtrl != NULL && !(GetWindowLong(hWndCtrl, GWL_STYLE) & WS_GROUP));
}
This declares a function template that can be instantiated for arbitrary scoped enum types, and implements the logic to translate between UI state and enum value. The integral underlying value of the enum serves as the zero-based index into the radio button group selection.
The implementation needs a bit of explanation, though. The following list provides a bit more information regarding the numbered // (n) code comments:
This initializes internal state used by the framework. The precise details aren't very important, as long as the correct function is called. There are 3 implementations, one for OLE controls, one for edit controls, and one for every thing else. We're in the "everything else" category.
Perform sanity checks. This verifies that the control identified by nIDC is the first control in a radio button group (WS_GROUP), and that it is indeed a radio button control. This helps weed out bugs early when running a debug build.
Initialize the radio button index counter (rdbtn_index), and start iterating over radio buttons.
Make sure the control we're operating on in this iteration is a radio button control (if not, see 7.).
When translating UI state back to member variables, verify whether the current control is checked, and store its index in the group as a scoped enum value.
Otherwise (i.e. when translating data to UI state) set the check mark if the numeric value of the enum matches the control index, and uncheck it otherwise. The latter is not strictly required when using BS_AUTORADIOBUTTON controls, but it's not harmful either.
If we encounter a control that isn't a radio button control, issue a warning. Closely watch the debug output for this message; it designates a bug in the dialog template. Make sure to set the WS_GROUP style on the first control following this radio button group (in tab order).
Move on to the next control in tab order.
Terminate the loop if either there is no trailing control, or the control starts a new group, designated by the WS_GROUP style.
That's a fair bit to digest. Luckily, use of this function template is far less cumbersome. For purposes of illustration, let's use the following scoped enums:
enum class Season {
Spring,
Summer,
Fall,
Winter
};
enum class Color {
Red,
Green,
Blue
};
and add the following class members to the dialog class:
private:
Season season_ {};
Color color_ { Color::Green };
All that's left is setting up the DDX associations, i.e.:
void CRadioEnumDlg::DoDataExchange(CDataExchange* pDX) {
CDialogEx::DoDataExchange(pDX);
DDX_RadioEnum(pDX, IDC_RADIO_SPRING, season_);
DDX_RadioEnum(pDX, IDC_RADIO_RED, color_);
}
(with CRadioEnumDlg deriving from CDialogEx). All the template machinery is neatly hidden, with the template type argument getting inferred from the final argument.
For completeness, here is the dialog template used:
IDD_RADIOENUM_DIALOG DIALOGEX 0, 0, 178, 107
STYLE DS_SETFONT | DS_FIXEDSYS | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME
EXSTYLE WS_EX_APPWINDOW
FONT 8, "MS Shell Dlg", 0, 0, 0x1
BEGIN
DEFPUSHBUTTON "OK",IDOK,59,86,50,14
PUSHBUTTON "Cancel",IDCANCEL,121,86,50,14
CONTROL "Spring",IDC_RADIO_SPRING,"Button",BS_AUTORADIOBUTTON | WS_GROUP | WS_TABSTOP,7,7,39,10
CONTROL "Summer",IDC_RADIO_SUMMER,"Button",BS_AUTORADIOBUTTON,7,20,39,10
CONTROL "Fall",IDC_RADIO_FALL,"Button",BS_AUTORADIOBUTTON,7,33,39,10
CONTROL "Winter",IDC_RADIO_WINTER,"Button",BS_AUTORADIOBUTTON,7,46,39,10
CONTROL "Red",IDC_RADIO_RED,"Button",BS_AUTORADIOBUTTON | WS_GROUP | WS_TABSTOP,54,7,39,10
CONTROL "Green",IDC_RADIO_GREEN,"Button",BS_AUTORADIOBUTTON,54,20,39,10
CONTROL "Blue",IDC_RADIO_BLUE,"Button",BS_AUTORADIOBUTTON,54,33,39,10
END
as well as its accompanying resource.h:
#define IDD_RADIOENUM_DIALOG 102
#define IDC_RADIO_SPRING 1000
#define IDC_RADIO_SUMMER 1001
#define IDC_RADIO_FALL 1002
#define IDC_RADIO_WINTER 1003
#define IDC_RADIO_RED 1004
#define IDC_RADIO_GREEN 1005
#define IDC_RADIO_BLUE 1006
Adjusting a default-generated MFC application (dialog-based) with the above produces the following result when launched:
That's sweet, actually. Note in particular that the second row of radio buttons has the second item checked, which matches the initial value set in the dialog class' implementation (Color color_ { Color::Green }).
So all's good then?
Well, yeah. I guess. Sort of, anyway. Let's talk about the things that aren't quite as cool, things to watch out for, and problems that simply don't have a solution.
The implementation provided above makes a number of assumptions, none of which can be verified at compile time, and only some of them can (and are) verified at run time:
Enum values need to be backed by integral values, starting at 0, and counting up without any gaps. To my knowledge, there's no way to enforce this today (C++20), and the most effective way to ensure this is a code comment.
The order of enum values must match the tab order of radio button controls. Again, this is nothing that can be enforced nor verified.
The control ID specified in the DDX_RadioEnum call must be the start of a radio button group. This is verified at run time (the first ASSERT).
The control ID specified in the DDX_RadioEnum call must identify a radio button control. Again, this is verified at run time (the second ASSERT).
The first control following the radio button group (in tab order) must have the WS_GROUP style set. This is verified at run time, in part. If the control following is not a radio button control, a warning is issued. If the control happens to be a radio button, then this is not something that can be verified.
Those assumptions certainly aren't impossible to match. The hard part is keeping those invariants valid over time. If you can, then this implementation is worth a try.
I subclassed FL_Value_Input such that I can give the widget a color when it is modified, but the user has not yet pressed enter.
The silly thing is that the handle(int e) function is never invoked in case the event is a FL_KEYDOWN event, other events (such as FL_KEYUP, FL_DRAG, FL_FOCUS etc) are being propagated fine.
The widget is part of a widget hierarchy... Could it be that one of its parents in this hierarchy is absorbing this specific FL_KEYDOWN event?
EDIT: apparently, the widget also doesn't have focus (tested by comparing this to Fl::focus()), which is odd, as I am typing into it.
Any help would be appreciated.
Fx_Value_Input::Fx_Value_Input(int x, int y, int w, int h, const char* l)
: Fl_Value_Input(x, y, w, h, l)
{}
int Fx_Value_Input::handle(int e)
{
int r = Fl_Value_Input::handle(e);
if (e == FL_KEYBOARD)
{
if ((Fl::event_key() != FL_Enter && Fl::event_key() != FL_KP_Enter ) )
color(Fx::get_modified_color());
else if ((Fl::event_key() == FL_Enter || Fl::event_key() == FL_KP_Enter) && color() == Fx::get_modified_color())
color(FL_WHITE);
redraw();
}
return r;
}
Using FL_KEYDOWN is the Windows way of doing things, which, as you have found, doesn't work because you need to subclass Fl_Input_: not Fl_Input and even then, it doesn't work properly.
Instead, use when(FL_WHEN_CHANGED|FL_WHEN_ENTER_KEY). Check changed() when keys are pressed and clear_changed(). It isn't set when the enter key is pressed. You can change colours back when that condition is met.
inputkey = new Fl_Input...
inputkey->when(FL_WHEN_CHANGED| FL_WHEN_ENTER_KEY);
inputkey->callback(cb);
....
void cb(Fl_Widget *ob)
{
Fl_Input* ip = dynamic_cast<Fl_Input*>(ob);
if (ip->changed())
{
// change colour
ip->clear_changed();
}
else
{
// change colour
}
}
Got a reply on the FLTK Google group, explaining the issue... There is no easy workaround for this...
FLTK delivers key strokes directly to the focus widget. Fl_Value_Input
includes an Fl_Input widget, and that widget becomes the focus widget when you click in the input field.
Hence the "parent" Fl_Value_Input never sees the Fl_KEYDOWN events.
Note that I quoted "parent" because Fl_Value_Input is a very
special case. It's not derived from Fl_Group, but it behaves somewhat
like an Fl_Group widget.
So why does your derived widget get FL_KEYUP events? That's another
feature of FLTK: FL_KEYUP events are also delivered to the focus
widget in the first place. However, AFAICT no core FLTK widget
handles FL_KEYUP events - they all return 0 in their handle()
methods. If the focus widget doesn't handle an event FLTK tries to
deliver it to the parent widget and then up through the widget
hierarchy until it reaches the top level window. Hence (and this is
IMHO weird) eventually all widgets will receive all FL_KEYUP events
unless one widget returns 1 from its handle() method (which is
usually not the case). Depending on the depth of the focus widget in
the total widget hierarchy it may be that some widgets get the same
FL_KEYUP event multiple times, because all parent groups of the focus
widget try to deliver the event to all their children.
I'm using WinCE 7 Visual Studio 2008 and writing a driver code for ALS (MAX44009). I have written the following code for reading the interrupt status register and displaying messages when the interrupt has occurs. But, it works randomly for a few times only. For eg., when I close the sensor with my hand, I get the messages only few times, and then, it doesn't go into the data==1 condition even when it has to interrupt and continues to loop. The threshold timer is 0. The AlsRegRead function does an I2CRead. pAlsDrvInfo is the driver context. ADD_ALS_INT_STATUS is 0. DumpAlsRegistry function will print the content of all the registers except register 0x0.
while(1)
{
AlsRegRead(pAlsDrvInfo, ADD_ALS_INT_STATUS, &data, sizeof(UINT8));
if (data == 1)
{
DumpAlsRegistry(pAlsDrvInfo);
RETAILMSG(1,(L"Interrupt Received...\r\n"));
}
}
Please guide me where I'm making mistake.
I have found the reason behind this. Two issues had been behind this and both of them are equally important.
1) The sensor had been in a partially damaged state.
2) It requires some delay. So, I added Sleep(1000) at the start of the loop.
while(1)
{
Sleep(1000);
AlsRegRead(pAlsDrvInfo, ADD_ALS_INT_STATUS, &data, sizeof(UINT8));
if (data == 1)
{
DumpAlsRegistry(pAlsDrvInfo);
RETAILMSG(1,(L"Interrupt Received...\r\n"));
}
}
Thanks.
I have a textfield (lower level) a call a function that call a higher level form that contains a datafield to pick up a date and display it in my textfield lowerlevel.
The problem is I cannot get back to my textfield (lower level) since the datefield appears
public void formdatepicker() {
final javax.microedition.lcdui.Command CONFIRM_COMMAND
= new javax.microedition.lcdui.Command("OK",
javax.microedition.lcdui.Command.OK, 1);
javax.microedition.lcdui.Command CANCEL_COMMAND
= new javax.microedition.lcdui.Command("Cancel",
javax.microedition.lcdui.Command.CANCEL, 2);
final DateField datefield = new DateField("Pick a date", DateField.DATE);
form.append(datefield);
form.addCommand(CONFIRM_COMMAND);
form.addCommand(CANCEL_COMMAND);
form.setCommandListener(new CommandListener() {
public void commandAction(javax.microedition.lcdui.Command c, Displayable d) {
if (c == CONFIRM_COMMAND) {
Date date = datefield.getDate();
display.setCurrent(null);// try to hide the current form to get
}
}
});
Display.getInstance().getJ2MEDisplay().setCurrent(form);
Your mistake is wrong assumption about what setCurrent(null) does. Per your question and code snippet, it looks like you expect it to somehow show the screen that has been displayed prior to form. It doesn't, see the exaplanation in the API javadocs (available online):
The application may pass null as the argument to setCurrent(). This does not have the effect of setting the current Displayable to null; instead, the current Displayable remains unchanged. However, the application management software may interpret this call as a request from the application that it is requesting to be placed into the background...
If you want to use setCurrent(Displayable) to show some screen instead of current one, you need to pass this screen as an argument to setCurrent.
For the sake of completeness, note that there is another version of setCurrent that accepts two parameters, first of which is Alert, which works a bit differently, but it is not applicable in your case because you use Form not Alert.