|
Hello. I got it now. To occupy an SDI/MDI with a formview resource template there is one detail in the project assistant. At the last page one can fill in from what the view derives. The preset is CView, but you must change it to CFormView. That was all. Well, I would have liked to make it an existing project, but this is ok, too. Thank You.
|
|
|
|
|
|
|
In my MFC application, I am doing a custom drawing in my dialog class OnPaint(). I have also created a few controls in dialog template. I have also resized and repositioned some of the controls in the dialog code. When I run my application, the controls are flickering.
Please suggest me how to avoid this?
BOOL CFP::OnInitDialog()
{
CDC *pDC = GetDC(); //Get DC for Dialog's Client Area
pDCTmp->CreateCompatibleDC(pDC); //Create Compatible DC(pDCTmp) for Dialog's Client Area(pDC)
//pDCTmp is a member Variable
pBgBitmap->CreateCompatibleBitmap (pDC, 800, 640 ); //Create Compatible Bitmap(pBgBitmap) for Dialog's Client Area(pDC)
//pBgBitmap->LoadBitmap(IDB_FORESTIMAGE);
pDCTmp->SelectObject(pBgBitmap);
ReleaseDC(pDC);
}
void CFacePlate::OnPaint()
{
CPaintDC dc(this); // device context for painting
// TODO: Add your message handler code here
CRect rect;
rect = rScreen; //rScreen is Client rect
pDCTmp->FillRect(rect,&CBrush(RGB(152, 185, 192))); //pDCTmp member variable is used to draw
.
.
.
.
//Custom drawings using the pDCTmp
}
|
|
|
|
|
I see nothing in your code snippet that causes flickering.
How did you implement the "Custom drawings"?
When does the flickering happen? While resizing only?
Which controls flicker?
|
|
|
|
|
A seperate thread function created already which calls a function UpdateAllViews() as shown below every half a second which in turn calls Invalidate the CFP Dialog. This is done to continuously update some real time numerical values on the dialog. When I remove this line
pFPlate->Invalidate(FALSE);
then there is no flickering on the dialog. But the values are not updated. How to avoid this flickering without affecting the value updation.
void tUpdateAllViews( CMainFrame *pMainFrm )
{
while( 1 )
{
pMainFrm->UpdateAllViews();
Sleep(500);
}
}
void CMainFrame::UpdateAllViews()
{
if(pFPlate->GetSafeHwnd()) //CFP Dialog member variable
{
if(pFPlate->IsWindowVisible())
{
pFPlate->Invalidate(FALSE);
}
}
}
|
|
|
|
|
I'm a little confused by some of your code but generally I think you will
have to override WM_ERASEBKGND so that the background is not erased by the
default processing. Do not call the base class; just return TRUE.
|
|
|
|
|
Yes. done that. But still its flickering. It seems the problem is in the thread which calls the Invalidate for the Dialog.
Please help to find out what is wrong or how to correct the problem
|
|
|
|
|
But why do you call Invalidate if you haven't changed anything in the View?
|
|
|
|
|
1. Do you have to call Invalidate() from a thread? Could you use a timer in the dialog
and only update what is needed instead of invalidating the whole dialog?
2. Are your dialog controls embedded in a TabControl/TabPage? If so you will have to
create a custom TabControl and TabPage to override the OnEraseBackground() in those and
paint the background in a temp dc as well.
3. I'm not sure about this, but you may have to set the dialog style WS_CLIBCHILDREN to
include them in the dialogs clip region. Look at definition in msdn.
|
|
|
|
|
Additionally, I don't know what pFPlate is but if it's a pointer to the dialog,
could you create a function in the dialog to update what you need instead of
calling Invalidate().
|
|
|
|
|
I am not a real fan of MFC but I can tell you what windows API is doing.
Dialog backgrounds paint by WM_CTLCOLORDLG, WM_CTLCOLORSTATIC it used to be WM_CTLCOLOR and I suspect MFC still uses WM_CTLCOLOR because it has a couple of bugs.
Usually what you want to do is return a NULL_BRUSH with GetStockObject(NULL_BRUSH);
So this one if you paint the entire dialog then return a NULL_BRUSH
WM_CTLCOLORDLG message - Windows applications | Microsoft Docs[^]
MFC may use this one and again return a NULL_BRUSH
WM_CTLCOLOR message - Windows applications | Microsoft Docs[^]
That means it doesn't paint the background before it sends you an WM_PAINT
If you want/need to transparent overlay the bitmap you have to use a transparent colour to stop flashing
void CDemoDialog::OnPaint()
{
CPaintDC dc(this);
dc.TransparentBlt(
10, 10, bmp.bmWidth, bmp.bmHeight,
&pDCTmp,
0, 0, bmp.bmWidth, bmp.bmHeight,
RGB(255, 0, 0));
}
In vino veritas
modified 1-Mar-19 12:54pm.
|
|
|
|
|
I'm generating dialog templates programmatically for a win32 project. A thing I often want to do is size the dialog box such that the distance between the left edge of the client region and the left edge of the leftmost control is the same as that between the right edge of the rightmost control and the right edge of the client region. Since the size of the dialog box as specified in the template, I believe, includes the non-client area, the only way I know of to do this is to use AdjustWindowRect on a RECT representing the desired client region. Since this requires the handle of the window being adjusted, I can't do it until after the dialog has been created. So I was wondering...if I can't ensure equal margins until runtime, how is it possible that one can use the GUI editor Visual Studio provides to create dialogs with equal margins ahead of time? I want to be able to do that too.
|
|
|
|
|
You can select a set of controls in the editor and then use the toolbar tool that centres the group in the dialog. There are tools to centre horizontally or vertically, make equidistant, align together etc.
|
|
|
|
|
I don't know if I'm misunderstanding your question but if you want to resize the dialog
at runtime, you can calculate your control positions and use
SetWindowPos(NULL, -1, -1, cx, cy, SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER);
in the OnInitDialog() function.
sorry if I misunderstood.
|
|
|
|
|
Resizing at runtime is what I'm currently doing, and it's an acceptable solution, but if possible I would like to specify the size of the dialog in the template, which is generated before runtime, such that it's correct relative to the controls it contains to begin with, without need of resizing. The fact that the dialog editor can do this suggests that it is indeed possible somehow.
|
|
|
|
|
I did something like this a long time ago where I defined a dialog within a code module without the
ui editor and I think you will have to implement the use of DLGTEMPLATE which is used to define the dialog and all of the associated controls.
Take a look at InitModalIndirect() in the Mfc library dlgcore.cpp and I believe
there was some needed functions in occmgr.cpp that will help to some extent.
If you haven't used this structure before, it will required a bit of work.
Oh yes, I'm still on V2005 so if you have the latest visual studio there may be some changes.
Hope this is what you are looking for.
|
|
|
|
|
A blank empty dialog template centred in it's parent at runtime and done the way speedbump is suggesting is coded below. It is pretty straight forward you just need to allocate global memory block as the template and you can fill the controls in at initialization
int DialogFromTemplate (HWND parent, int DialogWth, int DialogHt, char* DlgTitle, DLGPROC handler)
{
int nchar, ret;
int x, y;
RECT r;
HGLOBAL hgbl;
LPDLGTEMPLATE lpdt;
LPWORD lpw;
LPWSTR lpwsz;
GetClientRect(parent, &r);
x = ((r.right+r.left)/2);
y = ((r.bottom+r.top)/2);
x -= DialogWth/2;
y -= DialogHt/2;
x /= 2;
y /= 2;
hgbl = GlobalAlloc(GMEM_ZEROINIT, 1024);
if (!hgbl) return -1;
lpdt = (LPDLGTEMPLATE)GlobalLock(hgbl);
lpdt->style = WS_POPUP | WS_CAPTION | WS_SYSMENU;
lpdt->cdit = 0;
lpdt->x = x;
lpdt->y = y;
lpdt->cx = DialogWth/2;
lpdt->cy = DialogHt/2;
lpw = (LPWORD)(lpdt + 1);
*lpw++ = 0;
*lpw++ = 0;
lpwsz = (LPWSTR)lpw;
nchar = 1 + MultiByteToWideChar(CP_ACP, 0, DlgTitle,
-1, lpwsz, 50);
lpw += nchar;
*lpw++ = 0;
GlobalUnlock(hgbl);
ret = (int)DialogBoxIndirectParam(GetModuleHandle(0),
(LPDLGTEMPLATE)hgbl, parent, Handler, 0);
GlobalFree(hgbl);
return ret;
}
In vino veritas
modified 22-Feb-19 12:16pm.
|
|
|
|
|
Looks familiar... good job
|
|
|
|
|
It is impossible (*) to do.
Win32 and MFC do not implement design time dynamic resizing of dialog controls, and offer no automatic run time resizing of dialog controls (other than MoveWindow and SetWindowPos ).
You need to do it manually; there are many 3rd party solutions available that will manage resizing at run time.
All of them sucks one way or the other.
I'd rather be phishing!
|
|
|
|
|
Incorrect look at WM_INITDIALOG the message exists to do it. You simply move and resize the child windows before they become visible that is the whole point for the message to exist (read the message description). Everything is created but nothing has been drawn at that point.
WM_INITDIALOG message - Windows applications | Microsoft Docs[^]
In vino veritas
modified 22-Feb-19 11:45am.
|
|
|
|
|
There are no mechanisms in MFC or Win32 to automatically place and resize controls; you have to do it manually in WM_SIZE.
WM_INITDIALOG will let you place controls at runtime, yes, but that's it; there is no API that says, hey, I want to attach the left side of my edit box to the left side of the dialog.
I'd rather be phishing!
|
|
|
|
|
The OP didn't ask for that ... he asked for the ability to rescale a template or resource based dialog which we all do for high DPI apps because the inbuilt behaviour sucks.
Also for the record there are groups of controls that will do exactly what you have described they are called docking controls all you decide is where you want the anchor when you create them. I can easily give you a group of control that will automatically anchor themselves to the left side of a dialog it's trivial and CDockablePane in particular are often run that way in a dialog.
In vino veritas
modified 23-Feb-19 10:49am.
|
|
|
|
|
In standard Win32 API the dialog will be passed a WM_INITDIALOG message after it is created but before it is displayed.
WM_INITDIALOG message - Windows applications | Microsoft Docs[^]
You can simply do a call to GetClientRect to get the parent area and change the dialog that is what the message is for. You can also use CreateDialogIndirectParam, CreateDialogParam, DialogBoxIndirectParam, or DialogBoxParam and pass
a pointer to the area or anything else you may want to do at runtime.
If you have not got access to the dialogs parent window handle you can get it by using the dialog handle with
GetParent function | Microsoft Docs[^]
The dialog has been created and all functions on the handle work it just has not been made visible at that point.
You can also move and resize your child windows by handle or ID, they have all been created but nothing is visible at that point. You can also manually add child windows if you so desire at that point.
The WM_PAINT message to draw the dialog will be straight after that message and if it's a modal dialog it will then enter modal mode.
I am not sure how MFC encapsulates the WM_INITDIALOG probably ONINITDIALOG or something like that.
In vino veritas
modified 22-Feb-19 12:18pm.
|
|
|
|
|
What I'm doing already is setting the using the size information in the dialog template to store the size I want the client region to be, then calling GetWindowRect, AdjustWindowRect, and MoveWindow from the WM_INITDIALOG implementation. From the answers I've gotten, it sounds like this is about the most direct solution I could hope for, which is good to know.
|
|
|
|