|
When you create an object (like a mutex) you can specify a "name".
(see CreateMutex[^]).
In the child process you can retrieve another handle to that same object with OpenMutex[^], or whatever similar and coherent with the type of object) by giving it that name (that is supposed to be unique at least between all your entangled processes).
Note that the returned value may be different, due to the fact the the handle value is an "index of a table of indexes" that is different in the various processes.
The documentation talks improperly of inheritance of handles. What are inherited are the objects the handle refers to.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I think I'm front with a weird problem at combo box control :
If drop down list of combo box is down , and I delete all strings from combo box and call ShowDropDown(FALSE); I have assert error on strcore at 519 line .
In fact , it's mistake to call ShowDropDown(FALSE); when combo box is empty ?
|
|
|
|
|
Don't know what might cause that error but try "undropping" the list and then delete the strings? Or there's a particular reason why you try to delete first and then remove the list?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Yes , you are right , I thing that's the way to solve this problem ... weird behaviour . Thank you !
|
|
|
|
|
Yourwelcome.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
|
Interesting article, thanks for the link.
After reading it, I would say you can apply the same principle to STL by using the registry entry “std\:\:.*=nostepinto” instead of “ATL\:\:.*=nostepinto”. I haven't tried though. In any case, before trying this I'd create a restore point or whatever else you usually do to undo an unlucky change. It is an undocumented feature after all, and even if it weren't, manually editing the registry isn't for the weak of heart.
|
|
|
|
|
Hey, that actually works! Thanks
|
|
|
|
|
Every day you learn something new, is a good day. Thank you!
|
|
|
|
|
Excellent, thanks!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Hi all,
i have and unicode file, i wanna read this file by character wise,means read only one character at a time.
please tell me how can i do this.
thanks in advace.
|
|
|
|
|
|
|
What kind of Unicode text file are you dealing with (e.g. UTF-8 , etc..)?
What do you mean with 'character' (e.g. 'Unicode character' or 'single byte'?)?
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: What kind of Unicode text file are you dealing with (e.g. UTF-8 , etc..)? What do you mean with 'character' (e.g. 'Unicode character' or 'single byte'?)?
Using Unicode encoding type file and one character means single byte.
|
|
|
|
|
If you want to read a byte at time then use, as already suggested, fgetc[^].
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]
|
|
|
|
|
Hope you do know that unicode is two bytes and ascii is one byte...
|
|
|
|
|
UNICODE is actually a set of code-points whose cardinality requires 21 bits.
When encoded in sequence of 1 bye is called UTF-8 and when encoded as sequence of two bytes is called UTF-16.
In UTF-8 coding may vary from 1 to 4 bytes (and remains identical for code-points between 0 and 127, aka ASCII)
In UTF-16 coding may be 2 or 4 bytes (and is TWO for the most of Latin, Cyrillic and Greek characters, as many simplified Chinese).
UNICODE==2bytes is a misconception that originated at the time Windows included Unicode APIS using 16bits since -at that time- Unicode specs where not so wide.
Actually, reading 2bytes does not necessarily means "read a character".
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
unfortunately, i think it depends on what standard of C/C++ and what OS. I'm pretty sure windows defines unicode as 16bits...
from their website:
"Unicode: A fixed-width, 16-bit worldwide character encoding that was developed and is maintained and promoted by the Unicode Consortium, a nonprofit computer industry organization."
http://msdn.microsoft.com/en-us/library/cc194793.aspx[^]
|
|
|
|
|
I'm sorry for you and for Microsoft, but the one and only entitled to say what Unicode was, is and will be is www.unicode.org[^]
The page you linked is a very shame for Microsoft. A technical document like that cannot be written without specifying in the page itself a data when it was written (hey ... they speak about their new amazing Windows NT 3.5 ...) and for this sole fault should disqualify M$ of whatever authority in the field.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
so angry! ...similar articles found in the MS VS2010 area of MSDN... i don't do much in unicode so haven't needed to worry about it...
|
|
|
|
|
This is actually a miscoception ...
see here[^].
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
|
Nope.
1) Unicode is not a Microsoft product. What UNICODE is is defined by www.unicode.org[^]
2) Microsoft use to encode UNICODE into 16-bits units. That is a technique well defined by the UNICODE standard itself, known as UTF-16. Essentially, every code not in the range 0xD800-0xDFFF and lower than 0xFFFF is code as itself.
Every other greater that 0xFFFF is broken in two 10-bits chunks, or-ed with 0xD800 and 0xDC00 respectively.
The range 0xD800 - 0xDFFF is called "UNICODE surropgate" and does not contain valid codepoints.
So you can have single unicode characters requiring two wchar_t in sequence to be represented and sequences of two wchar_t representing a single character, with code greater than 0xFFFF (typical for CJK - Chinese, Japanese, Corean characters).
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
i certainly believe your point about unicode consortium being the authority... no argument there!
|
|
|
|