|
«_Superman_» wrote: In MFC, you should not directly access UI elements from background threads.
True.
«_Superman_» wrote: Instead, you must send messages to the UI thread to get and set elements for the UI.
Use can use SendMessage or PostMessage.
Not entirely true.
The reason for not accessing UI elements from another thread than the main thread is that you can quite easily create a deadlock situation. MFC classes for UI elements uses ::SendMessage() which will block until the message has been handled. If the main thread is not processing messages, possibly waiting for the thread that manipulates the UI element, the application will deadlock.
This of course means that you cannot use ::SendMessage(), even if you call it directly, as it would create the same potential deadlock situation.
::PostMessage() must be used since it doesn't wait for the message to be handled. It is possible to use ::SendMessageTimeout() to avoid a deadlock situation, but if the call fails the receiving thread never gets the message.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for clarifying that!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
SendMessage and PostMessage will do the job. You may also like to use PostThreadMessage instead of PostMessage 
|
|
|
|
|
If you pass the window handle that contains the UI you want to manipulate to the thread when created you can use it in ::PostMessage().
|
|
|
|
|
Have a look at the below code:
#include "stdafx.h"
#include "conio.h"
int _tmain(int argc, _TCHAR* argv[])
{
char name[20] = "Some Name";
printf("%s\n", name);
name[1] = 'a';
printf("%s\n", name);
char * name2 = "Some Name";
printf("%s\n", name2);
name2[1] = 'a';
printf("%s\n", name2);
getch();
return 0;
}
Why we get Runtime error when we modify name2[1] = 'a';?
|
|
|
|
|
It all boils down to the difference between an array and a pointer. For name, you have set aside room for 20 characters (that are initialized to "Some Name"). For name2, you are pointing to a static piece of memory. That memory cannot be changed.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Thanks Crow. That is constant piece of memory.
|
|
|
|
|
In this case... your definition of name2 is what is referred to as a string literal and points to data that is considered constant.
See here[^].
|
|
|
|
|
You are trying to modify a const char array (pointer).
This is not C++.
if you were writing proper C++, you would not get those problems (or a lot less likely).
std::string name = "some name";
std::cout << name << std::endl;
std::string name2 = "some name";
std::cout << name2 << std::endl;
name2[1] = 'a';
std::cout << name2 << std::endl;
Watched code never compiles.
|
|
|
|
|
Technically, to pick nits, it *is* C++ as C++ is a superset of C. What you are really saying is that it isn't "Object Oriented Programming" which is true, but it is still within the definition of C++.
|
|
|
|
|
Chuck O'Toole wrote: Technically, to pick nits, it *is* C++ as C++ is a superset of C
Does the newest ANSI C++ standard incorporate the latest ANSI C standard as a subset?
Last I heard that was not the case
|
|
|
|
|
The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.
|
|
|
|
|
Chuck O'Toole wrote: The point is, C++ did *not* decommit the "char" data type nor pointer
I was responding to what appeared to be a general comment about the language in general and in its entirety and not just one small part.
And that general comment, at this time (new standards), is wrong.
|
|
|
|
|
Context dude, gotta read comments in the context of the thread
|
|
|
|
|
Chuck O'Toole wrote:
Context dude, gotta read comments in the context of
the thread
And respond in that context.
Since another poster read your response in way similar to the way I read it, it suggests that your response is the one at fault.
|
|
|
|
|
C++98 is not a superset of C90 - especially when you consider const and what happens when you cast away const. C allows modification of literals (string and constants) through pointers while C++ doesn't or rather considers it undefined behaviour.
|
|
|
|
|
The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.
|
|
|
|
|
Agree with Chuck... technically it is C++.
|
|
|
|
|
Can people give me a list of compilers or interpreters that are capable of creating drivers (.sys files) followed by a link. 
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
You already have it, and I also gave you a suggestion as to how to find some tutorials and samples.
|
|
|
|
|
But when I use the WinDDK I get 3 files for whats suppost to be 1 file (the .sys file or driver). What I want to know is that if the driver or .sys file can work without those 2 other files (one .obj file and a debug database file) independently.
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Your original question asked for a list of compilers, so I'm not sure where you are going with this or why you are concerned. The .obj files are the output of the compiler which is then passed in to the linker to produce the executable code. In most projects there will be many .obj files input to the linker. In the case of driver builds the executable is a .sys file which has a special header used by the driver loader. The debug database is another extra that helps in debugging a new driver and, while not essential, is a useful tool for the developer. Using some other compiler would not make any difference to the build process or final product, and indeed why would you want to when the WinDDK kit has been created to do all the menial tasks and allow you to focus in writing your driver?
|
|
|
|
|
Richard MacCutchan wrote: Your original question asked for a list of compilers
Your right, but when you said I already had them.
Richard MacCutchan wrote: I'm not sure where you are going with this or why you are concerned
I'm wondering why I got 3 files when I compiled (successfully), when I compile a driver, I get the .sys file, but two files aswell.
But now I get it, I thought the .sys file needed those two files to run, like as if it was a dependency, but I guess not. But does WinDDK compile it as a binary build.
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Brandon T. H. wrote: But does WinDDK compile it as a binary build.
No, WinDDK does nothing, it is merely a set of templates and libraries collectively known as the Windows Driver Development Kit. You use that framework to write your driver code which is then built into the binary files as follows:
The C/C++ compiler (any one will do) converts the source code into interim object files which are in themselves not complete. They may have references to functions in other modules, and are all based on a starting address of 'relative' zero. These object files must then be combined by the linker which fixes external references by finding the object or library that satisfies the reference, rebases all the starting addresses to reflect the real start of the final program, and builds them into a single binary file, with various bits of meta-data required by the system to load the program. Whether the final object has a .sys or .exe extension is just a matter of convention laid down by the operating system. Any interim files may be used to rebuild the executable or aid in debugging as required by the developer, but are not critical to running the program.
|
|
|
|
|
Brandon T. H. wrote: if the driver or .sys file can work without those 2 other files (one .obj file and a debug database file) independently.
Yes, of course, even if it is a debug build.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
