Unicode version of FindFirstUrlCacheEntry

HT

unread,

Dec 10, 2007, 4:06:06 PM12/10/07

to

Hi there,

Here is the scenario (for XP machine):

I have an user whose username is: joséna

I have a C++ app that uses FindFirstUrlCacheEntry/FindNextUrlCacheEntry to
enumerate thru IE cookies.

The ANSI version of the API has no problems and returns her username
correctly:
lpszSourceUrlName = "Cookie:josén...@somesite.com"

But with IE7 and Unicode version of these APIs, the return value is:
lpszSourceUrlName = "Cookie:jo...@somesite.com"

so, for some reason the character "é" is gone and when using
DeleteUrlCacheEntry this will cause this API to fail because the entry
doesn't exist without the "é"...

Can please someone let me know if there is a workaround? or if I am doing
something wrong...

Thanks

Volodymyr Shcherbyna

unread,

Dec 11, 2007, 4:58:08 AM12/11/07

to

I will contact WNDP team regarding this issue.

--
Volodymyr
"HT" <ht...@yahoo.com> wrote in message
news:uP2T%23B3OI...@TK2MSFTNGP03.phx.gbl...

htome

unread,

Dec 11, 2007, 9:04:12 AM12/11/07

to

Sorry, problems with the editor...it should read:

The ANSI version of the API has no problems and returns her username
correctly:
lpszSourceUrlName = "Cookie:josén...@somesite.com"

But with IE7 and Unicode version of these APIs, the return value is:
lpszSourceUrlName = "Cookie:jo...@somesite.com"

I also had the problem with a French user with username
"propriétaire"...the Unicode version is retrieving:
lpszSourceUrlName = "Cookie:propr...@somesite.com"

Extended characters are not being properly handled by the Unicode
version of APIs.

On Dec 11, 4:58 am, "Volodymyr Shcherbyna"

> > Thanks- Hide quoted text -
>
> - Show quoted text -

HT

unread,

Dec 11, 2007, 8:55:55 PM12/11/07

to

in the attempt to fix the problem, I went ahead and assembled the string
manually so I could use DeleteUrlCacheEntryW but for my surprise it also has
a bug/problem...

if I try to use an Unicode string like "Cookie:josén...@somesite.com" with
DeleteUrlCacheEntryW, it fails to delete

but if I use DeleteUrlCacheEntryA with a ANSI string (naturally) then it
works...

So, because my app is Unicode, I had to manually assembled the string,
convert it to ANSI and use with DeleteUrlCacheEntryA to make this works...

Well, I will wait for you findings with WNDP...

Thanks

"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:ebjhex9O...@TK2MSFTNGP02.phx.gbl...

HT

unread,

Dec 11, 2007, 8:58:34 PM12/11/07

to

in the attempt to fix the problem, I went ahead and assembled the string
manually so I could use DeleteUrlCacheEntryW but for my surprise it also has
a bug/problem...

if I try to use an Unicode string like "Cookie:josén...@somesite.com" with
DeleteUrlCacheEntryW, it fails to delete

but if I use DeleteUrlCacheEntryA with a ANSI string (naturally) then it
works...

So, because my app is Unicode, I had to manually assembled the string,
convert it to ANSI and use with DeleteUrlCacheEntryA to make this works...

Well, I will wait for you findings with WNDP...

Thanks

"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:ebjhex9O...@TK2MSFTNGP02.phx.gbl...

Volodymyr Shcherbyna

unread,

Dec 12, 2007, 2:12:00 AM12/12/07

to

Actually, in 90 % of cases UNICODE versions of wininet functions call ANSI
equivalents. Here is a related post to this topic:
http://msmvps.com/blogs/v_scherbina/archive/2006/07/07/Finally-Microsoft-implemented-InternetReadFileExW-function-_2E002E002E00_.aspx

--
Volodymyr
"HT" <ht...@yahoo.com> wrote in message

news:e8lEEKGP...@TK2MSFTNGP06.phx.gbl...

HT

unread,

Dec 12, 2007, 9:29:58 AM12/12/07

to

Hi Volodymyr,

So, this suggests that instead of waiting for MS, I should go ahead and use
my kludge that calls the ANSI version whenever DeleteUrlCacheEntryW fails...

Anyway, please, let me know if you ever heard from them or if you have a
better solution...

Many thanks!!!

"Volodymyr Shcherbyna" <v_sch...@online.mvps.org> wrote in message

news:uc79L5IP...@TK2MSFTNGP04.phx.gbl...

Volodymyr Shcherbyna

unread,

Dec 12, 2007, 10:06:16 AM12/12/07

to

I suggest you to wait for official response.

Both functions (FindFirstUrlCacheEntryW / FindNextUrlCacheEntryW) has its
own implementations, I mean they are not just delegating to ANSI
equivalents. This of course is logical, because the data might be lost. If
you will be able to reproduce the issue with the code, i.e. create a small
application that set's the cookie, and then retrieves it with losted
character - it will be great.

--
Volodymyr
"HT" <ht...@yahoo.com> wrote in message

news:eApWDuMP...@TK2MSFTNGP02.phx.gbl...