C / C++ / MFC

11-Dec-03 10:26

aroraavinash wrote:
...is using dialog based application still good...so will dialog based application helps in it.

Yes, from what you've shown so far.

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

file manager

thes3cr3t111-Dec-03 6:52

11-Dec-03 6:52

hello,i have tried to write a filemanager in c++,im using the WIN32_FIND_DATA struct,to obtain file information,this seems to work okay apart from one thing,it list's all the files and directorys in my c:\ drive,but for some reason it dosent show "program files" as a directory,does anyboy have any idia what might be causing this?

thank you for your time. Smile | :)

chris

David Crow11-Dec-03 9:01

11-Dec-03 9:01

thes3cr3t1 wrote:
...but for some reason it dosent show "program files" as a directory...

What does it show it as?

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

thes3cr3t111-Dec-03 11:01

11-Dec-03 11:01

it dosent show it as anything,theese are the file artributes i got set: FILE_ATTRIBUTE_HIDDEN
FILE_ATTRIBUTE_COMPRESSED
FILE_ATTRIBUTE_SYSTEM
FILE_ATTRIBUTE_ENCRYPTED

do you know if i am missing anything there?

chris

David Crow12-Dec-03 2:41

12-Dec-03 2:41

thes3cr3t1 wrote:
do you know if i am missing anything there?

With the limited information you've provided, no.

I presume you have something akin to:

WIN32_FIND_DATA fd;
HANDLE hFind;
BOOL bContinue;
 
hFind = FindFirstFile(..., &fd);
if (INVALID_HANDLE_VALUE != hFind)
{
    do
    {
        // output fd.cFileName
        bContinue = FindNextFile(hFind, &fd);
    } while (FALSE != bContinue);
 
    FindClose(hFind);
}

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

thes3cr3t112-Dec-03 5:40

12-Dec-03 5:40

yes very much like that here is what it looks like,

{
string filebuff;
WIN32_FIND_DATA FindFileData;
HANDLE hFind;

hFind=FindFirstFile(Directory.c_str(), &FindFileData);

do{

if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY )
filebuff += "dir";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_HIDDEN )
filebuff += "Hidden";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_COMPRESSED )
filebuff += "Compressed";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_SYSTEM )
filebuff += "System";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_ENCRYPTED )
filebuff += "Encrypted";
else

filebuff +=("%*s", 30, FindFileData.cFileName);
filebuff += "\n" ;

}while ( FindNextFile(hFind, &FindFileData) );
//do something//
return 0;
}

i hope this gives a better understanding of what i might be doing wrong here,
my only thought was that i was missing out a file artribute that i didnt know about,there is no reason why "Program Files" isnt shown as a directory after all it is a directory isnt it,even if program files was hidden,it should stil show up as a directory too shouldnt it?
this code is what i took from my source,as im a n00b if ya spot any mistakes please lemmi know,thanks again 4 ya time.

chris

David Crow12-Dec-03 5:44

12-Dec-03 5:44

Change your code to:

if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) == FILE_ATTRIBUTE_HIDDEN)
    filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_COMPRESSED) == FILE_ATTRIBUTE_COMPRESSED)
    filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) == FILE_ATTRIBUTE_SYSTEM)
    filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_ENCRYPTED) == FILE_ATTRIBUTE_ENCRYPTED )
    filebuff += "";
else
    filebuff +=("%*s", 30, FindFileData.cFileName); // not sure what this does!

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

thes3cr3t112-Dec-03 6:00

How to create buttons on the video

12-Dec-03 6:00

wow thank you for such a speedy response,i tried what u said,but it didnt give the desired output,however with a little bit of tinkerin it seems to work nicly now,for some reson it now shows program files as a dir,i wold like to understand what was going wrong.this is the working code i now have

if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN)
filebuff += "<hidden>";
if( FindFileData.dwFileAttributes &FILE_ATTRIBUTE_COMPRESSED) filebuff += "<compressed>";
if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) filebuff += "<system>";
if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_ENCRYPTED) filebuff += "<encrypted>";

it seemed to be the " == FILE_ATTRIBUTE_SYSTEM )" line that was making it go wrong,however if you hadnt of shown me the baove code i would have never noticed,now the next step for me is to learn from my mistake.

thanks again for such a fast response!;)

Chinnaa Ganesh Kumar11-Dec-03 6:40

Chinnaa Ganesh Kumar

11-Dec-03 6:40

Hi all,

In my SDI applocation, I play the video file with the help DirectX.

Now I have to draw buttons over the running video image.

When trying for the same it's getting appear behind the video.

How to create buttons on the video

Thanks in Advance,

Chinna

Parent and child dialog, GetWindowRect()

J.B.11-Dec-03 5:29

11-Dec-03 5:29

Guys,
I am tring to dynamically move the positions of the child dialogs whenever the parent dialog is resized. But I started getting confused with the values passed to GetWindowPos for the dialogs.

Bsically, I have a parent dialog class, CMyDlg and the dialog contains a Group Box (IDC_SUBFRAME). the child dialog (CMainDlg) should fall into the centre of IDC_SUBFRAME. In CMyDlg::OnInitDialog(), I embedded the child dialog with following code:

CRect frameRect, childRect;

     (GetDlgItem(IDC_SUBFRAME))->GetWindowRect(&frameRect);

pMainDlg = new CMainDlg();
pMainDlg->Create(IDD_MAIN_DIALOG, this);
pMainDlg->GetWindowRect(&childRect);
pMainDlg->SetWindowPos(this, frameRect.left + ((frameRect.Width() - childRect.Width())/2),
    frameRect.top + ((frameRect.Height() - childRect.Width()) / 2),
    childRect.Width(), childRect.Height(), SWP_NOZORDER);
pMainDlg->ShowWindow(SW_SHOW);

I found the child dialog was sitting in the Group Box frame, but not quite at the centre. Through the debug, I found the values of the CRects are quite strange:

frameRect {top=150 bottom=472 left=13 right=600}
childRect {top=30 bottom=132 left=4 right=517}

How come the frame's top and left are larger than the child dialog's, when the child dialog actually sits IN the frame when initialised. To better illustrate, the big box below is the frameRect and the small box within is the childRect.

---------------------
|                   |
|  ---------------  |
|  |             |  |
|  ---------------  |
---------------------

From my understanding, GetWindowRect returns the coordinations in relation to the display (monitor). If so, wouldn't the frame's top and left values be smaller than the child dialog's?

Could anyone help me on this?
Thanks

georgiek5011-Dec-03 5:50

11-Dec-03 5:50

I sympathize with you one this because I was doing the same thing last week only with more "layers" of windows and it got real confusing. Key points to remember:

1) Use GetClientRect to get the original size of the parent window
2) After you have resized with MoveWindow calculate the difference in width and height and store it somewhere for later use
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.
4) Convert the rect.left and rect.top coordinates you just got with ScreenToClient to get client coordinates relative to the parent window
5) Final step, use SetWindowPos for the child windows with the difference in size (calculated earlier). eg.

// Apply the new height
lNewHeight = (rcTab.bottom - rcTab.top); // The original height calculate from GetWindowRect

lNewHeight += lDifference; // Add the difference calculated from the change in dimensions of the parent window. This will work regardless if the window became smaller or larger.

I hope I didn't confuse you more Smile | :)

J.B.11-Dec-03 15:26

11-Dec-03 15:26

georgiek50 wrote:
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.

Thanks you for the reply georgiek50,
however, GetWindowRect for me does not taken two parameter, with the compiler error,

'CWnd::GetWindowRect' : function does not take 2 parameters

I found the variant of GetWindowRect in Platform SDK, but how do I use it. Also, from the descriptions, I cannot see how the additional parameter affects the coordinate values copied.

Thanks again

georgiek5011-Dec-03 16:17

11-Dec-03 16:17

The "variant" I guess can only be used in Win32. If you mean the additional parameter being HWND it affects the values because it is getting the values relative to the values of of the window "below" it, just like GetWindowRect of the main dialog gets the values relative to the window (in this case the monitor/screen) "below" it. I'm sorry I can't explain this better than words, a drawing would be appropriate.

J.B.11-Dec-03 16:39

11-Dec-03 16:39

It's perfectly clear, thanks alot georgiek50

My development is under MFC, if considering my situation, GetWindowRect always get the values relative to the monitor/screen, correct? And as illustrated in my original post, how come the childRect left and top values are smaller than the frameRect's, when the display of the app actually has the child dialog sitting INSIDE the subframe. It does not seem to make sense.

georgiek5011-Dec-03 18:33

11-Dec-03 18:33

It is smaller because: your main window rect.top = 150, correct, and your child is 30 correct? So relative to the top of your MONITOR, the main window is at 150 and the child is at 180 (150+30)...but relative to your main window it is only 30...do you see now? GetWindowRect apparently in MFC needs only one paramater because it uses the owner of the child window for reference/starting point coordinates.

J.B.12-Dec-03 16:39

12-Dec-03 16:39

Hi georgiek50,
thanks for the reply. My drawing turns out to be a little misleading. frameRect and childRect are values for the SUBFRAME (a Group Box) and child dialog respectively, so neither of them is the main dialog (main window). The SUBFRAME placed inside the main dialog is used a reference box which the child dialo later created needs sit at the centre of it. In this case, to guess what you mean, the 150 now will be the "top" value of the SUBFRAME relative to the main window, correct? And the 30 will be the "top" value of the child dialog relative to the SUBFRAME?

If my guess is right, to let the child dialog to sit at the centre of the SUBFRAME, shouldn't it just be

pMainDlg->SetWindowPos(this, frameRect.left + ((frameRect.Width() - childRect.Width())/2),
    frameRect.top + ((frameRect.Height() - childRect.Height()) / 2),
    childRect.Width(), childRect.Height(), SWP_NOZORDER);

in the main dialog's OnInitDialog(). pMainDlg is the pointer to the child dialog.

Sorry for the trouble, appreciate any further help.

EDIT: further obersve the CRect value of the main dialog from

GetClientRect(&mainRect)

mainRect {top=0 bottom=465 left=0 right=606}

J.B.12-Dec-03 17:18

Proper way to process messages to modeless dialogs

12-Dec-03 17:18

Ok, after another long look, I think the way I have done it is correct. As to why the child dialog always appear not at the centre, but slightly towards the bottom part of the SUBFRAME (as illustrated), I do not know. Has it got something to do with the fact the child dialog's Border property is set to None and Control to True? Or the nature of the Group Box which always leaves a siginifcant large "top" margin?

georgiek5011-Dec-03 5:22