|
Thanks Jonathan, that looks likely. Does that mean I have to link the ATL library to an MFC project to use the shared classes?
I hope you realise that hamsters are very creative when it comes to revenge. - Elaine
|
|
|
|
|
Hi Steve,
I'm afraid I'm not sure what you'll have to do though as its a shared class I'd expect you'd link to some Shared library but I'm not sure what that would be now. A common shared class is CString as there's is/was both ATL/WTL and MFC versions before they became shared. It may mean you just have to scope your call with MFC:: or add some #pragma statement of some sort. I'm pretty sure there were whole articles written on how to get around similar problems raised by the sharing of CString so it may be worth your while having a look at one of those. Sorry I can't be of more help.
Jonathan
|
|
|
|
|
Hello,
As we know that we can extract information like imported/exported functions after parsing PE file programatically.
But we can only take the names (function names imported/exported) of methods. We cannot look up their parameters(in/out)names with their types and return type of method.(as these parts encoded as HEX)
Is there any way out to extract these as well..?
Regards Muhammad Usman Khalil
|
|
|
|
|
In general, no. If the names are mangled (see name mangling[^]) it's possible however.
Steve
|
|
|
|
|
In addition to the other answer - if your executable has debug information associated with it, it is possible to extract full information about function argument and return types.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
How..?
Is that that info(info regarding return type and parameters) of method reside in PE file still..?
If yes then which area need to parse of PE to get such info(regarding return type,in/out params of method)
Regards
Usman
|
|
|
|
|
Don't parse the PE file directly - use Microsoft's DbgHelp API[^]. That'll cope even when the debug information's been split into a separate PDB file.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Hi all,
i m working on client server type application.
using socket to communicate between client and server.
Symantec antivirus detect a virus activity and display like this.
Symantec == Suspicious.Insight
please tell me how can i find out the main reasons for this and resolve this.
thanks.
To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.
|
|
|
|
|
|
I've got a RAID project to run into.
As you know, MS disk manager provides soft RAID managment such as creating RAID disk array and reconstructing disk image on RAID0 RAID1 RAID5.
Is there any API or DEVICEIOCONTROL code in C++ so I can manage RAID in my APP instead?
|
|
|
|
|
There is a macro _countof, the define is
template <typename _CountofType, size_t _SizeOfArray>
char (*__countof_helper(UNALIGNED _CountofType (&_Array)[_SizeOfArray]))[_SizeOfArray];
#define _countof(_Array) sizeof(*__countof_helper(_Array))
It confuse me that __countof_helper is a very weird pointer.
At first glance, I thought it is a pointer of array, but, how can an variable can have an "()" suffix???
|
|
|
|
|
It's a template of a function pointer array.
|
|
|
|
|
shouldn't a function pointer's size be 4?
how can a sizeof(*funcPtrArray(param)) turn out to be some relation with ReturnValTypeSize
modified on Sunday, January 31, 2010 9:20 PM
|
|
|
|
|
It declares a function that takes an array and returns an array of char with the same number of elements. The sizeof operator acts on the returned array to give the number of elements.
|
|
|
|
|
This makes sense. Thank you very much
|
|
|
|
|
I would like to test whether a stream was opened for binary read/writes or for plain text. The goal of my code is to output the data in a MyClass object in two different ways depending on this stream property.
class MyClass {
friend ostream& operator <<(ostream& stream, const MyClass& obj);
friend istream& operator >>(istream& stream, MyClass& obj);
}
ostream& operator <<(ostream& stream, const MyClass& obj) {
if ([stream is opened for binary writes]) {
...
} else {
...
}
}
istream& operator >>(istream& stream, MyClass& obj) {
if ([stream is opened for binary reads]) {
...
} else {
...
}
} Would doing such a thing be poor design, or is this pretty acceptable? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
First: A stream is not binary or plain text, it is: do i want to treat incoming bytes as binary or as plain text. It is perfectly legal to open a stream containing plain text as binary. Next: you must open a stream with a flag that tells how you want to open it, so you already know if it's binary or not. Ergo: there's no need to test this.
But i guess i'm completely missing the point...
|
|
|
|
|
Ok, let me rephrase... one of the members of MyClass is an array. If the user wants to output my class in a human-readable form, I want to print the array as "[elem1, elem2, ... elemN]". If not, then I want to output the array length followed by each element in a binary representation. Now, when someone tries to output my class as "cout << MyClassInstance", it should be the human-readable version. When serializing the class to a file for later reloads, I want to output the binary version. How can I infer which version to use? I could conceivably write a specific implementation for ifstream and ofstream so I always read/write the non-human-readable version to a file, but that isn't really what I am trying to do. I could also write a specific method to serialize vs. just outputting my class, but again, I don't know what the standard way of doing this is. Thanks for any insight,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
std::ios_base::open_mode can tell you how the file stream was opened. The values are listed in xiosbase.h [edit] in VS.
modified on Monday, February 1, 2010 8:42 AM
|
|
|
|
|
After reading your post, I assumed that I could just use the statement:
bool const isBinary = ((out.flags() & ios_base::binary) != 0);
However, after testing this it appears that the ios_base::open_mode is not stored in the return value of "ostream::flags()". I have been unable to figure out how to get something from an ostream object that tells me the ios_base::open_mode used. Any idea how to extract this information after the file has been opened? Thanks,
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Wow. 9 months later. Internet been a bit slow?
I'm sorry, I also incorrectly assumed the mode would be accessible somewhere within the stream obj.
Other than scanning the array data for CR,LF combos, or trying different read/write modes and seeing what fails and what succeeds, I don't how to determine how the stream was opened.
|
|
|
|
|
Yeah, clearly I get sidetracked easily. Anyway, I ultimately determined that opening a file in binary mode doesn't really do what I thought it did... I was under the impression that doing so would force the shift operator to output data in binary, which it doesn't. Therefore, I decided to implement two methods: one to output the data in binary, and the other to output it in ASCII format. Thanks for the help, though.
Sounds like somebody's got a case of the Mondays
-Jeff
|
|
|
|
|
Hello @ all,
i want to change the color in the titlebar,i mean the background.
Can anyone help me please?
|
|
|
|
|
If you're talking about the 'titlebar' of the app - as in the window frame, you'll need to handle WM_NCPAINT.
|
|
|
|
|
Hello and thanks,
may you can explain more exactly how i can do that
|
|
|
|