|
Nope. That is correct you can't get any better using RegisterWindowMessage for private (i.e. inside same process) messages.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The messages are not within the same executable, and therefore I don't consider it as 'private'.
The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: The messages are not within the same executable, and therefore I don't consider it as 'private'.
The DLL is mapped in the executable address space, isn't it?
Rajesh R Subramanian wrote: The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
Using Spy++ (or another hook mechanism) you may know about.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: The DLL is mapped in the executable address space, isn't it?
So, are you telling that using a hardwired message ID is better than having the OS register a dynamic ID for us? Also, the DLL could be mapped into my address space, but it's still a different entity. If I keep on assigning WM_USER + based messages for all my handlers, that would certainly be
1. Poor programming technique
2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
CPallini wrote: Using Spy++ (or another hook mechanism) you may know about.
Like I said, if you would want to hack, there's no limits to it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: 1. Poor programming technique
Nope. Unless Microsoft itself is encouraging poor programming techniques.
Rajesh R Subramanian wrote: 2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
Rajesh R Subramanian wrote: 3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
I already acknowledged this very point.
Rajesh R Subramanian wrote: 4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
That's true, as correctly pointed out by Dr.Newcomer, only if you're distributing your DLLs and them are being used by clients that uses, at the same time, other 'sending messages DLLs' (I find rather hard to fit this in the OP scenario).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
No, it was a different point I was trying to make. Say if you're copy pasting a bunch of messages, you could accidentally define two different messages with the same ID while editing those.
And coming to the... Wait, I think this is stretching far too much for very little. Now we need to decide who of us gets the 'nitpick of the week' award.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
|
The correct way is to use RegisterWindowMessage(). That would ensure the uniqueness of messages. Read the details here: http://www.flounder.com/messages.htm
yccheok wrote: What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID? I wish not to respond, as I am only interested message from DLLs within my own process.
If you use RegisterWindowMessage(), then the 'other executable' won't know what would be the ID of this unique message.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
That would ensure uniqueness, for well behaving app, not for Spy++ & go hacks... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Oh well, if you decide to hack, you could do it anyway. But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
The point about WM_USER is right (I've fixed the OP), anyway, there's nothing wrong using WM_APP in the OP scenario (Dr.Newcomer warns about 'clients using DLLs with conflicting messages...') and the mechanism is the same of the WM_USER one.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: there's nothing wrong using WM_APP in the OP scenario
Well, yes and no. I'm not saying it's WRONG, but there's a better way. Dr. Newcomer, I and Ray Ozzie discussed this over a coffee. Just Kidding. 
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: Oh well, if you decide to hack
Oh, no. Unfortunately I'm really poor as hacker... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
[Jeremy Clarkson Voice] Some say that it's impossible for the stig Carlo to hack his way out of wet socks. [/Jeremy Clarkson Voice]
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
None of these approaches are inherently more 'secure' than any other.
WM_APP is a little better than WM_USER, because a number of the builtin Windows controls use messages in the WM_USER range.
Both WM_USER and WM_APP messages are easier to detect using Windows Spy++, since they have fixed values.
RegisterWindowsMessage is slightly more difficult to detect, since the value can change each time the message is created (the first time it is called with a given string, a new value is created; further calls with that string get the same value). A determined hack could look for calls to RegisterWindowsMessage and duplicate your string.
One option would be to use a randomly-generated string (such as a GUID) that your application and your DLL's could agree on. A simpler alternative would be to generate a random number between WM_APP and 0xBFFF and pass that to your DLL's via a conventional function call at initialization time.
|
|
|
|
|
After reading Joseph M. Newcomer's article (http://www.flounder.com/messages.htm), he is favoring in using RegisterWindowsMessage
However, there are some concern that, RegisterWindowsMessage may lead to resource exhaustion. http://stackoverflow.com/questions/1192204/can-abusing-registerwindowmessage-lead-to-resource-exhaustion
My situation is, I have a EXE with multiple DLLs. Each DLLs doesn't aware of each other DLL. Hence, the situation might happen if I am using WM_APP (Joseph M. Newcomer mark WM_USER as obsolute)
DLL_A.dll is sending DDL_A_REFRESH_MY_VIEW_MSG (WM_APP + 100)
DLL_B.dll is sending DDL_B_REFRESH_MY_VIEW_MSG (WM_APP + 100)
Does this mean, RegisterWindowsMessage will be the best choice, even my communication only tend to within a single process?
|
|
|
|
|
You might try using something like this:
int WM_DLL_A_REFRESH = RegisterWindowsMessage("DLL_A:Refresh");
|
|
|
|
|
I am a newbie to C++ and am trying to pass an array to a function and then display the contents of this array through the function. The array is populated through a different function though both functions reside within the same class. I am struggling to figure out how to execute the function object to execute the display function. Listed below are all of the code components:
//=============================================
Monop.h
class PurchaseProperty
{
public:
void PropInit(void);
char Display();
char DisplayProp(char [],int);
private:
};
//=============================================
MonopFunct.cpp
#include <iostream>
#include "Monop.h"
using namespace std;
using std::cout;
void PurchaseProperty::PropInit()
{
char *PropNameArray[] = {"Mediterranean Avenue","Baltic Avenue","Oriental Avenue","Vermont Avenue","Connecticut Avenue","St. Charles Place","States Avenue",
"Virginia Avenue","St. James Place","Tennessee Avenue","New York Avenue","Kentucky Avenue","Indiana Avenue","Illinois Avenue",
"Atlantic Avenue","Ventnor Avenue","Marvin Gardens","Pacific Avenue","North Carolina Avenue","Pennsylvania Avenue","Park Place",
"Boardwalk"};
float PropCostArray[] = {60,60,100,100,120,140,140,160,180,180,200,220,220,240,260,260,280,300,300,320,350,400};
float PropRentArray[] = {2,4,6,6,8,10,10,12,14,14,16,18,18,20,22,22,22,26,26,28,35,50};
float PropRent1Array[] = {10,20,30,30,40,50,50,60,70,70,80,90,90,100,110,110,120,130,130,150,175,200};
float PropRent2Array[] = {30,60,90,90,100,150,150,180,200,200,220,250,250,300,330,330,360,390,390,450,500,600};
float PropRent3Array[] = {90,180,270,270,300,450,450,500,550,550,600,700,700,750,800,800,850,900,900,1000,1100,1400};
float PropRent4Array[] = {160,320,400,400,450,625,625,700,750,750,800,875,875,925,975,975,1025,1100,1100,1200,1300,1700};
float PropHotelRentArray[] = {250,450,550,550,600,750,750,900,950,950,1000,1050,1050,1100,1150,1150,1200,1275,1275,1400,1500,2000 };
float PropHouseCostArray[] = {50,50,50,50,50,100,100,100,100,100,100,150,150,150,150,150,150,200,200,200,200,200};
float PropHotelCostArray[] = {50,50,50,50,50,100,100,100,100,100,100,150,150,150,150,150,150,200,200,200,200,200};
};
char PurchaseProperty::Display()
{
int cnt;
for(cnt = 0; cnt < 22; cnt++)
{
cout << "Program is Working";
}
return 0;
}
char PurchaseProperty::DisplayProp(char PropNameArray[], int)
{
int cnt;
for(cnt = 0; cnt < 22; cnt++)
{
cout << PropNameArray[cnt];
}
return 0;
}
//=============================================
Main.cpp
#include <iostream>
#include "Monop.h"
using std::cout;
using std::cin;
using std::endl;
char DisplayProp(char PropNameArray[],int);
int main()
{
PurchaseProperty object;
object.PropInit();
object.DisplayProp(PropNameArray,22);
return 0;
}
|
|
|
|
|
There are really a lot of errors in this code:
1) In the init function, you initialiaze a couple of arrays but these arrays are local to the init function, so you won't be able to access them. Which means that the code in the init function is useless. It is better to make these arrays members of your class.
2) Why do you declare a global DisplayProp function (in the main.cpp file) ? This function is a member of your PurchaseProperty class, so here you are simply declaring a new function that won't be used at all (and that doesn't even have a definition).
3) In your main function, you are calling DisplayProp and passing PropNameArray as argument. This variable doesn't exist anywhere, you need to actually pass an array that exists. What do you want to print there ? One of the arrays that was initialized in the Init method of your class ?
4) What is Display supposed to do ? What is the different between Display and DisplayProp ?
I really suggest that you start from a good book because it seems you lack some fundamental principles and without understanding them really well, you will have a lot of trouble writing any software.
|
|
|
|
|
Cedric,
Thank you for your comments. I have been self studying C++ How to Program as well as C Primer Plus. This is my first program. It is not copied from any source as I am trying to learn how to apply the principles.
As for my posting to clarify the problem I am having is the following (I should have been more clear in my initial posting):
I am attempting to call DisplayProp function which is a member of the PurchaseProperty class. I am making this call in the program Main. I though am having problems getting the program to recognize "PropNameArray". The following is the error message I am getting in Visual Studio 2008:
1>c:\users\mike certini\documents\visual studio 2008\projects\monopoly3\monopoly3\main.cpp(15) : error C2065: 'PropNameArray' : undeclared identifier
1>Build log was saved at "file://c:\Users\Mike Certini\Documents\Visual Studio 2008\Projects\Monopoly3\Monopoly3\Debug\BuildLog.htm"
--------------------------------------------------------------------------------
|
|
|
|
|
As Cedric already said, you really should get a good book, there's just too many problems with your code way beyond the syntactical issues your compiler complains about.
The latter is due to your apparent misunderstanding on the scope of variables in C/C++. If you declare a variable, this variable is only known within the scope it is declared in. In most cases this scope is between the previous opening '{' and the corresponding closing '}'. There are basically two exceptions: If you define a variable within the definition of a class (or a struct), then every function that is also defined as a member of that class has access to it. The other exception is when you declare a variable outside a function or class (or struct), which makes it a global variable. Global variables may be accessed anywhere, provided it's declaration comes prior to the location where it's defined. Check your C/C++ book of choice for further explanations on how to declare and access global variables. However, it is a good practice to keep the number of global variables to a minimum.
The compiler states that PropNameArray is an undeclared identifier because within the scope of the main function, the variable PropNameArray is not known. It is only known within the function PropInit(), where this variable was declared.
Note that all variables will be automatically destroyed when program execution leaves the scope they are declared in. In other words, when you execute the function PropNameInit(), the system will first create all these variables, then initialize them, and, when it leaves the function, immediately destroy them again. As has been pointed out in another response, the function PropInit() currently does nothing! You have three options:
1. Make the variables global (which is bad design).
2. Create the variables outside of the function (i. e. in main) and pass them as arguments to the function PropInit (which is impractical)
3. Declare these variables as attributes of the class
Hope this helps to get you started, but like stated before, do yourself a favor and get a book.
|
|
|
|
|
You are also missing the element count argument in DisplayProp
char PurchaseProperty::DisplayProp(char PropNameArray[], int count)
{
int index;
for(index = 0; index < count; index++)
{
cout << PropNameArray[index];
}
return 0;
}
No point supplying it if you don't use it.
|
|
|
|
|
Hi all,
I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release.
My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx.
But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened.
I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder.
Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like.
If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h]
[ Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
|
|
|
|
|
1.) you can compile a release with the option 'generate debug info' too.
2.) insert beeps or log-infos to localize the buggy code position.
3.) initialize all memory allocated by zero also static and local member.
4.) enshure you don't write beyond allocated memory.
5.) the debug version: checks memory (allocating more than neccessary and fill them with special values). also debug: checks the stack integrity.
6.) use the same compiler/linker options for release same as debug.
7.) turn on multithreading option.
|
|
|
|
|
you could tell the linker to produce a link map, then use that to identify which function contains 004320EE mov edx,dword ptr [eax+ecx*4+14h]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
