C / C++ / MFC

ns19-Sep-02 5:08

19-Sep-02 5:08

So we are limited only to functions that dont have any cDialog controls in them.

We cant do

CTest myTest;
myTest.DoStuff();
myTest.DoModal();

where

 CTest::DoStuff()
{
 m_editInCTest.SetWindowText("a");
}

right?

So the functions we can call are only for setting variables in the CTest.

Just making sure,
Smile | :)

Thanks,
ns

TyMatthews19-Sep-02 5:27

19-Sep-02 5:27

Yeah, this is the same as calling SetWindowText() directly. You can't do it either way because your window doesn't exist yet. You have to squirrel away the variable for use later on, once the window does exist.

You can always call other functions of CTest, just not any that deal with windows Smile | :)

Which pretty much limits you to DoModal() and anything you've written yourself.

Here's what is really happening under the hood. SetWindowText() is an immediate action that needs to occur. This is also an MFC-specific function in CWnd. MFC handles this particular action by sending a low-level windows message, likely via the SendMessage() API call, named WM_SETTEXT. SendMessage() only works when you specify a valid handle to a pre-existing window. Your window doesn't exist yet, so this parameter would be NULL.

If you called SendMessage() yourself with a NULL parameter, the result is probably undefined. It likely just goes nowhere. MFC is protecting you from this unfortunate situation by kicking out an ASSERT and gently reminding you that you can't do this yet. SetWindowText and the many other MFC functions of CWnd are just protective wrappers around the Win32 API. If you didn't get this ASSERT, you'd never know that your caption wasn't being set properly, and you'd be looking all over the place trying to figure out why. God bless MFC Poke tongue | ;-P

Hope this helps-

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

ns19-Sep-02 8:21

19-Sep-02 8:21

Hey thanks for that deeper insight! Yep - MFC is cool.
Smile | :)

Thanks,
ns

Maximilien19-Sep-02 5:37

Maximilien

19-Sep-02 5:37

no, that doesn't work either, because the Cdialog is not realized yet, it is realized when it is created.

You can set variables, do non-windows oriented processing, but you can't set the text to a control until the "WINDOW" is created.

You have to overwrite the OnInitDialog method to initialize dialog controls.

Max.

ns19-Sep-02 8:18

19-Sep-02 8:18

Thanks for that info! I didnt have time to test it.... Smile | :)

Thanks,
ns

Volatile variable...

Anonymous19-Sep-02 4:40

Anonymous

19-Sep-02 4:40

Hello world!!!

Why doesn't this compiled?

int main(int argc, TCHAR* argv[], TCHAR* envp[])
{
	volatile int pint[1] = {456};
	int* p = pint;
	return 0;
}

But this well:

int main(int argc, TCHAR* argv[], TCHAR* envp[])
{
	int pint[1] = {456};
	int* p = pint;
	return 0;
}

How to convert a volatile int* to a int*???
Is this possible???

Thanks in advance...

TyMatthews19-Sep-02 4:50

19-Sep-02 4:50

Just add the volatile keyword to your pointer.

int main(int argc, TCHAR* argv[], TCHAR* envp[])
{
         volatile int pint[1] = {456};
         volatile int* p = pint;
         return 0;
}

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

Raphael Kindt19-Sep-02 5:31

Raphael Kindt

19-Sep-02 5:31

But the problem is that I can do that... Because the int* p = pint is (in fact) an argument of a function that I don't have any access...
This is why I try to "transtype" this variable!

Hello World!!! Smile | :)

from Raphaël

Michael Dunn19-Sep-02 5:44

Michael Dunn

19-Sep-02 5:44

Well, you can do this:

int* p = const_cast<int*>(pint);

however if the original is volatile, it means the compiler should never optimize access to the variable. Removing volatile from your pointer gets around that, which might lead to strange problems.

--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm

PreTranslateMessage return value

Raphael Kindt19-Sep-02 5:58

Raphael Kindt

19-Sep-02 5:58

This compile... thanks...
The "volatile" code is necessary because the variable pint could be changed by another thread at any time.

And why not use this syntax to "transtype" ???

int* p = (int*)(pint);

Hello World!!! Smile | :)

from Raphaël

ns19-Sep-02 4:20

19-Sep-02 4:20

I did the following which works fine. But then I changed (to see what happens ) the FALSE (in red in code) to TRUE and it still works
the way I want it. I am puzzled because I thought that returning TRUE in this function meant ignore the Enter. But it doesnt, and responds to Enter just like when it was FALSE.

BOOL CTest::PreTranslateMessage(MSG* pMsg) 
{

	
if   ( pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_RETURN )

	if 	(GetFocus() ==& m_Ctestedit && (m_Ctestedit.GetWindowTextLength()) ) 
	{
		m_Ctestedit.GetWindowText(m_text);

		if(m_text=="a")
		{

		        EndDialog(IDOK);

		        return <code>FALSE</code>;  //still works if changed to TRUE. ???
		}
		else
		{
			m_Ctestedit.SetFocus();
		}
	}

	else
	{ 
		return TRUE;
	}

	return CDialog::PreTranslateMessage(pMsg);
}

Why does it do that? According to MSDN:

Return Value
Nonzero if the message was translated and should not be dispatched; zero if the message was not translated and should be dispatched.

Thanks,
ns

Re: PreTranslateMessage return value

dazinith19-Sep-02 4:34

dazinith

19-Sep-02 4:34

the EndDialog(IDOK) is throwing me off.. wouldn't the dialog your in? also you should trace to make sure that its working the way you think it is.

still a newb.. cut me some slack :P
-dz

file permissions check and cleanup

dazinith19-Sep-02 4:14

dazinith

19-Sep-02 4:14

what is the best way to check to make sure a person does not have read only access to a folder?

also this folder may get alot of files in it over a period of time, is there a way to make sure i dont go over the limit of files in a folder? or to check if they have more than 100 files and if so delete files older than a month or so?

just looking for directions, dont need exact code.. thanks for the help! Smile | :)

-dz

Re: file permissions check and cleanup

TyMatthews19-Sep-02 5:11

Re: file permissions check and cleanup

19-Sep-02 5:11

Every directory supports a nul file name. I think this is leftovers from the DOS days, and its strong imitation of *nix. So you can attempt to open a file for write access to Drive:\Directory\nul and see if that works. If it does, your user has the "write" right to the directory. No file will ever be created, because nul is a big black hole.

As for checking for old files, if you're using MFC you can use the CFileFind class to iterate through all of the current files in any given directory. There is a function of CFileFind called GetLastWriteTime() that will tell you the last time it was modified. Take the CTime that function gives you, a CTime::GetCurrentTime() and combine it with a CTimeSpan to compare them. It's not very intuitive, so here's some sample code Smile | :)

<code>

const int cNumDays = 30;
CFileFind fFinder;
CTime tCurrent = CTime::GetCurrentTime();
CTime tFile;
CTime tCompare;
 
BOOL bWorking = fFinder.FindFile( "c:\\mydirectory\\*.*" );
 
while( bWorking )
{
    bWorking = fFinder.FindNextFile();
    if( !fFinder.IsDirectory() && !fFinder.IsDots() )
    {
        fFinder.GetLastWriteTime( tFile );
        tCompare = tFile + CTimeSpan( cNumDays, 0, 0, 0 );
			
        if( tCompare <= tCurrent )
	{
             // Delete the file, move it, or as you please
             TRACE( "%s\n", fFinder.GetFilePath() );
        }
    }
}

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

dazinith19-Sep-02 5:46

dazinith

19-Sep-02 5:46

thanks for the help!

still a newb.. cut me some slack :P
-dz

Re: file permissions check and cleanup

TyMatthews19-Sep-02 5:50