|
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
|
|
|
|
|
I've read "Essential COM". In the case of the script bases registration code (I can't remember it explicitly) the script runtime almost certainly initialises COM (so it's already done). I understand that LoadLibrary and friends don't require COM, but that's hardly the point. The point is the runtime environment the registration code is allowed to assume.
Steve
|
|
|
|
|
Your memory's a bit faulty on that one, the code in the book doesn't initialise COM or assume that it's loaded by a process that's already initialised it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
