C / C++ / MFC

26-Oct-01 6:06

The app that I am making has this sucken in look where all the controls are at. I tried changing the windows style in this function, but that didn't work. I am trying to get rid of the sunken in look and make the whole area where the controls are located raised up with the rest of the app.
I sure appreciate any help.

Fazlul Kabir26-Oct-01 6:36

Fazlul Kabir

26-Oct-01 6:36

Two questions:
(1) Is your app MDI or SDI?
(2) What kind of view you are using to display controls?

// Fazlul

Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com

vhalik26-Oct-01 6:39

26-Oct-01 6:39

The app is SDI and I am using IDD_MFC_FORM.

vhalik26-Oct-01 6:57

26-Oct-01 6:57

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CFrameWnd::PreCreateWindow(cs) )
return FALSE;

cs.style = WS_OVERLAPPEDWINDOW;

return TRUE;
}

I thought by adding the OVERLAPPEDWINDOW would fix this problem, but it does not seem to do it.

Fazlul Kabir26-Oct-01 7:03

Fazlul Kabir

26-Oct-01 7:03

No, I guess WS_OVERLAPPEDWINDOW style bit is already set for MFC frame windows before ::PreCreateWindows() gets the hit, so this won't help.

I think I have a solution, I'll come back soon.

// Fazlul

Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com

Fazlul Kabir26-Oct-01 7:40

Fazlul Kabir

26-Oct-01 7:40

Here is a quick solution for you.

Overide CMainFrame's ::ReCalcLayout() and add this

void CMainFrame::RecalcLayout(BOOL bNotify) 
{
	// TODO: Add your specialized code here and/or call the base class
	CFrameWnd::RecalcLayout(bNotify);

	CView* pView = GetActiveView();
	if(pView && pView->GetSafeHwnd())
	{
		CRect rect;
		pView->GetWindowRect(rect);
		ScreenToClient(rect);
		rect.InflateRect(2, 2);
		pView->MoveWindow(rect);
	}
}

This would take out the client edges nicely provided that you don't have any controlbars docked on the frame.

This is a quick and dirty solution. There could be other ways of doing this. I'll try to find other solution later.

// Fazlul

Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com

vhalik26-Oct-01 7:50

Critical Section problems...

26-Oct-01 7:50

Nice!!! This worked like a charm! Thank you for taking the time on this problem!

LukeV26-Oct-01 5:59

LukeV

26-Oct-01 5:59

Here's part of my code:

void CValidateurlDlg::OnButton1()
{
...

for(int i=0;i<m_purllist->GetCount();i++)
{
...
ValUrlMgr.Validate(this, url);
}
}

void CValidateUrlMgr::Validate(CWnd* pWnd, Url UrlInfo)
{
THREADPARMS* ptp = new THREADPARMS;
ptp->UrlInfo = UrlInfo;
ptp->pWnd = pWnd;
ptp->pCriticalSection = &m_cs;
ptp->pEvent = &m_event;

CWinThread* pThread = AfxBeginThread (ThreadFunc, ptp,
THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);

::DuplicateHandle (GetCurrentProcess (),
pThread->m_hThread, GetCurrentProcess (), &m_hThread,
0, FALSE, DUPLICATE_SAME_ACCESS);

pThread->ResumeThread ();
}

//////////////////////////

UINT ThreadFunc(LPVOID pParam)
{
...

THREADPARMS* ptp = (THREADPARMS*) pParam;
Url UrlInfo = ptp->UrlInfo;
CCriticalSection* pCriticalSection = ptp->pCriticalSection;
CEvent* pKillEvent = ptp->pEvent;
CWnd* pWnd = ptp->pWnd;
delete ptp;

pCriticalSection->Lock ();

Doing some stuff....

pCriticalSection->Unlock ();

return 0;
}

If I dont comment the Lock() / Unlock() lines, I get an Unhandled error message. Not using them = works great! What's the use of critical sections then??? Confused | :confused:

thanks!

Joaquín M López Muñoz26-Oct-01 7:16

26-Oct-01 7:16

This may have nothing to do with your problem, but have you taken into account that CCriticalSections by default are locked right after construction? Maybe you'll have to add m_cs.Unlock() somewhere on the ctor for CValidateUrlMgr. If this is already known to you, excuse my guessing around.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

LukeV26-Oct-01 7:49

LukeV

26-Oct-01 7:49

Hi,

I did not know that (thanks for the tip!), but I tried what you suggested with no good results. Frown | :(

Although I have to say that I launch multiple instances of the same thread (look at my code), so I wonder if it's not failing when the thread function gets executed the 2nd time...

I'm sorta new to threads, just trying to figure out how they work...

Thanks again!

Joaquín M López Muñoz26-Oct-01 8:30

26-Oct-01 8:30

Guess more context is needed to help you find the problem. For instance, are you sure that CValidateurDlg exits only when all threads launched by OnButton1 have terminated? The m_hThread variable suggest you only keep track of the last thread launched.

Joaquñin M López Muñoz
Telefónica, Investigación y Desarrollo

Tim Deveaux26-Oct-01 10:20

Tim Deveaux

26-Oct-01 10:20

This doesn't really answer your question, but here's the basics of a little class that can be used for simple locks:

CX_Lock::CX_Lock(CRITICAL_SECTION *cs){
    EnterCriticalSection(cs);
    m_pCriticalSection = cs;        // ok - we're in - save for exit.
}
 
CX_Lock::~CX_Lock(){
    LeaveCriticalSection(m_pCriticalSection);   // all we need to do.
}

Now, for a class whose, say, accessor functions should be guarded, declare a member CS:

CRITICAL_SECTION    m_cs;               // synchronization object

And don't forget to call InitializeCriticalSection(&m_cs); in the constructor and DeleteCriticalSection(&m_cs); in the destructor.

Then inside a block of code in a memeber fn you just declare a local lock object like so:

DWORD MyClass::GetMyMemberVar()
{
    CX_Lock lock(&m_cs);   // protect access

    return m_dwMyMemberVar;
}

And voila, you've serialized thread access to the code in the block where the lock object has scope.

This has the advantages of exception safety (unwinding the stack will call the lock's dtor and exit the CS) and less code to muck with.

As an additional nice touch, declare the default ctor private (so people will use the class properly).

Not sure where I stumbled on this - I thought the MFC had an equivalent, but not sure.

How to set a bitmap as a dialog background ?

HintiFlo23-Jan-02 1:12

HintiFlo

23-Jan-02 1:12

Try out locking with the primitives:

CRITICAL_SECTION lock;

in the ctor: ::InitializeCriticalSection(&lock);
locking: ::EnterCriticalSection(&lock);
unlocking: ::LeaveCriticalSection(&lock);
in the dtor: ::DeleteCriticalSection(&lock);

I often heard about porblems with MFC-sync-Classes.

mfg HintiFlo

adara26-Oct-01 4:58

adara

26-Oct-01 4:58

How to set a bitmap as a dialog background ?
Thanx.

Re: How to set a bitmap as a dialog background ?

Joaquín M López Muñoz26-Oct-01 5:48

overload resolution in VC 6.0

26-Oct-01 5:48

It goes along this:

Class CYourDlg: public CDialog{
    ...
    CBitmap m_bitmap_background;
    BITMAP m_bmInfo_background;
    ...
};

BOOL CYourDlg::OnInitDialog()
{
    ...
    m_bitmap_background.LoadBitmap(IDB_BACKGROUND);
    ::GetObject(m_bitmap_background,sizeof(BITMAP),&m_bmInfo_background);
    ...
    return TRUE;
}

BOOL CYourDlg::OnEraseBkgnd(CDC* pDC) 
{
    CRect rect;
    GetClientRect(rect);

    CDC dcMem;
    dcMem.CreateCompatibleDC(pDC);
    
    HBITMAP* pBmpOld=(HBITMAP*)::SelectObject(dcMem.m_hDC,m_bitmap_background);

    for(int y=rect.top;y<rect.bottom;y+=m_bmInfo_background.bmHeight){
        for(int x=rect.left;x<=rect.right;x+=m_bmInfo_background.bmWidth){
            pDC->BitBlt(x,y,m_bmInfo_background.bmWidth,m_bmInfo_background.bmHeight,
                        &dcMem,0,0,SRCCOPY);
        }
    }

    ::SelectObject(dcMem.m_hDC, pBmpOld);

    return TRUE;
}

This is for a tesellation effect (sort of like background images in HTML). Easy to adapt it to your specific needs.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

thanx

adara26-Oct-01 12:19

adara

26-Oct-01 12:19

Patrick D Owens26-Oct-01 4:46

Patrick D Owens

26-Oct-01 4:46

I have a PString class that derives from CString. In it, I overload the + operator so I can add a PString and long variable to give me a new PString. It works fine in VC 5.0, but while converting to VC 6.0, I get a C2666 error saying it cannot determine which overloaded + to use.
Here is the code segment:

PString strTemp1 = "abc";
long lTemp1 = 123;
PString strTemp2 = "def";
(1) strTemp2 = strTemp1 + strTemp2; // works fine.
(2) strTemp2 = strTemp1 + lTemp1; // C2666 error.
(3) strTemp2 = +(strTemp1, lTemp1); // no error.
(4) strTemp2 = ::operator +(strTemp1, lTemp1); // no err

class PString : public CString
{
public:
....
PCSGENRL_EXP_TYPE friend PString operator +( const PString& string1, const PString& string2 );
PCSGENRL_EXP_TYPE friend PString operator +( const PString& string, TCHAR ch );
PCSGENRL_EXP_TYPE friend PString operator +( TCHAR ch, const PString& string );
PCSGENRL_EXP_TYPE friend PString operator +( const PString& string, LPCTSTR lpsz );
PCSGENRL_EXP_TYPE friend PString operator +( LPCTSTR lpsz, const PString& string );

PCSGENRL_EXP_TYPE friend PString operator +(const PString& string,const long& value);
PCSGENRL_EXP_TYPE friend PString operator +(const long& value, const PString& string);
PCSGENRL_EXP_TYPE friend PString operator +(const PString& string,const double& value);
PCSGENRL_EXP_TYPE friend PString operator +(const double& value, const PString& string);
PCSGENRL_EXP_TYPE friend PString operator +(const PString& string,const int& value);
PCSGENRL_EXP_TYPE friend PString operator +(const int& value, const PString& string);
PCSGENRL_EXP_TYPE friend PString operator +(const PString& string, const ULONG& value);
PCSGENRL_EXP_TYPE friend PString operator +(const ULONG& value,const PString& string);

Why does line (2) give an error, while lines (3) and (4) give no compile error? Aren't they the same instruction?
Any help would be appreciated.

Pat

C^hris L^osinger26-Oct-01 4:55

C^hris L^osinger

26-Oct-01 4:55

it probably can't decide between long and int for the second value.

try this : strTemp2 = strTemp1 + (long)lTemp1;

=c

Smaller Animals Software, Inc.
http://www.smalleranimals.com

Patrick D Owens26-Oct-01 5:16

Patrick D Owens

26-Oct-01 5:16

I tried
strTemp2 = strTemp1 + (long)lTemp1;
and it still gives the C2666 error.
I agree that it probably can't decide the type of that second value, but I have tried changing the overload definitions to

PCSGENRL_EXP_TYPE friend PString operator +(const PString& string, const long& value);
and
PCSGENRL_EXP_TYPE friend PString operator +(const PString& string, long& value);
and
PCSGENRL_EXP_TYPE friend PString operator +(const PString& string, long value);

From what I have read on this error in the help pages, if the compiler can't find an exact match, then it will try to do some conversions to get a match.
You would think that one of the above 3 overloaded definitions would give an exact match so the compiler wouldn't have to do any conversions. But I guess I am missing something. I assume the first argument is fine because I can add a PString and a PString. So it must be something with the second (long) argument, but I can't figure it out.

Pat

Joaquín M López Muñoz26-Oct-01 6:53

26-Oct-01 6:53

Amusing problem! First, your line (3) is probably not the same as (2), but rather a very different expression that by chance happens to compile. If I'm right, the compiler interprets it as a call to unary operator + applied to strTemp1, lTemp1, which in turn is parsed as the sequencing operator , applied to strTemp1 and lTemp1. In a nutshell, (3) is parsed as:

strTemp2 = +(strTemp1, lTemp1) // apply operator , to yield:
strTemp2 = +(lTemp1);          // apply unary operator + (idempotent for longs) to yield:
strTemp2 = lTemp1;             // apply user defined conversion from long to PString

For this analysis to hold water, some conversion from long to PString must exist. Otherwise I'm wrong (please confirm this). You can also check this hypothesis simply by printing out the result of (3) and seeing if it corresponds to the "stringed" value of lTemp1.

Then, if (3) actually is ruled out, we are left with solving the riddle of (4) compiling fine and (2) producing a C2666 error. IMHO, the only way for (4) not being equivalent to (2) is that your addition operators are defined in a namespace other than the global namespace, and the :: in ::operator + is making the difference by narrowing the set of addition operators applicable. Again, you're the one who can confirm or deny this.

So, if (3) and (4) give no error for the reasons I said (which I'm far from sure), then probably (2) fails legally to compile due to an overabundance of applicable operators and conversion. See this Microsoft article for an analysis of a problem resembling yours.

Why VC++ 5.0 compiled fine and 6.0 complains? Well, maybe is 6.0 being more standard compliant with respect to Koening lookup, who knows.

As you see, this is just a chain of speculations. Some of them you can easily check out (please inform back).
Also, I suggest you post this problem to comp.lang.c++.moderated for more authoritative opinions.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Filling CListCtrl from dll problem...

Patrick D Owens26-Oct-01 9:16

Patrick D Owens

26-Oct-01 9:16

Thanks Joaquin,
You are right on in your analysis. The result of line (3) is the value of lTemp1 "stringed", exactly as you broke it down. In fact, I thought my overload of PString + PString was working, but I stepped into the code with the debugger, and it wasn't going to my PString overload of '+', but to the CString overload of '+'. So it was doing a PString to CString conversion for me behind the scenes..

In researching this problem, the only thing I could come up with is that there are 2 ways to override the operators. One is to have a 'friend' function within the class. The other is to define it globally, outside the class. So I took my + overrides out of the PString class and defined them globally. Now things seem to be working just fine. I guess there was some scope issues.

BTW, in reading about the C2666 error, I did read that the reason behind errors like this is because Microsoft is implementing/enforcing more of the accepted C++ standards, just as you speculated.

Thanks for your analysis on this one.

Pat

26-Oct-01 4:39

I use following export for getting pointer on class derived from CListCtrl:

extern "C" void APIENTRY ExportToListCtrl(CBaseListCtrl *pBaseList) {};

Dll should fill data that it gathers into that list control, and actually it does the job, but when i build it as Release, list control doesnt show any results (all dlls functions for filling it works, but none of the data are shown)! I tryed the same using HWND for dll function parameter and attaching HWND to CBaseListCtrl that is declared inside dll and it worked, but the problem is that i desperatly need to use it trough *pBaseList as CBaseListCtrl has some CListCtrl functions overided as it allso fills some of its own internal structures. Dll is loaded dynamicaly (LoadLibrary(), GetProcAddress()).

Anyone knows how to make it work? Plz?

Re: Filling CListCtrl from dll problem...

Joaquín M López Muñoz26-Oct-01 7:27