[jburns2]

Hello! I am trying to create a windows form application using the libxl library. I would like to give the user the option to browse for a particular .xls file on their machine. I save the file path that they type in as a string, and convert it to a const wchar_t* (this is the data type that the libxl "book" class needs to load a file). I cannot seem to get the file to load up. Here is the code that I've been using to convert the string of data into a wchar_t*:

string listFile = "Path1";
string templateFile = "Path2";

wstring p1, p2; 
	
const wchar_t* listFile_new =  (widen(listFile, p1)->c_str());
const wchar_t* templateFile_new =  (widen(templateFile, p2)->c_str());

My "widen" function looks like this:

wstring* widen( const string& str, wstring& incomingString)
{    
	wostringstream wstm; 
	const ctype<wchar_t>& ctfacet =                         
			use_facet< ctype<wchar_t> >( wstm.getloc() );    
	
	for( size_t i=0; i<str.size(); ++i )
		wstm << ctfacet.widen( str[i] );    
	
	wstm << L"\n";
	incomingString =  wstm.str();
	return &incomingString;
} 

When I run my program in the debugger it seems like the conversion works okay, but when I check the value of listFile_new and templateFile_new, the de-referenced data seems to only include the first character of the string. I am sort of new to this type of conversion so if anyone has any input/ideas on what the problem might be I'd greatly appreciate it.

Thanks!

[Skydiver]

If your debugger treats wchar_t * as traditional C-strings, then it'll only show the first character because each character is now two bytes, and typically the second byte is zero. Since C-string stop when a zero byte is found, then your debugger only shows the first character. On the other hand, if your debugger handles wchar_t * properly, something is seriously wrong with your widen() function.

A quick way to test is add this line to your code:

wchar_t * myWideString = L"Wider is better";

If your debugger is showing "Wider is better", it's time to look closely at your widen() function.

Your widen() function should NOT append a carriage return to the string. See line 10.

[jburns2]

Thanks for the reply.

Something very strange seems to be happening. When I include the line of code you wrote, the debugger skips over it all together. I'm not sure why that would be happening but perhaps it could be related to the problem?

[Skydiver]

Skipping over it is fine. The compiler probably figured out that it was a constant initialization and optimized the code.

The question though, is can you view the value of myWideString in your list of locals? If so, what is the value you are seeing?

[jburns2]

Hmm it does not seem as though myWideString is appearing in my list of local variables.

With regard to the file paths, the debugger is showing them as follows:


templateFile_new 0x000000001BFFAA30 "C:/...File Path..." wchar_t*
*templateFile_new 67 L'C' wchar_t

I'm not sure if that's the norm. I should also mention that I am working with VS 2010.

[Skydiver]

VS2010 should be showing you the entire string, but then I have know I idea if somebody has twiddled with your debugger settings. I've stuck mostly with the default settings and I'm seeing the entire string.

What it does say in the locals window for p1 and p2?

Worst case, go to Debug.Windows.Memory>Memory 1... and then type in templateFile_new. It should show you the UNICODE bytes for your widened path.

Irregardless, as long as you got rid of the extra carriage return appended by your widen() function, you should have a good path to give to libxl.

jburns2, on 09 July 2012 - 01:43 PM, said:

Hmm it does not seem as though myWideString is appearing in my list of local variables.

Are you sure you are looking at the Locals window rather than the Auto window.

Are you building in Debug or Release mode? If release mode, it's perfectly fine for the compiler to strip away unused variables. This also tends to confuse the debugger because some variables get put in registers rather than memory slots that the debugger is expecting.

This post has been edited by Skydiver: 09 July 2012 - 02:46 PM

[jburns2]

The problem has been resolved. It seems as though the whole time the issue was the extra carriage return. DOH! Thanks so much for your help!!

[WhyThis]

Hello,

I'm new to programming but this is very similar to something that I'm trying at home. Converting a string to wchar_t* has been very challenging. I've tired your solution but I keep getting a bunch of "error LNK2022" errors... and complaints that "has inconsistent metadata with (0A00009C) in MSVCMRT.lib"... Along with a bunch of other mish-mashed information and gibberish memory addresses that I don't yet understand.

Did you experience this? Might you know what is causing this?

Thanks for the posting.

[WhyThis]

Oops,

I asked my question a little too soon.

I was exploring another solution and I got that to work first.

But thanks, anyway.

[Skydiver]

Can you show us your code where you are trying to do the conversion from a standard C++ string to a wchar_t *?