Cihan Altinay wrote:
Jacek Caban wrote:
@@ -321,7 +321,7 @@ static HRESULT do_process_key(LPCOLESTR
break;
}
-if(key_type != IS_VAL && key_type != DO_DELETE && *iter ==
'{') {
+if(key_type != IS_VAL && key_type != DO_DELETE && *iter ==
'{' && !iter[1]
Jacek Caban wrote:
Hi Cihan,
Cihan Altinay wrote:
Ok, I looked into it again and found a solution. The problem
was that the '{' character was treated as a separator which
is generally correct. But it seems that key names like the one
mentioned above are allowed without single quotes around the
Hi Cihan,
Cihan Altinay wrote:
Ok, I looked into it again and found a solution. The problem
was that the '{' character was treated as a separator which
is generally correct. But it seems that key names like the one
mentioned above are allowed without single quotes around them.
The attached patc
Cihan Altinay wrote:
Hi,
For example instead of creating the key
HKCR\CLSID\{63623F01-D9C7-11D5-A76B-8657580F}
I get
HKCR\CLSID\{
and
HKCR\CLSID\63623F01-D9C7-11D5-A76B-8657580F}
Maybe the trace output from atl helps finding the reason:
Ok, I looked into it again and found a so
Hi,
For example instead of creating the key
HKCR\CLSID\{63623F01-D9C7-11D5-A76B-8657580F}
I get
HKCR\CLSID\{
and
HKCR\CLSID\63623F01-D9C7-11D5-A76B-8657580F}
Maybe the trace output from atl helps finding the reason:
trace:atl:string_register (0x4038bf40 L"HKCR\r\n{\r\n\tPSRServe.P