|
It's not shocking to me, it's pathetic and annoying. This situation has existed for many years, and MS continues to ship this crappy API.
|
|
|
|
|
Rajesh R Subramanian wrote: Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Thats Incredible 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
The documentation for IsTextUnicode() states:
Determines if a buffer is likely to contain a form of Unicode text.
Which is to say, it can only test for the likelihood by sampling various bytes within the buffer. Since there is no byte or word pattern which absolutely guarantees that a buffer is Unicode there is no way that such a function can guarantee to recognise it.
It's time for a new signature.
|
|
|
|
|
And I've asked them several times why they have that crappy API and they say it could help instead of nothing.
But the problem is - it NEVER worked, so why have it?!
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
You are right, I just tried it and what do you know - it doesn't work.
See other answer below.
It's time for a new signature.
modified on Saturday, June 26, 2010 9:32 AM
|
|
|
|
|
Nothing seems to work.
The output of the code below is always Text is ASCII
#define UNICODE
#define _UNICODE
#include <windows.h>
#include <tchar.h>
#include <wchar.h>
#include <stdio.h>
int main()
{
char *asciimessage = "This is an ASCII string.";
wchar_t *unicodemessage = L"This is a Wide Unicode string.";
TCHAR *automessage = TEXT("This message can be either ASCII or UNICODE!");
if(IsTextUnicode(unicodemessage,80,NULL))
printf("Text is Unicode\n");
else
printf("Text is ASCII\n");
if(IsTextUnicode(asciimessage,80,NULL))
printf("Text is Unicode\n");
else
printf("Text is ASCII\n");
return 0;
}
|
|
|
|
|
Your parameters are incorrect. You have specified 80 for the buffer length in both your calls, but neither of your strings are 80 bytes long, so the tests will be inspecting some random data beyond the end of the strings.
See also my response below.
It's time for a new signature.
|
|
|
|
|
This code works:
char ascii[] = "The rain in Spain";
WCHAR ucode[] = L"The rain in Spain";
wcout << "Testing the ASCII string" << endl;
if (IsTextUnicode(ascii, sizeof ascii, NULL))
wcout << "It is Unicode" << endl;
else
wcout << "It is NOT Unicode" << endl;
wcout << "Testing the Unicode string" << endl;
if (IsTextUnicode(ucode, sizeof ucode, NULL))
wcout << "It is Unicode" << endl;
else
wcout << "It is NOT Unicode" << endl;
The issue seems to be that the buffer length must be correct, and parameter 3 should be NULL to ensure all possible tests are tried.
It's time for a new signature.
|
|
|
|
|
Thanks Richard.
I ran your code and it works.
Output:
Testing the ASCII string
It is NOT Unicode
Testing the Unicode string
It is Unicode
Press any key to continue
Complete code listing
#define UNICODE
#define _UNICODE
#include <windows.h>
#include <tchar.h>
#include <wchar.h>
#include <stdio.h>
#include <iostream.h>
int main()
{
char ascii[] = "The rain in Spain";
WCHAR ucode[] = L"The rain in Spain";
cout << "Testing the ASCII string" << endl;
if (IsTextUnicode(ascii, sizeof ascii, NULL))
cout << "It is Unicode" << endl;
else
cout << "It is NOT Unicode" << endl;
cout << "Testing the Unicode string" << endl;
if (IsTextUnicode(ucode, sizeof ucode, NULL))
cout << "It is Unicode" << endl;
else
cout << "It is NOT Unicode" << endl;
return 0;
}
|
|
|
|
|
I wish it were as simple as that. Try this:
LPCWSTR str = L"कमल";
BOOL b = false;
b = IsTextUnicode(str, _tcslen(str), NULL);
if(b)
AfxMessageBox(L"Text is Unicode!");
else
AfxMessageBox(L"Boo!");
I've worked extensively with Asian languages and I've never had this API to work reiably. I know the documentation kinda confesses it, but there has been no development on this at all!
Richard MacCutchan wrote: char ascii[] = "The rain in Spain";
Richard MacCutchan wrote: if (IsTextUnicode(ascii, sizeof ascii, NULL))
Also, your example is flawed because you're wrongly passing the size of the pointer instead of passing the size of the buffer itself in bytes.
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
Rajesh R Subramanian wrote: Also, your example is flawed because you're wrongly passing the size of the pointer instead of passing the size of the buffer itself in bytes.
No. Last time I checked:
char ascii[] = "The rain in Spain";
sizeof ascii == ::strlen(ascii) + 1
|
|
|
|
|
Yes, yes, apologies. See my reply to Richard.
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
No worries, I consider it a typo
|
|
|
|
|
I wonder what result you would get if the second param was number of bytes:
1 LPCWSTR str = L"कमल";
2 BOOL b = false;
3 b = IsTextUnicode(str, _tcslen(str)*sizeof(WCHAR), NULL);
|
|
|
|
|
What pointer? Richard was taking the size of an array.
Ash
|
|
|
|
|
This works: (apologies if that is not Hindi, and I hope it's a nice word!)
WCHAR hindi[] = L"कमल";
wcout << sizeof hindi << endl;
if (IsTextUnicode(hindi, sizeof hindi, NULL))
wcout << "It is Unicode" << endl;
Note the result of the sizeof operator; sizeof arrayName gives size in bytes, which is the value required by the IsTextUnicode() function.
It's time for a new signature.
|
|
|
|
|
I must stop replying in the middle of the night. I overlooked it were size of an array.
The word cannot be nicer, it means "Lotus". This probably means the API is now "improved"?! I'd be glad to go and test some of the old stuff that never worked. I'll keep you posted if they don't!
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
Rajesh R Subramanian wrote: I must stop replying in the middle of the night.
If it's any consolation I do this all the time in the middle of the day!
It's time for a new signature.
|
|
|
|
|
|
One other idea that comes to mind
try {
cout << mystring << endl;
catch
wcout << mystring << endl;
}
http://www.contract-developer.tk
|
|
|
|
|
Working on an MDI program. There is a toolbar ,in which there is an CMFCToolBarComboBoxButton item, in one of the views. User need to open multiple views of the same type. The question is the combox item will change together when user changed it in one view, even through the combox is in different views.
What's wrong? Is it designed by Microsoft?  
|
|
|
|
|
Since the button will have the same ID in all views, and you probably have hooked up event handlers for it, they will behave as one. It's the same code running for all, and also, you have the same document.
To avoid this, you could change the control ID for each new view created. Takes a bit of house keeping to keep within allowed ranges and maybe managing reuse of ID's.
Are you really sure you have to display the same view more than once? It also sounds as instead of opening a new view, you should create a new document with the same view type.
|
|
|
|
|
Thanks for your reply.
Yes. It is same views of same document. In the program, I really need multiple views of same type in one document. Simply, the program is a Single Docment Multiple Views one. More than one view of same type are displayed to view different data from data controller with SQL query support.
But I find if I use normal CCombox control other than CMFCToolBarComboBoxButton, it works well. I guess it may be a question with CMFCToolBarComboBoxButton.
Any more inputs?
|
|
|
|
|
In case of the classic CComboBox implementation, the toolbar does not deal with the control at all. It just reserves some space and paints it in-place. You explicitly manipulate the control when some event is triggered in you program.
With the new MFC classes, this is done for you. I think the reason is the customization possibilities, where in theory you can put the same button/control more than once in a toolbar.
|
|
|
|
|
ooh...okey. Now it seems a problem for me.  Originally, I think the view instance is not the same one in spite of same type of view. So the CMFCToolBarComboBoxButton control object is also created onece for each view. Only the ID is the same. The click/change message for the control may be routed to different target view. I think only the control box which is clicked actually should changed.
Whatever, any way to make it happen? I really donot want to use CComboBox control to implement. it is not a easy way to do. In that case, you need to control the the box by yourself completely, including its possition and behave.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
