C / C++ / MFC

Re: calling applications in VC++ etc,

26-Oct-01 8:56

1- CreateProcess();
2- CopyFile()
3- GetCurrentDirectory();

Cheers Big Grin | :-D

Carlos Antollini.
Green Alien | [Alien]

Today is Friday!!! Beer | [beer]

for All!!!

Navin26-Oct-01 8:59

Navin

26-Oct-01 8:59

MSDN has all these functions, although these types of functions are typically Windows API, and not wrapped in any way by MFC.

For running a process, there are a couple others:
1. ShellExecute: it is nice if you have a program's date (e.g., a RealPlayer file) and want the system to find the app that handles it.

2. CreateProcess: if you want full control over creation, but it is probably the most complicated of the ways to run a program.

The early bird may get the worm, but the second mouse gets the cheese.

(mfc) Checking a checkbox during CPropertyPage constructor

Simon Walton26-Oct-01 6:27

Simon Walton

26-Oct-01 6:27

I have a property sheet, and one property page (CFirstPage). m_showInfo is a bool, and m_ctrShowInfo is the DDX control for the checkbox. I want to initialise the property page with the current settings.

In my implementation file;

CFirstPage::CFirstPage() : CPropertyPage(CFirstPage::IDD)
{
	// Setup the controls on the property page

	if(m_showInfo)
		m_ctrShowInfo.SetCheck(1);
	else
		m_ctrShowInfo.SetCheck(0);
}

If i use SetState() instead, everything goes well. However, SetCheck() crashes at CButton::SetCheck. Any ideas why?

---
"Transmit in all known frequencies and in all known langauges, including Welsh."

Re: (mfc) Checking a checkbox during CPropertyPage constructor

C^hris L^osinger26-Oct-01 6:42

C^hris L^osinger

26-Oct-01 6:42

because m_ctrShowInfo isn't a "window" yet, and SetCheck is sending a window message.

try setting this in your InitDialog

-c

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

Re: (mfc) Checking a checkbox during CPropertyPage constructor

Simon Walton26-Oct-01 7:13

Simon Walton

26-Oct-01 7:13

Argh! My head is hurting. All this MFC i've been doing has reduced my potential lifespan. I actually figured it out whilst watching neighbours, but thanks anyway. Smile | :)

---
"Transmit in all known frequencies and in all known langauges, including Welsh."

Re: (mfc) Checking a checkbox during CPropertyPage constructor

Carlos Antollini26-Oct-01 6:52

Re: (mfc) Checking a checkbox during CPropertyPage constructor

26-Oct-01 6:52

Look into the declaration of m_ctrShowInfo Is a CButton or another thing?

Best Regards!!!

Carlos Antollini.
Green Alien | [Alien]

Today is Fridad!!! Beer | [beer]

for All!!!

Carlos Antollini26-Oct-01 6:54

Re: (mfc) Checking a checkbox during CPropertyPage constructor

26-Oct-01 6:54

Look into the declaration of m_ctrShowInfo Is a CButton or another thing?
But the problem is that you are in the contructor of your class, and the control have not HWND yet.....
Best Regards!!!

Carlos Antollini.
Green Alien | [Alien]

Today is Fridad!!! Beer | [beer]

for All!!!

Carlos Antollini26-Oct-01 6:56

CMainFrame::PreCreateWindow(CREATESTRUCT& cs)

26-Oct-01 6:56

Try to do that in the InitDialog. In that instance the Hwnd exists

Best Regards!!!

Carlos Antollini.
Green Alien | [Alien]

Today is Friday!!! Beer | [beer]

for All!!!

vhalik26-Oct-01 6:06

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

Joaquín M López Muñoz

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

Joaquín M López Muñoz

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.