Non-Const char * to Juce::String

Ok, I know these conversion questions have been asked before, but I can not for the life of me figure out how to do something that should, in theory, be conceptually simple. Here’s my deal :

I have a char * that grabs values from strtok (). Given that the actual pointer itself is going to change, it can’t be a const.

I later in my code attempt to populate a Combobox value with this pointer.

No matter what ridiculous hoops I jump through to convert this into a form that Juce will be happy with, the thing will just flat-out not populate the Combobox. Wrapping with _T(), in-between conversion to std::string, strcpy’ing into a static char * casted as a const char * all have failed with flying colors.

I figure this sort of operation is routine and surely someone knows how to do this, but if I had any hair, I would’ve pulled it all out on this one by now.

char * Current_Token = NULL;
Current_Token = strtok ( (char *) readBuffer.c_str (), ",\n\0");
cboThe_ComboBox->addItem (Current_Token, Index);

No variation or conversion of Current_Token has been successful. There’s got to be something simple I am just missing on this. I hope someone can point me in the right direction. Working code is more than appreciated.

Are you sure what ever is being returned from strtok is a valid, null terminated char*? I would printf it to make sure. If it is valid then you should just be able to pass is to a String constructor e.g. const String token (Current_Token); DBG (token);

As addItem takes a const reference String you should just be able to pass it Current_Token as you are doing though, so it makes me wonder if your String just isn’t properly being decoded. Is it definitely ASCII?

If you’re tokenising a string however, you might want to look directly at StringArray as it provides a lot of constructors, one of which is bound to fit your needs and then can be passed directly to your ComboBox with addItemList.

If you’re still having problems can you post a sel-contained (non) working code snippet that will compile in the JUCE demo somewhere?

There’s way too much code distributed among a number of files to easily parse it out to put up here and NDA’s. The non-working portion is up in my original code block. I’ll add the type declarations below and a little of the code that deals with it FWIW. I’m not joking when I say these are the only components not working. All there is is a char * for the Token itself and the Combobox. The disconnect is somewhere between them.

I can confirm via my output debug files that strtok is working as it should, so, yes, it’s definitely ASCII. The failure is simply in adding it to the actual Combobox. To call this strange I would dub as a glorious understatement.

I did try the way you recommended, but this failed to populate the Combobox also. :S

// In class definition in header file
ComboBox * cboThe_ComboBox;

// In constructor for the class mentioned above
cboThe_ComboBox= new ComboBox (_T("The_ComboBox"));

addAndMakeVisible (cboThe_ComboBox);

cboThe_ComboBox->setBounds       (10,  130, 180, 20);

cboThe_ComboBox->addListener (this);

// Previous to dynamically populating the Combobox, I had code in the form of the following which *did* work :
cboThe_ComboBox->addItem (_T("Item 1"),     1);

This is a valid assumption and is indeed the case, but the question why isn’t generating valid answers. The char * is not const (though I did also try this and that also didn’t work), so I’m not sure if that matters. strtok modifies the pointer.

strtok is evil; that’s the problem.

how about use a StringArray then addLines' oraddTokens’

Assigning value-judgements to strtok non-withstanding, I don’t see how that will help me. Mind you, strtok is the portion that DOES work. I’d just end up with the same problem, just on a separate portion of the code.

Why the Combobox refuses to take the values from either the char * coming from strtok, a value I can happily write to files all day long, or any other intermediary form of string or char array is the real question, one I’d be profusely excited bordering on hyperbole if someone could answer.

Ok, as apparently I’m a glutton for punishment, I tried the form of addTokens, which sort-of works, but now the tokens get added twice. Somehow the inherited constructor for the AudioProcessorEditor (which subsequently calls the Combobox population function) gets called twice, and even though the StringArray is non-static, it writes the values again to it on the second pass, doubling up the number of elements added. This is just sheer stupid. This is why I instinctively used strtok to begin with.

Doesn’t this work: ?

char* buf = "something"; String juceString(CharPointer_UTF8((const char*)buf));

Well… this should be working:

char * Current_Token = NULL;
Current_Token = strtok ( (char *) readBuffer.c_str (), ",\n\0");
cboThe_ComboBox->addItem (String::fromUTF8(Current_Token), Index);

It’s something I’m doing everytime I have to exchange UTF8 strings with my communication SDK.

It makes no difference at all whether you use a char* or a const char*.

char* n = "dfgdfdfd"; comboBox.addItem (n, 1); // this will work for ASCII comboBox.addItem (String::fromUTF8 (n), 1); // this will work for UTF8 comboBox.addItem (CharPointer_UTF8 (n), 1); // this will also work for UTF8

If it wasn’t working, then it’s definitely because the strings you were feeding it were not what you expected. Like hugh said, strtok is evil, and must be avoided at all costs.

…no, it’s not stupid at all! Note the fact that the method is called addTokens, and that its comments very clearly explain that it adds the tokens to the array!

Again though, why is this being considered “evil”? For this term to be used I require explanation of assignment of value judgement. Simply stating “it’s evil” is insufficient.

just google, evil strtok

The explanations out there explain why it’s so bad.