By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,264 Members | 1,743 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,264 IT Pros & Developers. It's quick & easy.

Finding Font File Name by FontName in Windows Vista

P: n/a
Hello friends

In c# 2005 I have written a function to access "font file name" by "Font
name" and it is working fine in all the windows version other than vista,

in vista it is throughing an error so please help me how can i access font
file name by font name in windows vista or what change i have to do in
following function to get the solution

my function source code is givin below -

private static string GetFontFileName(String FontName)
{
String subKey = "";
if (GetOSVer() 4)
{
subKey = @"SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Fonts";
}
else
{
subKey = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts" ;
}
return
GetRegisteryValue(Microsoft.Win32.RegistryHive.Loc alMachine, subKey,
FontName);
}

public static string GetRegisteryValue(RegistryHive registryHive, String
subKey, string valueName)
{
String returnValue = "";
Microsoft.Win32.RegistryKey registryKeyParent = null;
Microsoft.Win32.RegistryKey registryKeyChild = null;
switch (registryHive)
{
case Microsoft.Win32.RegistryHive.ClassesRoot:
registryKeyParent = Microsoft.Win32.Registry.ClassesRoot;
break;
case Microsoft.Win32.RegistryHive.CurrentConfig:
registryKeyParent =
Microsoft.Win32.Registry.CurrentConfig;
break;
case Microsoft.Win32.RegistryHive.CurrentUser:
registryKeyParent = Microsoft.Win32.Registry.CurrentUser;
break;
case Microsoft.Win32.RegistryHive.DynData:
registryKeyParent = Microsoft.Win32.Registry.DynData;
break;
case Microsoft.Win32.RegistryHive.LocalMachine:
registryKeyParent = Microsoft.Win32.Registry.LocalMachine;
break;
case Microsoft.Win32.RegistryHive.PerformanceData:
registryKeyParent =
Microsoft.Win32.Registry.PerformanceData;
break;
case Microsoft.Win32.RegistryHive.Users:
registryKeyParent = Microsoft.Win32.Registry.Users;
break;
}
registryKeyChild = registryKeyParent.OpenSubKey(subKey);
if (registryKeyChild != null)
{
object abc = registryKeyChild.GetValue(valueName);
returnValue = registryKeyChild.GetValue(valueName).ToString();
}
else
{
throw new Exception("Registery key not found");
}
return returnValue;

}
Feb 18 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hello BL,

Your implementation is obviously a hack that accesses internal Windows
system information directly, thereby relying on a specific layout of that
internal information. It seems understandable that such an approach could
break on a new version of Windows, that's why it's generally not
recommended to use such approaches. Your solution will incorporate either
rearchitecting your implementation, if possible, to find a compatible way
of doing the same thing - there may be some API you could use, for
instance - or finding out the details that make the hack work on Vista, too.

Glancing over your code, I can't really say what your problem is - the
registry location looks correct. You don't explain what the error is that
you're getting, which would of course be the basic information we'd need.
My personal guess is that you're trying to access the registry with full
permissions, and you're getting some sort of "access denied" error. Try
accessing the registry read-only, that should work for your purpose. But
without further information, of course I can't be sure there's nothing
else going wrong.
Oliver Sturm
--
http://www.sturmnet.org/blog
Feb 18 '07 #2

P: n/a
Thanks for reply

yes, the error is access denied in the case of restricted user, admin user
can easly access the registery

so if you have any idea about access registry in read only mode or is there
any API to access the font file name by font name please let me know

it will will a great help to me.

Thanks again

BL
"Oliver Sturm" wrote:
Hello BL,

Your implementation is obviously a hack that accesses internal Windows
system information directly, thereby relying on a specific layout of that
internal information. It seems understandable that such an approach could
break on a new version of Windows, that's why it's generally not
recommended to use such approaches. Your solution will incorporate either
rearchitecting your implementation, if possible, to find a compatible way
of doing the same thing - there may be some API you could use, for
instance - or finding out the details that make the hack work on Vista, too.

Glancing over your code, I can't really say what your problem is - the
registry location looks correct. You don't explain what the error is that
you're getting, which would of course be the basic information we'd need.
My personal guess is that you're trying to access the registry with full
permissions, and you're getting some sort of "access denied" error. Try
accessing the registry read-only, that should work for your purpose. But
without further information, of course I can't be sure there's nothing
else going wrong.
Oliver Sturm
--
http://www.sturmnet.org/blog
Feb 19 '07 #3

P: n/a
Hello BL,
>yes, the error is access denied in the case of restricted user, admin user
can easly access the registery

so if you have any idea about access registry in read only mode or is there
any API to access the font file name by font name please let me know

it will will a great help to me.
Hm. Now I found something interesting. I looked at pages in MSDN to find
how that read-only access worked again - I was sure I'd done it in the
past, but I wanted to refresh my memory - and suddenly I found that
read-only access is actually the default using the .NET registry API.

So I went ahead and copied your code from your original post and created
my own sample program to try things out - and the sample worked! I tried
it both with Administrator privileges (when running from VS on Vista) and
without (running as a "normal" user on Vista) and in both cases it worked
just fine.

So obviously this doesn't really solve your problem after all, as the
issue is not reproducible for me. Sorry... at least we've found that you
have a permission issue, now we just need to find the source of that...

Question: what about that user you're using? Working as that user, can you
run regedit and access the information manually?
Oliver Sturm
--
http://www.sturmnet.org/blog
Feb 19 '07 #4

P: n/a
Hello Oliver

thanks for being with me

did you tested it in ASP.net 2.0 ?

in windows application it is working fine here.

BL

The follwoing the complete function

private static string GetFontFileName(String FontName)
{
String subKey = "";
if (GetOSVer() 4)
{
subKey = @"SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Fonts";
}
else
{
subKey = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts" ;
}
return
GetRegisteryValue(Microsoft.Win32.RegistryHive.Loc alMachine, subKey,
FontName);
}
public static string GetRegisteryValue(RegistryHive registryHive,
String subKey, string valueName)
{
String returnValue = "";
Microsoft.Win32.RegistryKey registryKeyParent = null;
Microsoft.Win32.RegistryKey registryKeyChild = null;
switch (registryHive)
{
case Microsoft.Win32.RegistryHive.ClassesRoot:
registryKeyParent = Microsoft.Win32.Registry.ClassesRoot;
break;
case Microsoft.Win32.RegistryHive.CurrentConfig:
registryKeyParent =
Microsoft.Win32.Registry.CurrentConfig;
break;
case Microsoft.Win32.RegistryHive.CurrentUser:
registryKeyParent = Microsoft.Win32.Registry.CurrentUser;
break;
case Microsoft.Win32.RegistryHive.DynData:
registryKeyParent = Microsoft.Win32.Registry.DynData;
break;
case Microsoft.Win32.RegistryHive.LocalMachine:
registryKeyParent = Microsoft.Win32.Registry.LocalMachine;
break;
case Microsoft.Win32.RegistryHive.PerformanceData:
registryKeyParent =
Microsoft.Win32.Registry.PerformanceData;
break;
case Microsoft.Win32.RegistryHive.Users:
registryKeyParent = Microsoft.Win32.Registry.Users;
break;
}
registryKeyChild = registryKeyParent.OpenSubKey(subKey);
if (registryKeyChild != null)
{
object abc = registryKeyChild.GetValue(valueName);
returnValue = registryKeyChild.GetValue(valueName).ToString();
}
else
{
throw new Exception("Registery key not found");
}
return returnValue;

}
"Oliver Sturm" wrote:
Hello BL,
yes, the error is access denied in the case of restricted user, admin user
can easly access the registery

so if you have any idea about access registry in read only mode or is there
any API to access the font file name by font name please let me know

it will will a great help to me.

Hm. Now I found something interesting. I looked at pages in MSDN to find
how that read-only access worked again - I was sure I'd done it in the
past, but I wanted to refresh my memory - and suddenly I found that
read-only access is actually the default using the .NET registry API.

So I went ahead and copied your code from your original post and created
my own sample program to try things out - and the sample worked! I tried
it both with Administrator privileges (when running from VS on Vista) and
without (running as a "normal" user on Vista) and in both cases it worked
just fine.

So obviously this doesn't really solve your problem after all, as the
issue is not reproducible for me. Sorry... at least we've found that you
have a permission issue, now we just need to find the source of that...

Question: what about that user you're using? Working as that user, can you
run regedit and access the information manually?
Oliver Sturm
--
http://www.sturmnet.org/blog
Feb 19 '07 #5

P: n/a
Hello BL,
>thanks for being with me

did you tested it in ASP.net 2.0 ?
No - didn't cross my mind :-)

I'm sure that can be the problem, but I'm no expert in ASP.NET. I know
that a lot of things have changed in ASP.NET 2 with regard to code access
security, and I found a summary here:
http://msdn2.microsoft.com/en-us/library/ms998326.aspx
This also includes instructions for measuring one's needed permission set,
so I guess you should be able to find the problem if you follow these
instructions for your application.
Oliver Sturm
--
http://www.sturmnet.org/blog
Feb 19 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.