C / C++ / MFC

changing the menu bar due to a drop-down list selection

18-Dec-03 19:34

What are you trying to do?

1) If you just want to see what the image looks like before opening and you are using one of the Windows operating systems that support thumbnails, then
you should already have preview built in.

2) If you wish to support preview on a system that does not support thumnails in the open file dialog, then you will need to subclass the open file dialog. This is covered in the MFC libraray and I believe there may be some articles at codeproject that may cover this subject.

3) If you already have a dialog that you designed, then what problems are you having: (1) is it not drawing, (2) is it not draw in the correct location.

INTP

Hin Jang18-Dec-03 18:32

Hin Jang

18-Dec-03 18:32

for my MDI app, i have a toolbar with a drop down list that is properly initialised and created. i can capture/detect when the user selects a given item from the list.

desired functionality: whenever the user selects an item from the drop-down list, i want to change the contents of the main menubar. i read the online docs for Microsoft Visual C++ .NET regarding the CMDIFrameWnd::MDISetMenu method. at first glance this is what i want but the article suggests that we should not "call this member function if you use the framework to manage your MDI child windows".

any helpful suggestion would be appreciated. thanks.

Re: changing the menu bar due to a drop-down list selection

John R. Shaw18-Dec-03 19:13

18-Dec-03 19:13

I do not use .NET, but one source that might give you a clue is the book "The MFC Answer Book" (look for MFC FAQ on the internet). When using Visual C++ 6.0, you normaly create a resource for based on the view (but you can change the resource used at any time). The most effective way would probaly be to add and remove menue items directly via code (this is much harder to code and maintain).

INTP

WM_CLOSE Priority

Anonymous18-Dec-03 18:24

Anonymous

18-Dec-03 18:24

I wanted to know how an mfc application responds to WM_CLOSE. I have one application which is issuing a WM_CLOSE message to another MFC application.But the other doesn't respond to WM_CLOSE instantly. It waits for the current function or method running in primary thread to return and then takes up this message. But if primary thread is not doing anything, only secondary thread is processing, WM_CLOSE is processed instantly. Please confirm that my analysis is correct..

John R. Shaw18-Dec-03 18:58

18-Dec-03 18:58

It is not a matter (I believe) of how MFC responds, but of how Windows responds. You might try putting your thread to sleep momentaraly to give the other application time to process the command.

As for how mfc applications responds: that is up to the person who wrote the application.

INTP

Anonymous18-Dec-03 19:14

Anonymous

18-Dec-03 19:14

Thanks, I guess I didn't write my question clearly. What I want to confirm is whether an application running a message loop responds to WM_CLOSE instantly or after finishing the current processing. I tested with my application, what I found that when I issue a WM_CLOSE message to the second application, this second application responds to WM_CLOSE only after it has finished current processing. i.e. if a Dialog class's OnInitDialog method is getting processed when I issue WM_CLOSE, WM_CLOSE is handled only after OnInitDialog returns.
Is this behavior specific to DoModal or any method which is getting called?

Monty²18-Dec-03 19:42

Monty²

18-Dec-03 19:42

windows programs handle events serially for one window
e.g
if you are already handling an event and another event comes , it will be in the queue and after processing ur current event the next event will be processed from the Queue .
Hope it answers ur query

Live as if your were to die tomorrow. Learn as if you were to live forever.
-Mahatma Gandhi

John R. Shaw18-Dec-03 21:36

de-selecting items in cList Control

18-Dec-03 21:36

Sorry I was buzy elsewere!

Quick Answer: Before any application can close it must first finish what it is doing. That is it will not receive (etc...) any new messages until it is finish with the current message (or sub-task). It is possible to end a task now, but DO NOT DO THAT (CRTL-ALT-DELETE).

Question: "Is this behavior specific to DoModal or any method which is getting called?"
Answer: Yes and No! (1) The quick answer remains the same. The difference is that a modal box is not finished until the user closes the dialog box.

P.S. No application can respond until it has finished current processing.

INTP

azusakt18-Dec-03 17:32

azusakt

18-Dec-03 17:32

Hi, friends.
I'm make a project that contains a cList Control, when I added item to the list, the new added item always be selected. so when I added , and then click delete button, it always delete the new item.
I use GetFirstSelectedItemPosition () to get the selected item index inside delete function.

How can I de-selected the items after adding or editing?

Thanks

Re: de-selecting items in cList Control

John R. Shaw18-Dec-03 17:47

Directory Contents Question

18-Dec-03 17:47

Look at SetItemState().

INTP

Roger Wright18-Dec-03 16:17

18-Dec-03 16:17

I've spent the past two days playing with sample code that is supposed to, given a main directory, allow me to select one or more subdirectories and collect stats on them including the number of files, and the total size of each subdirectory. The technique used starts with

hFind = FindFirstFile(strFind, &dataFind);

where strFind is a wildcard search string on the main directory, and dataFind is a WIN32_FIND_DATA structure. Directories are identified by

if(dataFind.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY)

in a loop that traverses the entire directory. I found that this correctly identified only a few subdirectories, but couldn't figure out why. In a later section, files within a subdirectory are found using the same technique but using

if(dataFind.dwFileAttributes == FILE_ATTRIBUTE_ARCHIVE)

as the search criterion. This, too, failed to find all the files in the subdirectory. After many hours of research and experimenting I deduced that this is a stupid way to do this task, though it was a great way to demonstrate how to use the various controls in a dialog box. The reason, it appears to me, is that the field dwFileAttributes is an OR of one or more of many attributes, and rarely just a single one, so any single value comparison on a multiple-attribute entity will fail.

So my question is, what is a proper method for reliably testing whether a directory entity is a file or a subdirectory?

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

Rob Manderson18-Dec-03 16:55

Rob Manderson

18-Dec-03 16:55

You do it like this

if (dataFind.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)

and

if (dataFind.dwFileAttributes & FILE_ATTRIBUTE_ARCHIVE)

in other words, and out the bit you're interested in. I wouldn't rely on the archive bit though, it'll miss lots of files. Use FILE_ATTRIBUTE_NORMAL instead.

Rob Manderson

http://www.mindprobes.net

Paul Watson wrote:What sense would you most dislike loosing?

Ian Darling replied.

Telepathy

Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003

Roger Wright18-Dec-03 20:38

18-Dec-03 20:38

Thanks, Rob... That was sorta where my small mind was headed - performing an AND operation to isolate the particular bit of interest, then testing for equality. It's unfortunate that the authors of this book didn't take the opportunity in this example to demonstrate this option. I think it would have been very instructive to a lot of people trying to learn the language. At the very least, it would have alerted students to the fact that the Win32 and MFC APIs are full of such flag fields, and that a programmer must learn appropriate methods for dealing with them. To their credit, though, I must admit that the intent was to demonstrate how to populate the fields of several control objects, which the chapter did quite well. Maybe I'm too much a perfectionist, but I think that sample code in a textbook should be perfect. Unfortunately it is often a far cry from merely good, let alone perfect.

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

Rob Manderson18-Dec-03 22:22

Rob Manderson

18-Dec-03 22:22

You're welcome Smile | :)

Which book are you learning from?

I'm learning C# right now - with Tom Archers Inside C# 2nd edition as my guide. Great textbook so far but I didn't fully understand his description of assemblies, manifests et al in chapter 1. No matter - I'll go back and reread that part again and again, on the assumption that I've missed something, when I need to know it.

No textbook will be perfect - the author will always make some assumption somewhere that something is so obvious that it needs no explanation. In this case I suspect it was that the constants are named FILE_ATTRIBUTE_??? and the author assumed no one would imagine they were discrete constants.

Rob Manderson

http://www.mindprobes.net

Paul Watson wrote:What sense would you most dislike loosing?

Ian Darling replied.

Telepathy

Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003

Roger Wright19-Dec-03 5:23

19-Dec-03 5:23

Rob Manderson wrote:
Which book are you learning from?

Practical Visual C++ 6, by Bates and Tompkins. It's quite good, actually, and as I mentioned, the intent of the program was to illustrate how to fill up various controls, not to enumerate all the files in a directory. I was just thinking ahead a bit. I'm looking forward to reading Tom's book, but there's no rush as no one around here is using C# yet.

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

John R. Shaw18-Dec-03 17:09

18-Dec-03 17:09

Your conclusion is correct, that dwFileAttributes is a set of bit flags.
This is just of the top of my head.

if( !(dataFind.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
{
    // should be a file
}
else
{
   // should be a file}
}

// TESING MULTIPLE ATTRIBUTES
if( dataFind.dwFileAttributes & (FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_NORMAL) )
{
    // this is a normal or archived file
}

INTP

Roger Wright18-Dec-03 20:45

18-Dec-03 20:45

John R. Shaw wrote:
if( !(dataFind.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
{ // should be a file}
else
{ // should be a file}}

Off the top of your head that's quite reasonable - I understand the intent, despite the typo. Rob came up with much the same conclusion (see above). Thank you for your guidance - C++ is fairly new to me, but I'm finding that it's not really as bad as I'd expected. Big Grin | :-D

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

John R. Shaw18-Dec-03 22:12

18-Dec-03 22:12

You are welcome! I was wondering where that curley brace went to, but it is not a typo since it ended up as part of the comment. By the way, C++ is derived from C and what you are seeing is actualy C code (since no classes are invalved).

Have a great night, day, or whaterver!

INTP

Rob Manderson18-Dec-03 22:55

Rob Manderson

18-Dec-03 22:55

y'know I had to stare at the code John posted quite a long time before I saw the typo Smile | :)

Here I was scratching my head and wondering what Roger was on (and if I could have some Smile | :)

) before finally seeing that errant brace.

Rob Manderson

http://www.mindprobes.net

Paul Watson wrote:What sense would you most dislike loosing?

Ian Darling replied.

Telepathy

Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003

Roger Wright19-Dec-03 5:16

GDI Objects LEAK due to manifest file codes?

19-Dec-03 5:16

It was a little more than the curly brace:

if( !(dataFind.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
{ // should be a ~~file~~ directory}
else
{ // should be a file}}

Smile | :)

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

Yu Zhiquan18-Dec-03 16:03

Yu Zhiquan

18-Dec-03 16:03

I run an application(e.g. Test.exe) in Debug or Release mode,
without manifest file, the applcation will good.

But, I met a GDI Objects leak issue,
when I run the application with
a manifest file(e.g. Test.exe.manifest).

the follow is in the manifest file:

<br />
     <dependency><br />
          <dependentAssembly><br />
               <assemblyIdentity<br />
                    type="win32"<br />
                    name="Microsoft.Windows.Common-Controls"<br />
                    version="6.0.0.0"<br />
                    publicKeyToken="6595b64144ccf1df"<br />
                    language="*"<br />
                    processorArchitecture="x86"<br />
               /><br />
          </dependentAssembly><br />
     </dependency><br />

The leak will not issue, when I remove the codes from the manifest file,
or, the leak will not issue , I rename the application name(e.g. ATest.exe).

The GDI Objects leak due to manifest file?
Who can give me some comments, thanks in advance!

Re: GDI Objects LEAK due to manifest file codes?

John R. Shaw18-Dec-03 16:50