I'm subclassing a WTL combobox and I'm owner-drawing the items of the combobox. The control has the attributes CBS_DROPDOWNLIST | CBS_HASSTRINGS | CBS_OWNERDRAWVARIABLE and I'm using the mix-in class COwnerDraw to implement DrawItem() and MeasureItem(). When the drop down list is down, the items are drawn correctly. However when the drop down list is up, the combobox control is empty and the item isn't drawn. What am I doing wrong?
The WTL class looks like this:
class CMyComboBox :
public CWindowImpl<CMyComboBox, CComboBox>,
public COwnerDraw<CMyComboBox>
{
public:
BEGIN_MSG_MAP_EX(CMyComboBox)
CHAIN_MSG_MAP(COwnerDraw<CMyComboBox>)
CHAIN_MSG_MAP_ALT(COwnerDraw<CMyComboBox>, 1)
END_MSG_MAP()
void DrawItem(LPDRAWITEMSTRUCT lpDIS)
{
CDCHandle dc = lpDIS->hDC;
dc.FillSolidRect(&lpDIS->rcItem, lpDIS->itemID == 0 ?
RGB(255,0,0) : RGB(0,255,0));
}
void MeasureItem(LPMEASUREITEMSTRUCT lpMeasureItemStruct)
{
lpMeasureItemStruct->itemWidth = 12;
lpMeasureItemStruct->itemHeight = 12;
}
};
The class is used on a dialog and is subclassed like this:
m_cbMy.SubclassWindow(GetDlgItem(IDC_COMBO1));
m_cbMy.AddString(_T("Item 1"));
m_cbMy.AddString(_T("Item 2"));
Changing the control attributes to CBS_OWNERDRAWFIXED doesn't change anything.
Edit:
Thanks to the help of najmeddine I figured out that I have to handle WM_PAINT to draw the actual combobox, and not only the items in the drop-down list. Unfortunately now I have to also draw the combobox control all by myself. Is there a way to let the GDI draw the border and drop arrow so that I only have to draw the "insides" of the control?
To draw the combobox control you should use the theme APIs in your WM_PAINT handler (in XP+ - you don't say what Windows versions you need to support.) Specifically, use DrawThemeBackground, and pass in one of the CB_ values for iPartId.
You will also need to use the buffered paint APIs to handle transitions on Vista, which can complicate your paint handler - this and other drawing problems when custom painting a combobox control are explained here in a fair amount of detail. I'd suggest using that forum thread as your main reference implementing this.
On DrawItem you filling a rect with some color. But where is DrawText or something like it?
Example of custom DrawItem.
To draw the comboBox control (not the list), you should also handle the WM_PAINT message and do your painting there.
the DrawItem event only paints the drop list and it's items.
Related
I have a WIN32 application that uses a main dialog window as background and several alternative dialogs that can appear in front of the main window. These overlay dialogs should not have any border because they need to appear to be part of the main window.
Everything was working well until I activated Dynamic Layout on the controls in an overlay dialog. It then acquired a thin border with drop shadow, a thin top bar that was sometimes windows top bar color and sometimes white, and the dialog became independently resizable. I don't want this, I want the overlay dialog to resize only with the main dialog window.
How can I force the dialog to have No Border?
You can modify the style of a dialog window in your override of the OnInitDialog() member function, if that window is created using a custom class derived from CDialog or CDialogEx, or something similar. (If not, you'll need to somehow 'intercept' the window's creation process.)
Assuming you have overridden OnInitDialog(), the process will be along these lines:
BOOL MyDialog::OnInitDialog()
{
BOOL answer = CDialog::OnInitDialog(); // Call base class stuff
LONG_PTR wStyle = GetWindowLongPtr(m_hWnd, GWL_STYLE); // Get the current style
wStyle &= ~WS_BORDER; // Here, we mask out the style bit(s) we want to remove
SetWindowLongPtr(m_hWnd, GWL_STYLE, wStyle); // And set the new style
// ... other code as required ...
return answer;
}
Note: It is important to call the base class OnInitDialog() before you attempt to modify the window's style; otherwise, the window may not be in a 'completed' state, and any changes you make may be reverted.
As mentioned in the comment by IInspectable, it may be possible (or even better) to modify the style (taking out the WS_BORDER attribute) in an override of the PreCreateWindow() function:
BOOL MyDialog::PreCreateWindow(CREATESTRUCT &cs)
{
if (!CDialog::PreCreateWindow(cs)) return FALSE;
cs.style &= ~WS_BORDER;
return TRUE;
}
Again, as shown here, you should call the base class member before modifying the style.
So the answer to my original question is to put the following code in the overloaded OnInitDialog() after the call to the base class.
LONG_PTR wStyle = GetWindowLongPtr(m_hWnd, GWL_STYLE); // Get the current style
wStyle &= ~WS_SIZEBOX; // Mask out the style bit(s) we don't want
SetWindowLongPtr(m_hWnd, GWL_STYLE, wStyle); // And set the new style
My Qt based application has a QMainWindow and another modal widget. This modal widget does not have a restore option. The user is allowed to drag this widget across displays when more than one monitor is available. However, when my widget is large, and the user drags it across to an extended monitor( usually a projector with a very low resolution) the widget is too large for the screen and gets cut.
I want to be able to detect when the user has moved to different screen so that I can resize the widget( and the content within) to fit the new screen's dimension and resolution. Is there any signal that Qt emits for this purpose?
This is probably the function call you are looking for:
http://qt-project.org/doc/qt-5/qdesktopwidget.html#screenNumber
int QDesktopWidget::screenNumber(const QWidget * widget = 0) const
Returns the index of the screen that contains the largest part of
widget, or -1 if the widget not on a screen.
To use this as part of a signal, you should subclass moveEvent and resizeEvent of a QWidget and put your logic for deciding how to place/resize your widget there. If you want to resize like a browser tab that gets dragged onto a new monitor, you may want to just use the point of the mouse instead of the widget to decide which monitor to react to.
So your end code could look something like this:
void Widget::moveEvent(QMoveEvent * e)
{
m_newScreenSize = qApp->desktop()->screenGeometry(this);
}
void Widget::mouseReleaseEvent(QMouseEvent * e)
{
this->resize(m_newScreenSize);
}
Other Links and References
QMoveEvent
QResizeEvent
QDesktopWidget
http://qt-project.org/doc/qt-5/qdesktopwidget.html#details
http://qt-project.org/doc/qt-5/qapplication.html#desktop
http://qt-project.org/doc/qt-5/qmoveevent.html#details
http://qt-project.org/doc/qt-5/qwidget.html#moveEvent
http://qt-project.org/doc/qt-5/qwidget.html#resizeEvent
http://qt-project.org/doc/qt-5/qrect.html#intersects
http://qt-project.org/doc/qt-5/qdesktopwidget.html#availableGeometry-2
const QRect QDesktopWidget::availableGeometry(const QWidget * widget) const
I have such menu situation:
int menu_create(Ihandle *menu)
{
hamburger = IupItem("&Hamburger", "hamburger");
IupSetAttributes(hamburger, "AUTOTOGGLE=YES, RADIO=YES");
char* ce = "Ćev&apčići";
cevapcici = IupItem(utf8_to_cp1250(ce), "cevapcici");
IupSetAttributes(cevapcici, "AUTOTOGGLE=YES, RADIO=YES");
exit = IupItem("Exit\tAlt+F4", "exit");
img4 = IupLoadImage("icons\\delete_16x16.ico");
IupSetAttributeHandle(exit, "TITLEIMAGE", img4);
menu = IupMenu(
IupSubmenu("File",
IupMenu(
hamburger,
cevapcici,
IupSeparator(),
IupItem("Carro&t", "carrot"),
IupSeparator(),
exit,
NULL)),
NULL);
IupSetFunction("exit", (Icallback)mnu_exit);
... etc...
IupSetHandle("menu", menu);
return IUP_DEFAULT;
}
How to get "radio toggle group" functionality with items hamburger and cevapcici so first turns off a second checkmark and opposite. This is my try but it don't work.
2) I try webbrowser example from IUP suite on my windows 7. Problem is that bad black flickering appear's during resize (increase). Also, background of webbrowser flicker black during showing.
I try a same example on Ubuntu and there flickering appear's too but it is not so much visible since background is there white.
Is here any way to get rid of those flickering or if not to get white background of webbrowser window on windows?
3) Since webbrowser is ole object (on windows) is it possible to use say "print preview" or "zoom" function by reference from IUP handle or at any other way like we used to do from MS programming tools?
wbInstance.ExecWB(Exec.OLECMDID_OPTICAL_ZOOM, ExecOpt.OLECMDEXECOPT_DONTPROMPTUSER, 150, DBNull.Value)
4) How can I get key_up event fired from IupTree?
5) Interesting situation with IupTabs:
frame3 = IupHbox(mat, val, NULL);
vboxt1 = IupVbox(frame3, NULL);
vboxt2 = IupVbox(frame3, NULL);
IupSetAttribute(vboxt1, "TABTITLE", "First documents... ");
IupSetAttribute(vboxt2, "TABTITLE", "Second documents... ");
tabs = IupTabs(vboxt1, vboxt2, NULL);
hbox1 = IupHbox(tabs, IupVbox(frame, tree, frame2, NULL), NULL);
dlg = IupDialog(hbox1);
When I set frame3 which should be a same for both tabs my GUI frozes.
However, I have to got same "mat" (IupMatrix) in both tabs because by changing tabs other data load in matrix but similar enough to use same matrix and related functions.
What to do here?
1) The RADIO attribute belongs to the IupMenu, not to the IupItem. This also means that all the IupItems inside that menu will be part of the radio.
A workaround would be to manually unset the other toggle inside the action callback.
2) That flicker is not caused by IUP. Don't know why the native controls are doing it.
3) Yes, but you will have to program that using the OLE API. If you take a look at the IupOleControl and IupWebBrower source code and send me the code to do it, I will be happy to add it to IUP.
4) You don't. Use the K_ANY callbacks.
5) You can not reuse a control in different places in any dialog. So you must have two different frames, with two different matrices. What you can do is to encapsulate your matrix, so the same function will create a matrix with the same attributes and callbacks any time you want one.
I am relatively new to the Win32/Windows API (non-MFC), and am trying to change the text colour of a static text control. It is already drawn to the screen in black, but I want to change it to another colour using the Windows Colour Chooser dialog, which is opened on clicking a button. Is this possible?
For the button, the WM_COMMAND message is handled on clicking. So far, I have written:
CHOOSECOLOR ccColour;
ccColour.lStructSize = sizeof(ccColour);
ccColour.hwndOwner = hWnd;
ccColour.rgbResult = crLabelTextColour;
ccColour.Flags = CC_FULLOPEN | CC_RGBINIT;
if (ChooseColor(&ccColour) == TRUE)
{
// crLabelTextColour is a COLORREF global variable assigned on loading the program
crLabelTextColour = ccColour.rgbResult;
}
This code, however, fails with an unhandled exception at the if statement, and I'm not sure why! Other examples seem to write code like this.
ChooseColor() crashes because you are not initializing the CHOOSECOLOR structure completely. You are only setting 3 fields, the rest will contain garbage. You'll need to zero-initialize everything, simple to do:
CHOOSECOLOR ccColour = {0};
I need to do something which i expected to be was simple - create a tab control which has 2 tabs, implying 2 modes of operation for my app. When user clicks on Tab1, he'll be presented with some buttons and textboxes, and when he clicks Tab2, some other input method. I noticed that there was a CTabCtrl class thats used in MFC to add tabs.
However, once I added the tab ctrl using the UI designer, I couldn't specify how many tabs there'll be using property window. Searching on the net, I found some examples but all of them required you to derive from CtabCtrl , create 2 or more child dialogs etc and to write your own custom class. My question is, since I want to do something so basic, why couldn't I do it using the familiar Add Event handler/Add member variable wizard and then handle everything else inside my app's class ? Surely, the default CTabCtrl class can do something useful without needing to derive from it ?
Forget about CTabCtrl and use CMFCTabCtrl which is much easier to work with (this is assuming you are working on VS2008 SP1).
Failing that, you seem to misunderstand how the tab control works. It only provides the 'tab strip' at the top and sends messages when the user clicks on another one. It doesn't provide you with 'tab canvases' on which you can put controls. Showing and hiding the controls on the tab is something that the programmer needs to take care of. The resource editor provides little support there. Like Stewart says, the most common way of working is to have child dialogs in your tab and hide all of them except the one of the current tab.
You don't need to derive from CTabCtrl, you can also implement the switching behavior in the window that is the parent of the CTabCtrl.
The MFC tab control is a pretty thin wrapper over the win32 tab control, which works in pretty much the way you describe. It is a window, which provides switching between child windows using tabs. As it happens, in straight win32 this is the most useful way for it to work. If you want to do something more sophisticated than switching between individual windows, you do this by using child dialogs. MFC doesn't do a great deal to help you, but deriving from CTabCtrl and using child dialogs is really not very difficult to do, although if you're used to the way WinForms does tab controls it does seem unnecessary.
If you want the tab control at the root of the dialog, with no other controls along side it, you might want to look at CPropertySheet (http://msdn.microsoft.com/en-us/library/d3fkt014(VS.80).aspx) which is probably simpler to use. Unless you want to use any of the wizard functionality you don't even need to derive from it - you just create a couple of child dialog classes, then in the place where you want to create the property sheet, make an object, add the pages to it and invoke it.
The approach I took with an MFC dialog that contained a CTabCtrl was to derive a small class to manage the tab control and used dialog templates to create the actual tab window contents.
This is still being worked on so the source code is not very clean however here are some pieces. For instance CTabCtrlDialog needs constructor and destructor in order to release object which may have been created.
In the resource file I have a dialog template with a tab control followed by three dialog templates for each of the different tab content windows inserted into the tab control. While the dialog displaying the tab control has the WS_POPUP style, the dialog templates for the tab windows that are inserted into the tab control have a WS_CHILD style instead. This change makes the tab windows child windows so that when the dialog is moved, everything stays lined up properly with no further effort on my part.
In my case the tab windows which are inserted into the tab control display a set of check boxes to indicate various operational parameters. Using a dialog template approach makes it very easy to create the necessary tab window content.
I derive a class from CTabCtrl that extends the standard MFC class with an additional method for inserting into the tab control a tab window based on a specified dialog template id. Since this is just a single dialog, I just put this class into the same files, .h and .cpp, as the dialog components themselves.
class CTabCtrlDialog : public CTabCtrl
{
public:
void InsertItemDialogTemplate (UINT nIDTemplate, int nItem, TCITEM* pTabCtrlItem);
public:
struct {
UINT nIDTemplate;
CDialog *pDialog;
} m_pDialogData[10];
};
The method InsertItemDialogTemplate() looks like:
/*
* InsertItemDialogTemplate ()
*
* Insert into a tab control a tab pane based on the specified dialog template. The
* dialog template describes what the tab pane looks like so far as controls, etc.
*
* NOTE: The STYLE description must be WS_CHILD and not WS_POPUP. Also the dialog
* needs to have as its top coordinate some distance in pixels so that the
* various tab descriptions are visible. For instance an example dialog
* template in the resource file may look like:
* IDD_CASHIER_TAB_ONE DIALOGEX 0, 10, 178, 113
* STYLE DS_SETFONT | DS_FIXEDSYS | WS_CHILD
* FONT 8, "MS Shell Dlg", 400, 0, 0x1
* BEGIN
* LTEXT "Dialog Tab one",IDC_STATIC,6,44,90,17
* END
*
**/
void CTabCtrlDialog::InsertItemDialogTemplate (UINT nIDTemplate, int nItem, TCITEM* pTabCtrlItem)
{
InsertItem (nItem, pTabCtrlItem);
m_pDialogData[nItem].nIDTemplate = nIDTemplate;
m_pDialogData[nItem].pDialog = new CDialog ();
m_pDialogData[nItem].pDialog->Create (nIDTemplate, this);
m_pDialogData[nItem].pDialog->ShowWindow (FALSE);
}
For handling tab selection which displays the various tabs I have the following message map and then the two event handlers in the dialog.
BEGIN_MESSAGE_MAP(CDiaCashierEdit, CDialog)
ON_NOTIFY(TCN_SELCHANGE, IDC_TAB_CASHIER_EDIT_STATUS, &CDiaCashierEdit::OnTcnSelchangeTabCashierEditStatus)
ON_NOTIFY(TCN_SELCHANGING, IDC_TAB_CASHIER_EDIT_STATUS, &CDiaCashierEdit::OnTcnSelchangingTabCashierEditStatus)
END_MESSAGE_MAP()
void CDiaCashierEdit::OnTcnSelchangeTabCashierEditStatus(NMHDR *pNMHDR, LRESULT *pResult)
{
// TODO: Add your control notification handler code here
*pResult = 0;
int i = TabCtrl_GetCurSel(pNMHDR->hwndFrom);
m_TabCtrl.m_pDialogData[i + 1].pDialog->ShowWindow (TRUE);
}
void CDiaCashierEdit::OnTcnSelchangingTabCashierEditStatus(NMHDR *pNMHDR, LRESULT *pResult)
{
// TODO: Add your control notification handler code here
*pResult = 0;
int i = TabCtrl_GetCurSel(pNMHDR->hwndFrom);
m_TabCtrl.m_pDialogData[i + 1].pDialog->ShowWindow (FALSE);
}
In the DoDataExchange() method of the dialog I have the following which creates first the tab control and then creates each of the tab windows and inserts them into the tab control.
void CDiaCashierEdit::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_EDIT_CASHIER_NAME, m_CashierName);
DDX_Control(pDX, IDC_EDIT_CASHIER_SUPNO, m_SupervisorId);
DDX_Control(pDX, IDC_EDIT_CASHIER_TEAMNO, m_TeamNumber);
DDX_Control(pDX, IDC_EDIT_CASHIER_GCSTART, m_GuestCheckStart);
DDX_Control(pDX, IDC_EDIT_CASHIER_GCEND, m_GuestCheckEnd);
DDX_Control(pDX, IDC_TAB_CASHIER_EDIT_STATUS, m_TabCtrl);
if (pDX->m_bSaveAndValidate) {
m_CashierName.GetWindowText (m_paraCashier.auchCashierName, 20);
m_paraCashier.usSupervisorID = m_SupervisorId.GetWindowTextAsInt();
m_paraCashier.uchTeamNo = m_TeamNumber.GetWindowTextAsInt();
m_paraCashier.usGstCheckStartNo = m_GuestCheckStart.GetWindowTextAsInt();
m_paraCashier.usGstCheckEndNo = m_GuestCheckEnd.GetWindowTextAsInt();
for (int i = 0; i < sizeof(m_TabItemOneStatus)/sizeof(m_TabItemOneStatus[0]); i++) {
int iTab = m_TabItemOneStatus[i].sTabItem;
int iDlg = m_TabItemOneStatus[i].iDlgItem;
int iOffset = m_TabItemOneStatus[i].sOffset;
CButton *p = (CButton *) m_TabCtrl.m_pDialogData[iTab].pDialog->GetDlgItem(iDlg);
if (p->GetCheck()) {
m_paraCashier.fbCashierStatus[iOffset] |= m_TabItemOneStatus[i].uchBit;
} else {
m_paraCashier.fbCashierStatus[iOffset] &= ~(m_TabItemOneStatus[i].uchBit);
}
}
} else {
m_CashierName.SetWindowText(m_paraCashier.auchCashierName);
m_SupervisorId.SetWindowTextAsInt (m_paraCashier.usSupervisorID);
m_TeamNumber.SetWindowTextAsInt (m_paraCashier.uchTeamNo);
m_GuestCheckStart.SetWindowTextAsInt (m_paraCashier.usGstCheckStartNo);
m_GuestCheckEnd.SetWindowTextAsInt (m_paraCashier.usGstCheckEndNo);
m_TabCtrl.InsertItemDialogTemplate (IDD_CASHIER_TAB_ONE, 1, &m_TabItemOne);
m_TabCtrl.InsertItemDialogTemplate (IDD_CASHIER_TAB_TWO, 2, &m_TabItemTwo);
m_TabCtrl.InsertItemDialogTemplate (IDD_CASHIER_TAB_THREE, 3, &m_TabItemThree);
for (int i = 0; i < sizeof(m_TabItemOneStatus)/sizeof(m_TabItemOneStatus[0]); i++) {
int iTab = m_TabItemOneStatus[i].sTabItem;
int iDlg = m_TabItemOneStatus[i].iDlgItem;
int iOffset = m_TabItemOneStatus[i].sOffset;
CButton *p = (CButton *) m_TabCtrl.m_pDialogData[iTab].pDialog->GetDlgItem(iDlg);
if (m_paraCashier.fbCashierStatus[iOffset] & m_TabItemOneStatus[i].uchBit) {
p->SetCheck (1);
} else {
p->SetCheck (0);
}
}
m_TabCtrl.m_pDialogData[1].pDialog->ShowWindow (TRUE);
}
}