|
Yes it is!
I have a number of console applications for which I used this. In Visual Studio, you add a file to the sources folder with a name like "AppName.rc". studio will ask something like "No such file exists, add anyway?" to which you reply confirmative. Next, you must open the file (again from the sources folder) Studio will again ask: "This file does not yet exist; do you wat to create a new file?" Again, you answer "yes". Then, there will be an empty rc file and a "ResourceView" tab will be added to your project, between the "ClassView" and the "FileView" tabs. When you open the resource, it will have no resources yet, so you add an icon. You must make sure to create this icon in both 32*32 bit version as well as in 16*16 bit version. When you then recompile your console application, there will be no changes to the application itself, nor to the console window in which it runs. However, if you browse to your program using explorer, it will show you your icon next to the filename, rather than the default exe icon.
In the same way, you can add version information to your program. You can view this version information by selecting "Properties" in explorer. The issue here is that both the version information as well as the icon are kept in the exe's header information, which is not loaded at runtime, but which is used by explorer to show information about the exe file. This is also the reason why you cannot use the version information from your resource at runtime in your application; it's simply never loaded! 
Regards,
William
|
|
|
|
|
Engberts wrote: hich is not loaded at runtime, but which is used by explorer to show information about the exe file. This is also the reason why you cannot use the version information from your resource at runtime in your application; it's simply never loaded!
Do you see the Icon you create/attached with the console application in taskbar or caption of application window when you run that application!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Sir
I want 2 know that weather we can call SAME function
from mutiple threads if yes what issues we must consider?
will same block of code will b code will be copied in
diff threads? iam waiting for ur reply sir.
bye
|
|
|
|
|
In C/C++, local variables are stack based so any variables declared inside of the routine are ok unless they are static.
The problem boils down to the routine trying to access the same piece of data in two threads. If this is what is happening, then you will have problems unless the data is read only and will never be written to.
For example:
int Sum (int a, int b)
{
int c = a + b;
return c;
}
This routine can be called from many threads at the same time.
For example:
int value = 0;
void ChangeValue (int a)
{
value += a;
}
This routine will not work well unless only one thread calls the routine at a time.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote: This routine will not work well unless only one thread calls the routine at a time.
But Windows Programming provides us facility of Syncronization Objects
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
That is true, but I was trying answer his question without giving him so much information that he wouldn't understand the answer.
If he wishes to access data between more than one thread, he can ask that in a follow up question.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote: he can ask that in a follow up question.
As Usual, You are Right, Sir!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
It is possible to call the same function from two different threads. Normaly this
holds no problem.
There are indeed issues you must consider when doing is.
Normal vars are placed in the stack and since each thread has his own stack.
But static vars are not located on the stack , so both threads could take action
on those objects.
Another issue is that some objects aren't thread safe, so using such vars in a
function causes the function to be not thread safe
codito ergo sum
|
|
|
|
|
In short, the answer is maybe. In depends on the function. There are many issues such as:
- Does the function access gloal data.
- Does it call APIs which are not thread safe.
- Does it use APIs that have thread affinity.
This is not a simple question - Multithreading is complex and subtle!
Steve
|
|
|
|
|
E.Satish wrote: I want 2 know that weather we can call SAME functionfrom mutiple threads if yes what issues we must consider?
Yeah you can, but your application chances for crashes are very high.if still want to use same function in different thread you can use Syncronization objects like critical section , semaphore etc
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Need your thoughts and/or opinion. Question at the bottom.
When user closes the modeless dialog box you can trap the WM_CLOSE message to insure proper cleanup.
According to Help
CWnd::OnClose
The framework calls this member function as a signal that the CWnd or an application is to terminate. The default implementation calls DestroyWindow.
I found two ways to approach the user who closes the modeless dialog box by clicking the x on the upper right hand corner of the window
Looking at the first example below.
I found out that if you don't call DestroyWindow() from your OnClose() and you don't want multiple instances of your modeless opened you will need to set the pointer to NULL here (otherwise your pointer value can't be used as a flag to prohibit other instances of your modeless dialog from being opened). PostNcDestroy apparently isn't run until the parent is destroyed. Once the parent/owner is closed then a PostNcDestroy is run for each modeless that opened - one right after another.
void CDialogDerived::OnClose()
{
CDialog::OnClose();
m_pParent->m_pModelessDialog = NULL;
}
void CDialogDerived::PostNcDestroy()
{
CDialog::PostNcDestroy();
m_pParent->m_pModelessDialog = NULL; //in case destroy window is called from your code and OnClose is never run
delete this;
}
Example 2. This seems like a cleaner approach as the Dialog is destroyed immediately and thus your pointer is set to
NULL immediately
void CDialogDerived::OnClose()
{
CDialog::OnClose();
DestroyWindow();
}
void CDialogDerived::PostNcDestroy()
{
CDialog::PostNcDestroy();
m_pParent->m_pModelessDialog = NULL;
delete this;
}
Any thoughts pro and con to either of these approaches? I'm curious why the PostNcDestroy is not run promptly
with the OnClose call on the first example.
Thanks!
|
|
|
|
|
Why make this so complex? You can easily check if the window still exists from the parent with a check like this:
if ( NULL == m_pModelessDialog->GetSafeHwnd() )
{
if ( NULL != m_pModelessDialog )
delete m_pModelessDialog;
}And just forget about all the messy cleanup in the dialog itself.
|
|
|
|
|
mx483 wrote: you don't want multiple instances of your modeless opened you will need to set the pointer to NULL
This is a curious way to avoid multiple instance. Is this a child dialog of your app or, the app itself ? Why don't you check if the dialog already exists before starting a new one ? If you destroy your dialog, a simple check on SafeWindow will tell you that your pointer is not used anymore. YOu could even fire up a message to your parent to reset the pointer if you really want to.
As for the examples, I think this is sufficient, no need to intercept another message.
void CDialogDerived::PostNcDestroy()
{
m_pParent->m_pModelessDialog = NULL;
delete this;
CDialog::PostNcDestroy();
}
~RaGE();
[edit] I wrote teh same as Shog because I forgot to post my message right away... Nevermind, and great to see we are on the same wave length [/edit]
-- modified at 10:01 Wednesday 15th February, 2006
|
|
|
|
|
Thanks for the responses. I do check for the NULL pointer before opening an instance. I didn't include that code because it isn't relevant. What is relevant though is the correct way to handle the WM_CLOSE message.
And my curiosity was I didn't understand why the WM_CLOSE message didn't run the Destroy Window right away - only after parent was closed.
|
|
|
|
|
I think you both missed my message. You have to intercept the WM_CLOSE message. If you don't you are
1. Not Destroying your window till your parent is closed.
2. Therefore you PostNcDestroy is not run until your parent is closed
3. Therefore, how does your app know that the pointer is no longer valid.
You can run GetSafeWnd all day long - it still points to valid memory...cause you never bothered to delete the CWnd object...until the parent is closed.
So back to my original question please.
|
|
|
|
|
mx483 wrote: 1. Not Destroying your window till your parent is closed.
Sorry, i guess i missed that. Sounds like you're missing a few things in your implementation, so i'll go over the steps to doing a proper modeless dialog in MFC:
- Create with
Create(), followed by ShowWindow(), not DoModal() (i'm sure you're already doing this ) - Never call
EndModalLoop() (or EndDialog()) - Never let the default behavior run when it will end up doing what you avoided in #1 or #2
- No default behavior for
OnOK() or OnCancel() (WM_COMMAND handlers for IDOK and IDCANCEL) - Be aware that the default behavior for
WM_CLOSE just posts a WM_COMMAND for IDCANCEL (so it'll end up calling IDCANCEL) - Be aware that various keys can trigger
OnCancel()/OnOK() directly (ENTER, ESC) or indirectly (Alt+F4 -> WM_CLOSE -> OnCancel()). So you really do need to override these commands, even if you don't have an explicit IDOK or IDCANCEL button on your dialog.
So the likely explanation for the behavior you describe is that you're letting the baseclass call EndModalLoop(), which just hides the window. Then when the parent is destroyed, its (now hidden) children are also destroyed, causing the wave of delayed destruction you noticed.
So your fix is simple: override OnOK() and OnCancel() and cause them to call DestroyWindow() rather than the baseclass implementation. Optionally, do the same for OnClose() (isn't necessary, but will make it more obvious what you're doing).
And i'd still encourage you to avoid messing with data in the parent window class (and especially doing delete this). Nothing absolutely wrong with it, but it's messy - let the owner handle that stuff.
|
|
|
|
|
Bingo!
Hey thanks, Here was where I wasn't understanding:
Be aware that the default behavior for WM_CLOSE just posts a WM_COMMAND for IDCANCEL (so it'll end up calling IDCANCEL).
Thanks for taking the time to write again and explaining why the window wasn't really destroyed when the WM_CLOSE was called.
I'll also strongly consider your other suggestions.
|
|
|
|
|
I believe that fact that the Dialog was not getting destroyed was because the WM_CLOSE message is being overridden by CDialog and calling and IDCANCEL. That would make sense. Before I posted the question though I attempted to follow the WM_CLOSE message to see where it was going - hence the reference to CWnd::Close from Help at the top of the question. When I put a break point at the OnClose function -user clicks the x at upper right hand part of dialog(Created through ClassWizard capturing the WM_CLOSE message) I am lead to this.
_AFXWIN_INLINE void CWnd::OnClose()
{ Default(); }
Continuing I am lead to
LRESULT CWnd::DefWindowProc(UINT nMsg, WPARAM wParam, LPARAM lParam)
Message being passed is 16 and IDCANCEL is defined as 2
Now I'm scratching my head. Wouldn't I see an IDCANCEL call or something like that. CWnd is supposed to destroy the window
Thanks
|
|
|
|
|
(btw - no harm in starting a new thread with offshoot topics like this )
This question takes you into the fun and exciting world of Classic Win32. Well, perhaps i'm being generous with "fun and exciting"... but anyway...
In a nutshell, this is how it works: in basic ol' Win32 (and Win16 for that matter), dialogs are not quite the same as "regular" windows. They aren't created in the same way, they don't get passed messages in the same way, and the default behavior for unprocessed messages isn't the same either. MFC does a lot to hide this from you, but at its core it still behaves in much the same way. Which makes things interesting when you're creating a non-modal by deriving a class from CDialog, because you inherit a lot of defaults that you really don't want.
And one of those behaviors is what happens when you call ::DefWindowProc() with WM_CLOSE as the message. As you've found, dialogs do not call DestroyWindow() - they post WM_COMMAND with WPARAM set to 2 (IDCANCEL). And because the message is posted, you don't get a nice call stack leading back to OnClose() from OnCancel().
Why is this so? Because you don't close dialogs - real modal dialogs - by calling DestroyWindow(). They have their own message loops that need to be cleaned up, and those take care of actually destroying the window, so you call EndModalLoop() in MFC, or EndDialog() in Win32. And that is what the default behavior for OnClose()/OnOk() end up doing... which as you've noticed, is nearly useless for non-modal dialogs.
|
|
|
|
|
Yeah, its starting to make sense. But why when I hovered over the nMsg in the DefWindowProc did the message come back as 16. I know IDCANCEL is 2
#define IDOK 1
#define IDCANCEL 2
#define IDABORT 3
#define IDRETRY 4
#define IDIGNORE 5
#define IDYES 6
#define IDNO 7
#if(WINVER >= 0x0400)
#define IDCLOSE 8
#define IDHELP 9
Still scratching. Oh and by the way thanks for your help.
|
|
|
|
|
Here's a little trick: in the debugger, put a number (or variable) in the watch window, and follow the name with , wm - it'll display the name of the window message that the number maps to. But you're not gonna see IDCANCEL being passed in nMsg anyway - it's passed in the wparam field, while the message is WM_COMMAND.
|
|
|
|
|
Sounds neat, I wish I could get it to work. Both wparam and lparam are zero with nMsg = 16. I using Visual C++ 6.0 so maybe the watch stuff is a new edition.
IDCANCEL, wm gives me an error message in the watch window.
I also looked up the value of WM_COMMAND and it is 273
|
|
|
|
|
mx483 wrote: IDCANCEL, wm gives me an error message in the watch window.
Wrong way about. Try:
16, wm<br /> or
nMsg, wm<br /> Put a breakpoint in OnCancel(), and look up the callstack when it gets hit - you'll see WM_COMMAND being processed then.
|
|
|
|
|
Thanks for being so patient. Yep It works, it was case sensitive. I see where the WM_CLOSE message is being posted. I can keep pressing F11 and trace into the functions where finally the DefWindowProc shows up. Then I can go to the call stack and see all this too. I think I'm back to wondering why (according to you) I should be seeing a WM_COMMAND message instead of a WM_CLOSE message.
Hey thanks you are teaching me a bunch!
|
|
|
|
|
mx483 wrote: I think I'm back to wondering why (according to you) I should be seeing a WM_COMMAND message instead of a WM_CLOSE message.
You'll see both - WM_CLOSE first, then (if you let the default handler handle it) WM_COMMAND.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
