|
You can use OLE2A macro, for example,
USES_CONVERSION;
CComBSTR bstrSource = "Text to convert";
std::string sTarget = OLE2A(bstrSource);
Jaime
|
|
|
|
|
Thank you very much - that has made the next 2 crappy days 4 me better
|
|
|
|
|
I have an application that should be able to run either as a service or as a
user mode application. Currently, I call StartServiceCtrlDispatcher and if
it fails (error 1063) I run as user mode. But, StartServiceCtrlDispatcher
often takes several seconds before it fails when I'm running the app in user
mode, causing an annoying startup delay.
Can someone suggest a fast way to tell whether or not my application is
being started as a service? (Please do not suggest using command line
options.)
--------
There are 10 types of people in this world. Those who know binary and those who don't.
|
|
|
|
|
JT Anderson wrote:
Can someone suggest a fast way to tell whether or not my application is
being started as a service? (Please do not suggest using command line
options.)
I'm not sure what you've got against command line options - it would be the simplest solution...
You could call GetProcessWindowStation() and if it returns NULL, it is probably either running as a service or as a WTS process. If it is not NULL, then it was probably started by the user. Not perfect though.
Another way would be to get the user name that the process was started as. Generally services are run as the "Local Service" user (or something similar, can't remember exactly).
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I found a peculiar problem when using CSharedFile.
Requirement:
I have data present in (BYTE*) which needs to be converted to HGLOBAL. The data is segmented, that is the entire data is present in 2-3 BYTE*.
What was done:
a) Created a CSharedFile and attached it to a CArchive object. Then the entire BYTE* data was archived using a while loop for each BYTE*.
b) Called CSharedFile::Detach to obtain the HGLOBAL data.
Problem:
The actual size of the data is 1184 bytes. But when checking the actual size of the memory allocated using GlobalSize() function the return value was 8192!!!
Please let me know what could be the reason for this?
You can reach me at s_adityapalanki@yahoo.com
Thanks and regards,
Aditya Palanki
|
|
|
|
|
This is the documented behaviour for GlobalSize.
|
|
|
|
|
Dear Johan,
Does this mean that the extra memory that is being allocated is normal?
Can you suggest any other way of creating an HGLOBAL?
Regards,
Aditya Palanki
|
|
|
|
|
Aditya_Palanki wrote:
Does this mean that the extra memory that is being allocated is normal?
Yes, it allocates in blocks. If your allocation size is not an exact multiple of the block, you'll get extra padding.
Aditya_Palanki wrote:
Can you suggest any other way of creating an HGLOBAL?
GlobalAlloc is the way of doing it. If the receiver needs to know the size actually allocated, just add this value to the beginning of the block, for example.
|
|
|
|
|
Hello,
When you press ESC or Enter on the dialog the dialog will close. How can I remove this I don't want my dialog to close.
|
|
|
|
|
|
|
Hi Folks,
I am trying to access a java webservice from Visual C++ .NET.
This java webservice has following method.
public void CreateDoc(String[][] values);
When I add webreference to this webservice in my visual studio .net environment, it changes the method to look like as following.
HRESULT CreateDoc(BSTR* arrayOfarrayOfString_1, int arrayOfarrayOfString_1_nSizeIs);
So, now in my visual c++ code, I have to pass a string array in this above format of BSTR*. I have tried a lot achieving this but no success !
Can anyone give me some idea how to do that ?
Thanks in advance,
Arun.
|
|
|
|
|
Are you using SafeArrayAccessData before manipulation the BSTR* array?
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Arun, did you manage to find a way to do it?
|
|
|
|
|
I'm half asleep today. I ended up writing the following code....
printf("rta %s %s\n", "router""jmd", token);
Even the linux gnu c compiler compiles it OK!
 
I feel like I'm diagonally parked in a parallel universe
Jerry Davis
http://www.astad.org
http://www.jvf.co.uk
|
|
|
|
|
Jeremy Davis wrote:
Even the linux gnu c compiler compiles it OK!
I'm with the compiler. I see nothing wrong with the statement. What do you think is wrong?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
It's the "string1""string2" bit. It becomes "string1string2". I just never realised you could add strings like that.
My bad then!
I feel like I'm diagonally parked in a parallel universe
Jerry Davis
http://www.astad.org
http://www.jvf.co.uk
|
|
|
|
|
There's really nothing special about it. String constants occupy a spot in memory, and two, contiguous, quoted strings will be right next to each other. Consider the following:
char *pszName = "A really long string here" \
"...and the rest of it here.";results in pszName pointing to "A really long string here...and the rest of it here." in memory.
Make sense?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
That isn't how it works. The standard specifically says that the strings will be concatenated.
If what you said was true, the strings would have a '\0' between them. Also, there is nothing that says that strings are placed in the EXE in the same order they are found in the source files.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
The standard specifically says that the strings will be concatenated.
They're not concatenated as there is nothing to concatenate. Concatenation implies two or more strings, whereas the snippet I showed only has one string. The fact that it breaks two lines, or has multiple sets of quotes, is irrelevant.
Tim Smith wrote:
If what you said was true, the strings would have a '\0' between them.
I don't know where you pulled this from. 
Tim Smith wrote:
Also, there is nothing that says that strings are placed in the EXE in the same order they are found in the source files.
Uh, actually there is. While the preprocessor sees two separately quoted strings, once the extra quotes (and backslash) are removed, the compiler sees only one. Therefore, they are in memory in exactly the same way had they been written as one continuous string.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Read the C++ standard section 2.13.4.3. It specifically states that:
In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined...
The two strings are concatentated. They way you describe it is totally wrong. It doesn't just ignore the two quotes as also covered in 2.13.4.3. It doesn't just place the two strings after each other in the EXE. Literal string pooling requires that strings be moved around. But that is probably implementation specific but that does not mean it breaks the standard. Please find the section in the standard that says it must do this.
Also, a backslash is not required.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
Read the C++ standard section 2.13.4.3.
Then I must also consider these examples that accompany the Concatenation section:
Another way to continue a string is to have two or more consecutive strings. Adjacent string literals will be concatenated to produce a single string. The following example demonstrates this:
"hello " "there" // is equivalent to "hello there"
"hello" "there" // is equivalent to "hellothere"
char *third = "Hello " "there"; // stored as "Hello there\0"
Characters in concatenated strings remain distinct. For example, the strings "\xab" and "3" are concatenated to form "\xab3", rather than the single hex character \xab3.
I believe this site also has a mention of how concatenation is implemented.
Tim Smith wrote:
In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined...
My example did not mix wide and narrow literals, but that's not the point here.
Tim Smith wrote:
The two strings are concatentated.
Indeed, but not in the sense of what one typically thinks of with concatenation (e.g., the "+" operator).
Tim Smith wrote:
They way you describe it is totally wrong.
I respectfully disagree, as it makes perfect sense to me and others I've spoken with about it. Perhaps we are saying the same thing two different ways.
Tim Smith wrote:
It doesn't just ignore the two quotes as also covered in 2.13.4.3.
The compiler sees/stores the two concatenated literals as one single literal.
Tim Smith wrote:
It doesn't just place the two strings after each other in the EXE.
If the two concatenated literals were stored separately, how would the compiler know to find the other piece(s)? It's not like there is a pointer at the end of the first one that points to the start of the second one. Look at some of your latest .exe or .dll files and you'll see that string literals are kept together.
Tim Smith wrote:
Literal string pooling requires that strings be moved around.
Of course, but only when they are "pointed to" by different variables. Given a statement such as:
FindThisName(_T("This is someone's very long name"));the string literal is not going to be scattered around in multiple places. If it's moved, it's moved altogether. Now consider:
FindThisName(_T("This is someone's very long name"));
PrintThisAddress(_T("123 W. Evergreen St. Suite 9"));These two string literals are disparate so they will be stored independently of each other. If one is moved, the other might not be, and vice-versa.
Tim Smith wrote:
Also, a backslash is not required.
Of course it's not. I merely used one to show that there were indeed two string literals. Had I used something like:
char *pszName = "A really long string here""...and the rest of it here."; it might not have been immediately obvious that there was more than one literal.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Perfectly valid code.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi there
Im loading a dll from project1.exe, then start project2.exe by CreateProcess and pass it the Handle of loaded dll as a CommandLine parameter. After this in project2.exe I try to get the dll function's address by caling GetProcAddress with the given handle; But these addresses are NULL!
Where is the problem?
|
|
|
|
|
Are you sure that the handle returned from LoadLibrary() can cross process boundaries?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
