C / C++ / MFC Discussion Boards

Richard MacCutchan2-Jan-11 1:14

2-Jan-11 1:14

I'm no expert, but I do not think you can call a C++ function directly like this, and expect a String to be returned. I would suggest posting your question in the Visual Basic forum, as someone there will probably know the answer.

Just say 'NO' to evaluated arguments for diadic functions! Ash

Re: LPCWSTR Problem.?

User 74293382-Jan-11 3:47

User 7429338

2-Jan-11 3:47

The hello string is a local variable within the DisplayInfo() function; so when you return, the memory is freed. You return a pointer to the string, but the string's memory got overwritten.

To fix this this particular problem, you could make hello a static variable; this will keep its address valid after returning.

Another, more generally usable way would be to pass a string variable to DisplayInfo() and copy hello's content to it inside the function.

modified 13-Sep-18 21:01pm.

Re: LPCWSTR Problem.?

CPallini2-Jan-11 5:03

CPallini

2-Jan-11 5:03

Actually, in this particular case, the local variable points to a string literal that is, of course, not freed.
Smile | :)

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]

Re: LPCWSTR Problem.?

Stefan_Lang9-Jan-11 23:54

Stefan_Lang

9-Jan-11 23:54

I wouldn't be too sure about that. The variable hello is not declared const, so it would be valid to modify the content of this string later in the code like this:

hello[3]=0;

This means the compiler does have to create a local string variable on the stack, inside this function. And this particular string variable will indeed be destroyed upon return.

You might argue that there is no such modification, but since the function itself passes a (non-const) pointer to this string, the caller might modify the contents instead! Also, later calls to that function need to initialize hello with the original string, not an address to a presumed literal which in the meantime might have been changed to god knows what. So what you'll want to pass is a copy of the literal being used for intialization, not the address of the literal itself!

Re: LPCWSTR Problem.?

CPallini10-Jan-11 0:21

CPallini

10-Jan-11 0:21

Stefan63 wrote:
This means the compiler does have to create a local string variable on the stack, inside this function. And this particular string variable will indeed be destroyed upon return.

You are wrong, at least on Microsoft compiler, these strings have static storage duration, see http://msdn.microsoft.com/en-us/library/0h227906.aspx[^].
Smile | :)

Re: LPCWSTR Problem.?

Stefan_Lang10-Jan-11 0:45

Stefan_Lang

10-Jan-11 0:45

Duh

Microsoft wrote:
Microsoft Specific

You win

P.S.:
if a DLL uses a static variable, and gets called just once, will the variable be released after the last (and only) call, or at the end of the lifetime of the application that calls it?

I'm pretty sure about a C++ app calling a C++ DLL; but not so much about another language app that might use other DLL bindings...

Re: LPCWSTR Problem.?

CPallini10-Jan-11 0:58

CPallini

10-Jan-11 0:58

Actually it looks a more general fact, see, for instance http://stackoverflow.com/questions/267114/scope-of-string-literals[^] (look at reported sentences of the C++ standard).

Static variables are, ehm, static, in other words, must be there...
Smile | :)

Re: LPCWSTR Problem.? [modified]

Stefan_Lang10-Jan-11 2:44

Stefan_Lang

10-Jan-11 2:44

Thanks for the link. My problem with the original question was that I didn't notice the 'C' part of the return type, assuming it was LPWSTR, like the cast on the return statement. Also the variable hello is not a const string pointer. At the very least the local variable used to temporarily store a pointer to the literal is a non-const pointer however, and thus should be usable for modifying the string it points to!

I've tested it in Visual Studio though, and it appears that even a non-const string pointer initialized to point to a string literal may not be used to change that literal: code that tries to do this does compile without warnings, but when run causes a run-time exception. For all I know this behaviour is Microsoft Specific.

Consider this example

char* DisplayInfo()
{
   char* hello = "hello!";
   return hello;
}

int _tmain(int argc, _TCHAR* argv[])
{
   char* h = DisplayInfo();
   if (strlen(h)>0)
       h[0] = 0;
	return 0;
}

When you call DisplayInfo, normally all you should care about is the function prototype, which states it returns a pointer to characters. By testing the string length you assert that the pointer is non-zero and points to an array of characters of non-zero length. it should be totally legitimate to alter individual characters within that array, as the return type was non-const.

But it turns out doing so might result in a run-time error, depending on how DisplayInfo is being implemented, and based on how string literals are being treated, even when dealing with non-const string types!

The link you provided mentions const string types only, and thus doesn't apply here - this is indeed compiler-specific, and might indeed just be Microsoft Specific.

Regarding my PS question: I was just being overly cautious. A dynamic library will only be loaded once it's used, not neccessarily upon starting the application that uses it. So the static variables will not exist from the start. I wondered whether for similar reasons the DLLs might be discarded once they are no longer needed. But of course, that is absurd, as the application wouldn't know in advance when a DLL is being called for the last time... Blush | :O

P.S. (another one):
I just noticed that the last section of the quote from the standard states

The C++ Standard wrote:
The effect of attempting to modify a string literal is undefined.

This implies you do in fact have a non-const string pointer. Before it says

The C++ Standard wrote:
An ordinary string literal has type "array of n const char"

(or const wchar_t).

How can you modify const char? I am confused now Confused | :confused:

modified on Monday, January 10, 2011 8:52 AM

Re: LPCWSTR Problem.? [updated]

CPallini2-Jan-11 5:12

CPallini

2-Jan-11 5:12

It looks like VB6, isn't it?
As far as I know the Visual Basic Runtime takes for granted that DLLs' functions use ANSI strings and takes care about the conversions, hence you have to use char* instead of wchar_t* inside your DisplayInfo function.

BTW have a look, for instance, at the following tutorial http://www.programmers-corner.com/tutorial/4[^].

[update]
Please note you mustn't return the string that way, you should instead modify the passed buffer, see this MSDN article[^].
[/update]

Smile | :)

modified on Sunday, January 2, 2011 12:33 PM

Re: LPCWSTR Problem.?

Sauro Viti2-Jan-11 5:39

Sauro Viti

2-Jan-11 5:39

As far as I know, the VB6 strings are unicode and their VC correspondant is the BSTR type...

Re: LPCWSTR Problem.?

CPallini2-Jan-11 5:59

CPallini

2-Jan-11 5:59

Sauro Viti wrote:
As far as I know, the VB6 strings are unicode

Yes, that's the reason I was talking about 'conversion'.

Sauro Viti wrote:
and their VC correspondant is the BSTR type...

That holds for VB6 interacting with C++ COM components, however for standard C++ DLLs the scenario is a bit different (according to MSDN[^]):

In order to develop your C DLL, it is important to know how Visual Basic handles strings internally in order to know how they will be passed to your DLL functions. Most C functions expect a string to be a null-terminated, ASCII character array. But Visual Basic uses a type-safe Automation string called a BSTR. For the Win32 platform, a BSTR is a long pointer to an allocated memory structure containing a Unicode character string and a 32- bit integer prefix that stores the length of the string.

You can ignored most of this difference, because Visual Basic will automatically convert any Unicode BSTRs to ASCII before passing them to an external function.

BTW: Note the typo in 'ignored'... Big Grin | :-D

Re: LPCWSTR Problem.?

Sauro Viti2-Jan-11 6:03

Sauro Viti

2-Jan-11 6:03

CPallini wrote:
You can ignored most of this difference, because Visual Basic will automatically convert any Unicode BSTRs to ASCII before passing them to an external function.

This will mean that VB pass strings to DLLs as ANSI, but what's about the opposite: what VB does with strings returned by a DLL function call?

Re: LPCWSTR Problem.?

CPallini2-Jan-11 6:33

CPallini

2-Jan-11 6:33

Of course VB6 takes care of performing the opposite conversion (you know, that language was highly engineered... Roll eyes | :rolleyes:

).
However that doesn't happen on the function return value but on passed parameter (I need to update the reply to the OP).
From the same MSDN article (did you read it?):

void __stdcall FillString(LPSTR pszString, LONG cSize)
{
   // Create a temp buffer with our string
   char buffer[] = "Hello from the C DLL!";

   // Copy our temp string to pszString
   // but check the size to make sure we have a buffer
   // big enough to hold the entire string.
   if (cSize > strlen(buffer))
      strcpy(pszString, buffer);
}

Re: LPCWSTR Problem.?

goldenrose94-Jan-11 0:11

goldenrose9

4-Jan-11 0:11

thanx. but if i want to change this function for unicode what changes have to be done, so this function supports unicode.

gold

Re: LPCWSTR Problem.?

CPallini4-Jan-11 0:27

CPallini

4-Jan-11 0:27

I suppose you should make a COM component.
Smile | :)

Re: LPCWSTR Problem.? [modified]

Stefan_Lang10-Jan-11 0:21

Stefan_Lang

10-Jan-11 0:21

The problem you try to solve is passing a string to a caller, where the caller has no knowledge of the length of that string, and therefore cannot easily provide a buffer variable to store that string into.

The posted solution does not work, because the compiler will create a local copy of the string literal you used for initialization, and the address to that copy will be invalidated upon return.

If you used const wchar_t* instead of wchar_t*, and the appropriate const string types, it might have worked. But if you want a non-const string, then there are really only two possible ways to deal with this:

1. use a secondary function that enables the caller to inquire about the expected length of the string, and then pass a buffer of sufficient size to DisplayInfo.

const wchar_t* HELLO = _T("Yahoooooo");
int DisplayInfoSize()
{
    return wcslen(HELLO);
}
LPCWSTR __stdcall DisplayInfo(wchar_t* hello)
{
    return wcscpy(hello, HELLO);
}

2. Have DisplayInfo allocate memory on the heap to story that string.

const wchar_t* HELLO = _T("Yahoooooo");
LPCWSTR __stdcall DisplayInfo()
{
    wchar_t* hello = new wchar_t*[wcslen(HELLO)+1];
    return wcscpy(hello, HELLO);
}

Solution 1 is awkward, but it makes sure the caller can release the allocated memory once the string is no longer needed. Solution 2 might create a memory leak, if the caller has no way to properly release the string being passed to it (which may very well be the case if it's called from VB), but it would not require a change of the interface.

P.S.:

Just realized that the return type on your DisplayInfo function is a const string! This means that the compiler should indeed just return a pointer to the literal as others already pointed out. I'm sorry, I got confused by the cast in your return statement (which is non-const string!)

The suggestions above might still work if none of the other responses are helping.

modified on Monday, January 10, 2011 6:34 AM

Adding a reference to MFC Project....

AmbiguousName1-Jan-11 8:09

AmbiguousName

1-Jan-11 8:09

hello guys... When I craete a NEW solution in VS 2008 and choose the solution combo box as "Add to the Solution", only then I can add a reference (a dll reference). But If I create a solution and choose the solution combo box as "Create New SOlution", it does not show me the required reference even after providing all the necessary paths. How can I add the reference when I choose the "Create a New Solution"??

How can I initialize an CListBox& null reference ?

mesajflaviu1-Jan-11 4:57

mesajflaviu

1-Jan-11 4:57

I want to ask you something ( maybe ) simple question :
Can I initialize an CListBox& ListCtrl reference with null value ? Because later , I want to use ListCtrl reference variable in many if contitions ...
I try :

CListBox& ListCtrl = NULL;

and doesn't go ...
Give me an error like this :

initializing' : cannot convert from 'const int' to 'class CListBox &'

Re: How can I initialize an CListBox& null reference ?

BicycleTheif1-Jan-11 5:28

BicycleTheif

1-Jan-11 5:28

Hi,

You are trying to initialize a reference to CListBox, in which case you need to give proper object. NULL is nothing but a typedef of '0'. To solve your problem try to use a pointer variable instead of reference variable.

CListBox *pListBox = NULL;

Re: How can I initialize an CListBox& null reference ?

mesajflaviu1-Jan-11 5:32

mesajflaviu

1-Jan-11 5:32

I can use CListBox* pList = NULL;
Why , because somewhere I have :

CListBox& GetListBoxCtrl() const {return *(CListBox*)this;}

How can I solve the problem ?

Re: How can I initialize an CListBox& null reference ?

«_Superman_»1-Jan-11 7:41

«_Superman_»

1-Jan-11 7:41

You cannot assign NULL to a reference.
In your case you can do this - CListBox* pListBox = &GetListBoxCtrl();

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

Re: How can I initialize an CListBox& null reference ?

CPallini1-Jan-11 7:54

CPallini

1-Jan-11 7:54

Nope.

Re: How can I initialize an CListBox& null reference ?

bleedingfingers2-Jan-11 20:08

bleedingfingers

2-Jan-11 20:08

C++ basics would help.

...byte till it megahertz...

my donation to web rubbish

How can send message to an notepad ? [modified]

mesajflaviu1-Jan-11 2:53

mesajflaviu

1-Jan-11 2:53

I open an notepad application :

void CTestMessageView::OnHelpStartapplication() 
{
	// TODO: Add your command handler code here

	ShellExecute(m_hWnd,"open","notepad.exe",NULL,NULL,SW_SHOWNORMAL);
}

and I want to send some message to notepad :

void CTestMessageView::OnHelpSendmessage() 
{
	// TODO: Add your command handler code here

	CString sTemp = "Test message\n";

	HWND hWnd = ::FindWindow("Notepad",NULL);
	if(hWnd)
	{
//		::PostMessage(hWnd,WM_CLOSE,0,0);
		::PostMessage(hWnd,WM_CHAR,(WPARAM)'1',0);
		::PostMessage(hWnd,WM_KEYDOWN,'1',0);
		::PostMessage(hWnd,WM_SETTEXT,0,(LPARAM)(LPCTSTR)sTemp);
		::PostMessage(hWnd,EM_REPLACESEL,0,(LPARAM)(LPCTSTR)sTemp);
	}
}

but only first message WM_CLOSE ( comment one ) is receipt by notepad , other , not . I think that other message then WM_CLOSE is addressed for view of notepad , not the main frame window of the notepad . My question is , how can I send message to the view , not the main frame window of notepad ?

modified on Saturday, January 1, 2011 9:13 AM

Re: How can send message to an notepad ?

Espen Harlinn1-Jan-11 4:43

Espen Harlinn

1-Jan-11 4:43

Do an EnumChildWindows[^] on your hWnd and locate the edit control

Regards
Espen Harlinn

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.