Help with mfc

[2kaud]

Thankyou kaud
Were using visual studio . Mostly MFC, but there is legacy owl still there. Not sure how VS handles that

Probably you have OWLNext. How OWL interacts with MFC.........

[pdk5]

Sorry, but I actually donot understand the legacy concepts .. (but i was told, some code, still inherits from owl ).

Btw, now i am trying to see if i can use the ScreenToClient to move the rectangle to the right corner. Actually issue is that i donot know the width of parent window

[2kaud]

Actually issue is that i donot know the width of parent window

Well if you have the handle of a child window, you can get the handle of its parent and from that you can get the size of that window.

GetParent()
https://learn.microsoft.com/en-us/wi...user-getparent

GetWindowInfo()
https://learn.microsoft.com/en-us/wi...-getwindowinfo

These are WIN32 functions. There'll be similar MFC methods.

[pdk5]

Thankyou very much kaud, ill check..

I also need to make sure the co-ordinates need to match the screen co-ordinates

[2kaud]

To get the size of the screen, use GetSystemMetrics()
https://learn.microsoft.com/en-us/wi...ectedfrom=MSDN

See SM_CXFULLSCREEN, SM_CYFULLSCREEN

There's loads of info about Windows available.

[ovidiucucu]

Aside note...

Dealing with legacy projects is not an easy task and requires some knowledge and experience. Simply getting tweaks from old sources is not enough. This particular case requires at least basic understanding of Windows concepts.

Especially for GUI part, I kindly recommend Win32 Programming by Brent E. Rector and Joseph M. Newcomer. It's an old book, but still
actual and it was more than a "bible" for me.

Then, programming with MFC or OWL, which are just C++ wrappers around plain Windows API, is like a walking in the park.

[ovidiucucu]

Returning to our sheep...

First note that all Windows controls like buttons, list boxes, combo boxes, and so on are windows, as well. You can see that in plain WinAPI: all are created by a call of CreateWindow(Ex). Also, in MFC CButton, CListBox, CComboBox etc. are derived from CWnd.

On the other hand, the shapes drawn using GDI, like Rectangle, Ellipse and so on, ARE NOT windows.

So, when we say "parent window", we refer to a control, which generally is a "child window" and not to a shape.
See also: What is a child window.
When we are talking about drawing a shape, simply refer to (the clent area of) a window.

Leaving a little bit theory away, here is an example of drawing a rectangle in the client area of a dialog.

void CDemoDlg::OnPaint()
{
        // do not call base class method!
        // CDialog::OnPaint();

        // get device context for painting
        CClientDC dc(this);

        const int nTopMargin = 10; // just for demo purpose
        const int nRightMargin = 15;
        const int nShapeWidth = 60;
        const int hShapeHeight = 30;

        // get the dialog's client area
        CRect rcClient;
        GetClientRect(rcClient);

        // calculate the shape coordinates
        int x = rcClient.right - nShapeWidth - nRightMargin;
        int y = rcClient.top + nTopMargin;

        // set the shape rectangle
        CRect rcShape(CPoint(x, y), CSize(nShapeWidth, hShapeHeight));

        // draw the shape
        dc.Rectangle(rcShape);
}

Additional notes

• client area is the area that excludes the frame, caption and menu;
• a dialog is a special type of window, designed as a container for child controls (buttons, listboxes, and so on) and not for drawing;
• I gave just an example based on your question, but generally prefer drawing in a view (see MFC classes CView and CScrollView);
• if have to show some drawing in a dialog, then place it in a custom or ActiveX clild control.

[2kaud]

Especially for GUI part, I kindly recommend Win32 Programming by Brent E. Rector and Joseph M. Newcomer. It's an old book, but still
actual and it was more than a "bible" for me.

The 'classic' book is Programming Windows by Charles Petzold (5th edition 1998). This book was so used that it was often referred to just as Petzold.
https://www.amazon.com/Programming-W...95X/ref=sr_1_4

For MFC, the 'classic' book is Programming Windows with MFC by Jeoff Prosise (2nd edition 1999) . This is for MFC what Petzold was to Windows.
https://www.amazon.com/Programming-W...50/ref=sr_1_10

Note that these books (and also Rector's (1997) - which I agree is a good Windows book but IMO Petzold is easier to read) are quite old and reflect c/mfc programming as of the time they were written. Also note that they were written for Windows NT/95 - so don't include any windows functions since

But if you need to get to grips with old-style windows programming then these are recommended.

If you want to know what's available for Windows and have small demonstrative examples then there's Windows 2000 API Superbible which is based on Win 2000.
https://www.amazon.com/Windows-Super...WWI/ref=sr_1_3

[pdk5]

@ovidiucucu : Thankyou very much for the help. And yes, the help with the book, which i will try to read.
@kaud : Thanks for the help and reference books.

Btw, sorry for the delay.
I am yet to go through the details you have given.
Btw the day i posted the question, I got it with the following code :

void EmfCellListRend::DrawRectangle(EmfCellListRendDrawingParams* pParams, TDC& dc, CEmfCellList *pCelllist, int nEmfUnit, bool bDisplayRight)
 {
	ILogicalLayerManager&	rLogLayManager  = DataManager::GetInstance().GetLogicalLayer();

	// The font is not changing when i use the owl dc to mfc dc.
	// Need to check why !!!
	CDC* pDC		= CDC::FromHandle(dc.GetHDC());
	CFont* pCurrent = pDC->GetCurrentFont();
	
	// TODO_PRIYA_EMF3: Choosing a new font (unrelated to dc context works)
	CFont font;
	font.CreatePointFont(80, _T("Verdana"));

	CFont* pOldFont = pDC->SelectObject(&font);
	SetBkMode(dc,		OPAQUE);
	SetBkColor(dc,		TColor(RGB(0, 255, 0)));

	tstring sEmfUnit	=_T(TXPower2::GetEmfUnitString(TXPower2::GetCurrentEmfUnit()));
	tstring sFinaText	=_T("EMF Cell list ");
	sFinaText			+=sEmfUnit;
	for (int i = 0; i < (int)pParams->GetNumCovCells(); i++)
	{
		const MultiTechCell* pObjCell((const MultiTechCell*)rLogLayManager.Find(OT_MULTI_TECH_CELL, pCelllist[i].m_CellKey));
		tstring		sNewLine		= _T("\n");
		TgNetType	eTechType		= 	pObjCell->GetActiveTechnologyMode();
		CString		strTechType		= MAIN_NET_TYPE_STRINGS_SWITCH( eTechType );
		std::string str(strTechType, strTechType.GetLength());
		tstring		sTechtype		= _T(str);
		tstring		sCellId			= _T(pObjCell->GetID());

		const double dCurrentEmf_dBVm = pCelllist[i].m_dCellEMF_dBVm;
		ASSERT(dCurrentEmf_dBVm > -200.0);// If dCurrentEmf_dBVm is <= -200.0, we should probably force dCurrentEmf_dBVm to be -200 also ??

		// Convert dBV/m to dBmW/m2 if necessary
		TXPower2 helper(dCurrentEmf_dBVm, EMFUNIT::dBVm);
		const EMFUNIT emfUnit	= TXPower2::GetCurrentEmfUnit();					// The EMF unit chosen by the user in the preferences
		const double dEmf		= static_cast<float>(helper.EMFLevelAs( emfUnit ));	// Either dBV/m or dBmW/m2

		sFinaText+=sNewLine+sTechtype+" "+sCellId+"  "+_T(std::to_string(dEmf));
	}

	HWND hwnd = WindowFromDC(dc);
	CRect rect;
	GetClientRect(hwnd, &rect);

	RECT rc={ 0, 0, 400, 0 };
	UINT format = DT_LEFT | DT_TOP | DT_EDITCONTROL | DT_WORDBREAK;
	DrawText(dc, sFinaText.c_str(), -1, &rc, format | DT_CALCRECT);

	// Adjust co-ordinates of rectangle, to fit the parent window and shift 
	// rectangle to right.
	// From the mouse co-ordinates, check if co-ordinates fall on
	// right corner, choose to display on left and vice versa.
	if( bDisplayRight)
	{
		int long temp = rc.right - rc.left;
		rc.left = rect.right - temp;
		rc.right = rect.right;
		rc.top = rect.top;
	}

	DrawText(dc, sFinaText.c_str(), -1, &rc, format);

	pDC->SelectObject(pCurrent) ;

	DeleteDC(dc);

	dc.RestorePen();

Now the background is changed to the set colour (green). But it is only if the text is there (see the red marker i drew manually aroubd that )

[ovidiucucu]

And about moving the child windows (controls) inside the client area of the parent...

One easy method is to get the client area of the parent (call CWnd::GetClientRect), calculate the the child coordinates relative to this area and then call CWnd::MoveWindow.

Here is am example of moving child controls, relative to top-right corner of the parent dialog.

void CDemoDlg::MoveControlTopRight(UINT nCtrlID, int nTopMargin, int nRightMargin)
{
    CRect rcClient;
    GetClientRect(rcClient);

    CWnd* pCtrl = GetDlgItem(IDOK);
    if (pCtrl->GetSafeHwnd())
    {
        // get the control's size
        CRect rcControl;
        pCtrl->GetWindowRect(rcControl);
        int nWidth = rcControl.Width();
        int nHeight = rcControl.Height();

        // calculate the new control's coordinates
        int x = rcClient.right - nWidth - nRightMargin;
        int y = rcClient.top + nTopMargin;

        // set the new control's rectangle
        CRect rcNew(CPoint(x, y), CSize(nWidth, nHeight));
        // move the control
        pCtrl->MoveWindow(rcNew);
    }
}

Now you can call it from CDemoDlg::OnInitDialog and CDemoDlg::OnSize (WM_SIZE message handler) for a bunch of controls.
It looks not very complicated. However, if using MFC, there is even an easier method: can set the Moving Type (also Sizing Type) at design time.

Have a look here: Dynamic Layout.

[pdk5]

@ovidiucucu : Thankyou very much. I will go through this and try this idea. Just wanted to say, thankyou very much for your valuable time and patience in helping me. Really appreciated

[ovidiucucu]

You are welcome!

[off-topic]
Just joking a little bit: if I had to deal with that (legacy) code, I would be tempted to hit the monitor with the keyboard.
But no problem, everything can be fixed.

Now seriously: for each new problem, please open a new discussion thread. Otherwise, becomes hard to follow what we are talking about.

And please, give it a meaningful title, for example "DrawText - Problem with background color". Someting like "Help with mfc" is too general and may be thousands of questions about that.

[2kaud]

@pdk5 - you might find this book of interest/help when dealing with legacy code.

https://leanpub.com/legacycode

[pdk5]

@ovidiucucu : Thankyou very much for the comments . You being expert in this area, felt so bad about legacy code, you can think of my situation
I will add a new topic for this issue

@kaud: Thankyou very much help and reference books..