|
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.
|
|
|
|
|
Hello,
Does anyone know how to register a dll or ocx file using c++ code (in particular I'm using vc++ 2008 standard)? I need it to work for Vista and Windows 7.
Thanks!
|
|
|
|
|
It's a three step process:
- LoadLibrary to get the DLL into memory
- GetProcAddress to get the address of the function DllRegisterServer
- Call DllRegisterServer through the pointer from GetProcAddress.
Or you can just link with the DLL normally and call DllRegisterServer by name.
Cheers,
Ash
|
|
|
|
|
Thanks Ash,
Will this work on Vista and Windows 7 with them having the extra security features?
|
|
|
|
|
I think so, I've done it successfully on both of them. There might have to be some fancy footwork on Vista but if there is my mind's a blank.
Oh, I was using it from a setup program which was running elevated under Vista and Windows 7 - which might be a problem.
Cheers,
Ash
|
|
|
|
|
Registering a DLL/OCX involves modifying the registry which means elevated privileges.
You can either always remember to run the registering application as administrator (Right click -> Run as administrator).
Or you can instruct the application to always run elevated - Project -> Properties -> Configuration Properties -> Linker -> Manifest File -> UAC Execution Level -> requireAdministrator.
|
|
|
|
|
You should initialise COM too, as the code here[^] shows.
Steve
|
|
|
|
|
You're partly right as the original poster mentioned ocxs, mea culpa!
However you don't have to initialise COM to load up a DLL and call an exported function on it. You can (conceptually) easily register most COM DLLs by writing to the registry directly - if you know all the details of the objects you're registering (GUIDs of the CoClasses and IIDs of the CoInterfaces). Have a look in "Essential COM" by Don Box for a script based DllRegisterServer that doesn't require COM to be initialised.
ActiveX controls may be an exception but they're out of my experience. If that's the case, as they implement OLE interfaces, you need OleInitialise() before registering and NOT CoInitialize().
Cheers,
Ash
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
