|
Hi!
If I use static as you said, I got the following linker errors:
Error 80 error LNK2001: unresolved external symbol "protected: static int CGameState::musicVolume" (?musicVolume@CGameState@@1HA) D:\Goldminer\GameOptionsMenuState.obj
|
|
|
|
|
You have to later initialize it somewhere, for instance, like
int CGameState::musicVolume = 0;
...byte till it megahertz...
|
|
|
|
|
See what Niklas posted.
...byte till it megahertz...
|
|
|
|
|
Read bleedingfingers' answer. 
|
|
|
|
|
hey hey hey don't Moak me I had asked the OP a question and before I could reply after my lunch, Niklas had answered it. I find not following up on a question with a reply to be rude and there was no point in re replying.
...byte till it megahertz...
|
|
|
|
|
I've answered your question.
|
|
|
|
|
I'm using dsoframer in my app, does this interfere with WM_COPYDATA? The error text is:
"An outgoing call cannot be made since the application is dispatching an input-synchronous call."
[Edit]
I found a kb article[^] that seems to explain why this occurs:
------------------------------------------------------
See the beginning of chapter 13 in the OLE 2 Programmer's Reference Volume 1 for the categories of OLE calls. An understanding of these categories is required for this article.
The majority of OLE calls are synchronous calls. A synchronous call to a different process yields to that process and waits for a reply from that process. In addition, OLE has input-synchronized calls that relate to the inplace-activation interfaces. Input-synchronized calls are implemented using an inter-process/inter-thread SendMessage.
16-bit Windows doesn't allow a task to yield while in an inter- process/inter-thread SendMessage because a system deadlock could occur. The deadlock occurs because a message for the sender could be present at the top of the shared system queue, and this prevents other tasks, including the recipient of the SendMessage, from retrieving their messages from the system queue until the sender does. The sender cannot retrieve its message because it is waiting for the inter-process/inter-thread SendMessage to return.
In 32-bit Windows, each process has its own system queue and this architecture normally prevents deadlock problem from occurring. However, when one process is inplace active in another process's window, the system queues of the two processes are synchronized as in 16-bit windows, so the deadlock could occur. To prevent this, OLE stops synchronous OLE calls from being made while the caller is the recipient of an input-synchronized call.
OLE determines if the caller of the synchronous call is a recipient of an input-synchronized call by using the InSendMessage() API. This broad check prevents a synchronous call from being made if the caller is currently a recipient of any inter-process/inter-thread SendMessage.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
modified on Tuesday, September 28, 2010 3:47 AM
|
|
|
|
|
I am adding a feature into my application programs which will be using shared (mapped) memory to communicate between two programs.
I made a demo1 program to test and verify the class implementations. It works well.
So I started to do one of the real application program. To prevent two instances in the system, I used CreateMutex for that.
HANDLE hMutex = CreateMutex(NULL, FALSE, MUTEX_NAME);
if(hMutex) {
if(ERROR_ALREADY_EXISTS == GetLastError()) {
return FALSE;
}
}
Later during the initialization of the program, I found CreateFileMapping failed.
m_hFile = CreateFileMapping(
INVALID_HANDLE_VALUE,
NULL,
PAGE_READWRITE,
0,
m_dwBufSize,
m_sMappingName);
When I removed the CreateMutex line, CreateFileMapping returned a valid handle.
Are they using the same system resource?
Maxwell Chen
|
|
|
|
|
What did CreateFileMapping fail with, call GetLastError and see what it says, maybe it helps to decypher the problem.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: What did CreateFileMapping fail with, call GetLastError and see what it says, maybe it helps to decypher the problem.
When CreateMutex is used in the code in CDemoApp::InitInstance, CreateFileMapping returns a NULL value. GetLastError() returns 0x00000006 (invalid handle).
When CreateMutex is NOT used in the code, CreateFileMapping returns a valid handle to the mapped memory.
Maxwell Chen
|
|
|
|
|
This is strange, i find it very unlikely that CreateMutex would affect CreateFileMapping. I have worked with a project that used quite a few mutexes for synchronization and also used file mappings to access data (not using the paging file though) and there was no trouble with working altogether.
Are you completely sure that the only difference between the two "versions" is the creation of the mutex?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: Are you completely sure that the only difference between the two "versions" is the creation of the mutex?
Yes! I just used // to comment out the lines. 
Maxwell Chen
|
|
|
|
|
Is it possible that you specified the same name for the mutex and the file mapping object?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: Is it possible that you specified the same name for the mutex and the file mapping object?
I had also considered this possibility, too. So I have tried using different names for the mutex and the mapped memory individually. Not working...
Maxwell Chen
|
|
|
|
|
Try creating an unnamed mutex and see if that changes anything. I know you will need a named one but this is just for testing.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: Try creating an unnamed mutex and see if that changes anything. I know you will need a named one but this is just for testing.
I just tried this, and it works.
And I also tried again the mutex with name A and the mapped memory with name B. It also works now.
I think my system was getting crazy. 
But thank you anyway.
Maxwell Chen
|
|
|
|
|
Also, the documentation[^] of CreateFileMapping states this:
"If lpName matches the name of an existing event, semaphore, mutex, waitable timer, or job object, the function fails, and the GetLastError function returns ERROR_INVALID_HANDLE. This occurs because these objects share the same namespace.", this should be a name-collision issue. Just to test this, try explicitly specifying "appleappleapple" for your mutex and "pearpearpear" for your mapping object, i mean, directly where you call the creation methods, not using a macro or any member variable.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I've given this a 5, not 'cause of the original answer but because of the way code-o-mat followed the problem through to it's solution. Class act!
Cheers,
Ash
|
|
|
|
|
Thanks. 
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
The APIs are not related in anyway.
Just to be sure I tried to run the piece of code and it works perfectly.
So the only thing relating both the APIs in the code above is the name.
By giving the same name for both the mutex and the mapping, I'm able to reproduce the error with GetLastError returning the error code 6.
|
|
|
|
|
Maxwell Chen wrote: if(hMutex) {
shouldn't that be if(!hMutex) { ?
|
|
|
|
|
Luc Pattyn wrote: shouldn't that be if(!hMutex) { ?
Nope, my original code snippet as the below is correct.
HANDLE hMutex = CreateMutex(NULL, FALSE, MUTEX_NAME);
if(hMutex) {
if(ERROR_ALREADY_EXISTS == GetLastError()) {
return FALSE;
}
}
Maxwell Chen
|
|
|
|
|
My mistake. This is one of the exceptional cases where calling GetLastError makes sense even when the function succeeded.
|
|
|
|
|
|
Maxwell Chen
|
|
|
|
|
What happens after you return FALSE ?
Otherwise, I think you just leaked a system object handle.
Your program should technically close the mutex handle if you are not going to use it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
