Timo Kreuzer wrote:
This is the code:
RtlFormatCurrentUserKeyPath(&CurrentUserKeyPath);
InitializeObjectAttributes(&ObjectAttributes,&CurrentUserKeyPath,OBJ_CASE_IN SENSITIVE,NULL,NULL);
Status = ZwOpenKey(&CurrentUserKeyHandle, KEY_READ, &ObjectAttributes);
And I always get Status == STATUS_OBJECT_NAME_NOT_FOUND
What makes you sure ZwOpenKey is failing, and not one of the functions above it? You should use error checking where nessesary.
Ged.
Murphy, Ged (Bolton) schrieb:
What makes you sure ZwOpenKey is failing, and not one of the functions above it? You should use error checking where nessesary.
Ged.
NT_SUCCESS(RtlFormatCurrentUserKeyPath(...)) is TRUE.
InitializeObjectAttributes is a macro, that cannot fail.
#define InitializeObjectAttributes(p,n,a,r,s) { \ (p)->Length = sizeof(OBJECT_ATTRIBUTES); \ (p)->RootDirectory = (r); \ (p)->Attributes = (a); \ (p)->ObjectName = (n); \ (p)->SecurityDescriptor = (s); \ (p)->SecurityQualityOfService = NULL; \ }
I'll try to find out what ObjectAttributes is initiliazed to, but trunk is crashing, when compiled with debug = 1.
Murphy, Ged (Bolton) wrote:
Timo Kreuzer wrote:
This is the code:
RtlFormatCurrentUserKeyPath(&CurrentUserKeyPath);
InitializeObjectAttributes(&ObjectAttributes,&CurrentUserKeyPath,OBJ_CASE_IN SENSITIVE,NULL,NULL);
Status = ZwOpenKey(&CurrentUserKeyHandle, KEY_READ, &ObjectAttributes);
And I always get Status == STATUS_OBJECT_NAME_NOT_FOUND
What makes you sure ZwOpenKey is failing, and not one of the functions above it? You should use error checking where nessesary.
That's why I told him to print out the value of &CurrentUserKeyPath. He seems to have ignored my email...
Best regards, Alex Ionescu
Hi we do not have SysColors key in ros reg and that reason it fail. he did igonre jimtablor. if it same guy I thinking of I told him we do not have reg key for SysColors and spi message to get and set. and SysColors is hard code into win32k
----- Original Message ----- From: "Alex Ionescu" ionucu@videotron.ca To: "ReactOS Development List" ros-dev@reactos.org Sent: Wednesday, August 02, 2006 5:39 PM Subject: Re: [ros-dev] Probelms with ZwOpenKey or RtlFormatCurrentUserKeyPath?
Murphy, Ged (Bolton) wrote:
Timo Kreuzer wrote:
This is the code:
RtlFormatCurrentUserKeyPath(&CurrentUserKeyPath);
InitializeObjectAttributes(&ObjectAttributes,&CurrentUserKeyPath,OBJ_CASE_IN
SENSITIVE,NULL,NULL);
Status = ZwOpenKey(&CurrentUserKeyHandle, KEY_READ,
&ObjectAttributes);
And I always get Status == STATUS_OBJECT_NAME_NOT_FOUND
What makes you sure ZwOpenKey is failing, and not one of the functions
above
it? You should use error checking where nessesary.
That's why I told him to print out the value of &CurrentUserKeyPath. He seems to have ignored my email...
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Magnus Olsen wrote:
Hi we do not have SysColors key in ros reg and that reason it fail. he did igonre jimtablor. if it same guy I thinking of I told him we do not have reg key for SysColors and spi message to get and set. and SysColors is hard code into win32k
I think you're missing the point and/or can't read source code. This has nothing to do with system colors or win32k. He can't open the current user key.
Best regards, Alex Ionescu
Murphy, Ged (Bolton) wrote:
Timo Kreuzer wrote:
This is the code:
RtlFormatCurrentUserKeyPath(&CurrentUserKeyPath);
InitializeObjectAttributes(&ObjectAttributes,&CurrentUserKeyPath,OBJ_CASE_IN SENSITIVE,NULL,NULL);
Status = ZwOpenKey(&CurrentUserKeyHandle, KEY_READ, &ObjectAttributes);
And I always get Status == STATUS_OBJECT_NAME_NOT_FOUND
What makes you sure ZwOpenKey is failing, and not one of the functions above it? You should use error checking where nessesary.
Ged.
I looked and we only have one entry, HKEY_CURRENT_USER\Control Panel\Colors\Background.
Wine does not see any of this with regedit. Testing regedit at work (2k & XP) shows all of these settings.
From wine source, static const char * const DefSysColors[] = { "Scrollbar", "192 192 192", /* COLOR_SCROLLBAR */ "Background", "0 128 128", /* COLOR_BACKGROUND */ "ActiveTitle", "0 0 128", /* COLOR_ACTIVECAPTION */ "InactiveTitle", "128 128 128", /* COLOR_INACTIVECAPTION */ "Menu", "192 192 192", /* COLOR_MENU */ "Window", "255 255 255", /* COLOR_WINDOW */ "WindowFrame", "0 0 0", /* COLOR_WINDOWFRAME */ "MenuText", "0 0 0", /* COLOR_MENUTEXT */ "WindowText", "0 0 0", /* COLOR_WINDOWTEXT */ "TitleText", "255 255 255", /* COLOR_CAPTIONTEXT */ "ActiveBorder", "192 192 192", /* COLOR_ACTIVEBORDER */ "InactiveBorder", "192 192 192", /* COLOR_INACTIVEBORDER */ "AppWorkSpace", "128 128 128", /* COLOR_APPWORKSPACE */ "Hilight", "0 0 128", /* COLOR_HIGHLIGHT */ "HilightText", "255 255 255", /* COLOR_HIGHLIGHTTEXT */ "ButtonFace", "192 192 192", /* COLOR_BTNFACE */ "ButtonShadow", "128 128 128", /* COLOR_BTNSHADOW */ "GrayText", "128 128 128", /* COLOR_GRAYTEXT */ "ButtonText", "0 0 0", /* COLOR_BTNTEXT */ "InactiveTitleText", "192 192 192", /* COLOR_INACTIVECAPTIONTEXT */ "ButtonHilight", "255 255 255", /* COLOR_BTNHIGHLIGHT */ "ButtonDkShadow", "0 0 0", /* COLOR_3DDKSHADOW */ "ButtonLight", "224 224 224", /* COLOR_3DLIGHT */ "InfoText", "0 0 0", /* COLOR_INFOTEXT */ "InfoWindow", "255 255 225", /* COLOR_INFOBK */ "ButtonAlternateFace", "180 180 180", /* COLOR_ALTERNATEBTNFACE */ "HotTrackingColor", "0 0 255", /* COLOR_HOTLIGHT */ "GradientActiveTitle", "16 132 208", /* COLOR_GRADIENTACTIVECAPTION */ "GradientInactiveTitle", "181 181 181", /* COLOR_GRADIENTINACTIVECAPTION * "MenuHilight", "0 0 0", /* COLOR_MENUHILIGHT */ "MenuBar", "192 192 192" /* COLOR_MENUBAR */ };
Ok, first thanks for all The replies. It has in fact nothing to do with the presence of the Keys. I have written the appearance page of the desk.cpl, it set's the colors and writes the correct values to HKLM\Control Panel\Colors (at least on WinXP)
I just couldn't open the CurrentUserkey. @Alex: I didn't ignore you, I answered to Ged's post, that I will try to find out as soon, as I get a debug-version running. But I have found the error already: I exidently called my function from a place where there's probably no user logged on. I changed this and try a different implementation with RtlQueryRegistryValues, wich is better here.
James Tabor schrieb:
Murphy, Ged (Bolton) wrote:
Timo Kreuzer wrote:
This is the code:
RtlFormatCurrentUserKeyPath(&CurrentUserKeyPath);
InitializeObjectAttributes(&ObjectAttributes,&CurrentUserKeyPath,OBJ_CASE_IN SENSITIVE,NULL,NULL);
Status = ZwOpenKey(&CurrentUserKeyHandle, KEY_READ, &ObjectAttributes);
And I always get Status == STATUS_OBJECT_NAME_NOT_FOUND
What makes you sure ZwOpenKey is failing, and not one of the functions above it? You should use error checking where nessesary.
Ged.
I looked and we only have one entry, HKEY_CURRENT_USER\Control Panel\Colors\Background.
Wine does not see any of this with regedit. Testing regedit at work (2k & XP) shows all of these settings.
From wine source, static const char * const DefSysColors[] =
Timo Kreuzer wrote:
Ok, first thanks for all The replies. It has in fact nothing to do with the presence of the Keys. I have written the appearance page of the desk.cpl, it set's the colors and writes the correct values to HKLM\Control Panel\Colors (at least on WinXP)
I just couldn't open the CurrentUserkey.
Yes, that's what I've been trying to tell the others. I guess they had a slow day and were lost watching TV or something.
@Alex: I didn't ignore you, I answered to Ged's post, that I will try to find out as soon, as I get a debug-version running. But I have found the error already: I exidently called my function from a place where there's probably no user logged on. I changed this and try a different implementation with RtlQueryRegistryValues, wich is better here.
That's exactly why you should've just done what I said. I was expecting this was the problem, and based on your print I could've told you the solution. Oh well, glad you got it working.
Best regards, Alex Ionescu
Timo Kreuzer wrote:
It has in fact nothing to do with the presence of the Keys. I have written the appearance page of the desk.cpl, it set's the colors and writes the correct values to HKLM\Control Panel\Colors (at least on WinXP)
You aren't using ZwOpenKey in a cpl are you?
Ged Murphy wrote:
Timo Kreuzer wrote:
It has in fact nothing to do with the presence of the Keys. I have written the appearance page of the desk.cpl, it set's the colors and writes the correct values to HKLM\Control Panel\Colors (at least on WinXP)
You aren't using ZwOpenKey in a cpl are you?
Course he isn't, his original problem was not being in a logged in account, which implies SYSTEM-context level application.
Best regards, Alex Ionescu
Alex Ionescu schrieb:
Ged Murphy wrote:
Timo Kreuzer wrote:
It has in fact nothing to do with the presence of the Keys. I have written the appearance page of the desk.cpl, it set's the colors and writes the correct values to HKLM\Control Panel\Colors (at least on WinXP)
You aren't using ZwOpenKey in a cpl are you?
Course he isn't, his original problem was not being in a logged in account, which implies SYSTEM-context level application.
In the cpl, I'm using RegOpenKey, of course, and that works. This code is for implementing reading SysColor from the registry in win32k.sys. I have now written a function IntSysColorsUpdatePerUserSettings inside win32k, wich is called just before IntDesktopUpdatePerUserSettings. (at this point the user is logged on). It now uses RtlQueryRegistryValues to query all the color values at once and call a Callback procedure for every entry. Don't know if it works, because trunk is always restarting at second level setup. and never logging on. I'm just recompiling lastest rev...