|
Carlo asked you what would you be doing with the const BYTE buffer after such a "conversion".
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Your code performs the conversion (i.e. the cast) of the pointer, not of the string. In other words the string buffer remains unchanged, it is just interpreted diffently.
Since that maybe fine or maybe a plain catastrophe, I need to know what is the purpose of your 'conversion'.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: I need to know what is the purpose of your 'conversion'.
Just noticed t hat we both have put that word in quotes. Fits the context perfectly. Subtly expressing something, ya know. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Are you aware of the fact that a BYTE is 8 bits and A WCHAR is 16 bits?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Hi Rajesh,
I am not aware of it...so does it mean that its not at all possible to convert??
|
|
|
|
|
Sure, you can reinterpret a pointer to a dialog as a pointer to a socket. It is possible to achieve that. But WHY?!
After such a conversion (assuming you did it), what will you want to be doing with the BYTE buffer?! Answer that.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Hi All,
I am actually learning vc++.. i just want to know whether it can be converted or not.. whether it is feasible or not..
my seniors have used a functions in which they have typecast like wat i have mentioned in the first message..they are sending type-cast parameter as an arugment to other functions..but it is not casting properly....its taking the first character alone..
if i say, const wchar* test = L"hello";
const BYTE* test1 = (const BYTE*)test; o/p will be 'h' alone..
Hence raised in this forum whether you people can enlighten me about this issue..
thanks,
rakesh.
|
|
|
|
|
Rakesh5 wrote: if i say, const wchar* test = L"hello";
const BYTE* test1 = (const BYTE*)test; o/p will be 'h' alone..
If you do need to convert the wide char string into a char one, then use a conversion macro instead, for instance (assuming a ANSI build, like yours):
const wchar_t * wstrTest = L"Hello";
CW2A strTest( wstrTest );
AfxMessageBox( strTest);
Rakesh5 wrote: my seniors have used a functions in which they have typecast like wat i have mentioned in the first message..
I hope your seniors know what they are doing.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi, Actually i have made my character set as unicode and not as multibyte in the project settings.. so its not converting fully..
is there any way to do by keeping the current settings?
thanks,
rakesh.
|
|
|
|
|
Then use
const wchar_t * wstrTest = L"Hello";
CW2A strTest( wstrTest );
AfxMessageBox( (CString) strTest);
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
A BYTE is an 8 bit data type. A WCHAR is a 16 bit data type.
Now, you can cast a BYTE pointer to a WCHAR pointer or vice versa. However, since these data types are of different sizes, and if you cast an array of BYTES to an array of WCHARs, the conversion will succeed, but the resultant buffer will be unusable (the code "won't work"). In other words, you only casted the pointer.
You can call a horse a dog, but however, it won't bark. OK, I know. That's not a good example, but you get the drift.
Rakesh5 wrote: my seniors have used a functions in which they have typecast like wat i have mentioned in the first message..they are sending type-cast parameter as an arugment to other functions..but it is not casting properly....its taking the first character alone..
I have a feeling that your seniors are not the brightest sparks for you to learn from. Or ask them to give you an explanation of what they're trying to achieve and ask them how such a "conversion" could make sense.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
|
Simply casting an 8-bit type to a 16-bit type is not going to produce the expected result. Consider:
8 8 8 8 8
╓─╥─╥─╥─╥─╖
║H║e║l║l║o║
╙─╨─╨─╨─╨─╜
16 16 16 16 16
╓─┬─╥─┬─╥─┬─╥─┬─╥─┬─╖
║H│0║e│0║l│0║l│0║o│0║
╙─┴─╨─┴─╨─┴─╨─┴─╨─┴─╜ In the top figure, each character uses 1 byte or 8 bits. In the bottom figure, each character uses 2 byte or 16 bits. The second byte holds a \0 character. Casting will not magically add that character.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Nice illustration, David.
But the Unicode string in the figure seem to have been terminated by a single '0' character, whereas it should be 2 '0's.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: But the Unicode string in the figure seem to have been terminated...
Actually, neither is terminated. I didn't deem that important.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Oh yeah. I only looked at the Unicode text. 
And yes, the illustration serves the purpose well.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
hai,
as a begineer in VC++ 6.0 programmer what are all the areas should i have strong knowledge........?
waiting for ur reply..
thank u'.......... 
|
|
|
|
|
thangvel wrote: as a begineer in VC++ 6.0 programmer what are all the areas should i have strong knowledge........?
Visual C++ 2010?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
thangvel wrote: as a begineer in VC++ 6.0 programmer what are all the areas should i have strong knowledge........?
It is more important to have a solid understanding of the C++ language than any IDE.
|
|
|
|
|
Seriously: The questions you will be asked may depend on how long have you been working on windows programming.
MFC:
Doc/View architecture (along with menus, splitter windows, rebars, scroll views, etc.,)
Dialog applications
Controls
Common controls
Thread basics (MFC thread classes and the hopelessly broken thread sync implementation of MFC)
GDI Basics
Message mapping in MFC (OK, you know it. But how does it work?)
COM (depends if you're into it or not)
Windows API: There's aplenty.
General: OOP, C++ language (very important)
Seriously 2: Use Google.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
|
Hi All,
I am having a UI thread and in the controlling function of the UI thread I am doing certain operations , but once the function gets over my thread exits .. so is there anyway i can stop this and make sure the thread exits only when i call suspendthread().
Please help me on this issue
Thanks,
Hari
|
|
|
|
|
Show some code, please, relevant parts should be enough to start with, btw, SuspendThread[^] doesn't "exit the thread", it just suspends its execution.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
This makes me recalling: "The Old New Thing: Why you should never suspend a thread".
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
hraman1987 wrote: but once the function gets over my thread exits
How possibly can an UI thread exit without you posting a WM_QUIT to its message loop? 
Are you even sure that it's an UI thread? Can you show me your relevant code?
Also, why would you EVER suspend a UI thread? If there are no messages to be processed, the thread is automatically blocked on the message loop.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
