I am trying to silently apply very specific appearance settings for a single user with poor eyesight on an XP machine.
I can alter the settings by using the appearance tab of the display settings dialog and clicking apply/ok. Doing this works however the user cannot see well enough to change her settings back to how she likes them each time she logs on.
Just changing the registry keys does not make the desired changes until the user logs off and then on again. For reasons that would take too long to explain, I cannot simply get the user to log off and then on again. I need the settings to be applied immediately upon login.
So! I either need to force windows to apply the display settings, a process which seems to be associated with the 'Please Wait' dialog, screenshot included OR I need to programmatically change the appearance settings individually (which includes altering 'Advanced' font-size settings).
Many thanks.
Please Wait Example http://www.dur.ac.uk/alexander.holmes2/b/pleasewait.jpg
Does this user have his/her own windows User? (his/her own account on XP). It should keep settings for you if you have them as a separate user from whoever else likes the larger DPI. Just create a user.
Related
as the title indicates I need help with the on-screen keyboard properties.
I have to configure a script, which I will deploy through SCCM in 30 terminals, and I need to make the keyboard go on screen as soon as I start the pc.
I have already solved this by adding this key to the registry
HKLM\Software\Microsoft\Windows\CurrentVersion\Run Clavier_Visuel = "C:\Windows\System32\osk.exe"
The problem is that I can't find a place to set the parameters of the keyboard: Remove the X to close it, display the PAD number, set the language to French and make it fit the screen.
This can be done manually, but that's not the goal.
Another point is that different users will be logged into the computers, so I can't set the condition to single user, but it should be general for all.
If you can help me it would be great, since I have not found anything useful so far, a greeting!
I have made a program to change the mouse sensivity in the same way as you can do it with the Control Panel.
The changes are made in the registry, the keys at HKEY_CURRENT_USER\Control Panel\Mouse and they are in fact done (I have checked them from regedit.exe) but the mouse works as if this changes are not made. In other words, the changes do not take any effect, they only do if you use the control panel. Why do they not take effect?
Windows registry isn't something that is refreshed all the time. The changes you made will be applied after the current user (that's why it's HKEY_CURRENT_USER) logs in again, or as you said after using control panel, which will read the registry. I don't know, what language your program is written in, but you should check out this link: "https://msdn.microsoft.com/en-us/library/ms724947.aspx"
In general, tweaking registry settings directly is unsupported, especially when there's an API to tweak the setting. In this case, the API is SystemParametersInfo. In particular, you need to use the SPI_SETMOUSESPEED as the argument for the uiAction parameter.
In other words, the changes do not take any effect, they only do if you use the control panel. Why do they not take effect?
Because there's often a little more to it than setting the value in the registry. Often there is a notification that must be sent after changing the value in order to tell the all the other software on the machine to drop any cached values and replace them with the new value that's now in the registry. In many cases, the notification will be in the form of a broadcast message.
In the case of mouse driver settings, you probably need to use the SPIF_UPDATEINIFILE argument for the fWinIni parameter. You might also need to OR it with SPIF_SENDCHANGE to broadcast a WM_SETTINGCHANGE message, but I'm not sure about that.
I´m trying to make some changes(Wallpaper/Themes) on a windows7 enviroment, until now, I copied some files in to a directory with admin rights, so the "hard" part is over.
Trying to change the registryKey with a batch or with a Powershell file will work, as an Admin and as a normal-user.
The bad thing is, if I try to make the changes as an Admin, then the changes will be just for the adminSession. And I want to make the changes for the normalUser and every new user(with not admin rights).
I found that with a batch file, I can make some changes to my normalUser account:
HKCU:\Software\Micorsoft....\Themes\ and change the value CurrentTheme to my own Windows theme.
If I check my registry, I notice that the CurrentTheme value was accepted, and after a reboot stay so.
But Windows shows me the default theme... ¬¬
I tried to change "everything" to set my Theme as default, but nothing works..
Is there a way to make it works? Why windows is refusing to take the changes in the registry and always show me the default Theme?
Go to HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows
In the left pane, right click on Windows and click on New and Key. Type Personalization and press enter (if not already exists).
Create a New and String Value called ThemeFile and press Enter. Right click on ThemeFile and click on Modify. Type in the full path of the .theme file with file extension in "" (example: "C:\Users\UserName\AppData\Local\Microsoft\Windows\Themes\NewCustomTheme.theme") ; it will be default for new users.
Are the systems on a domain?
You should know that registry values stored within the Policies key and all the subkeys after that can be reset by domain group policy at any time. That is to say that if you make a change here and reboot or run gpupdate, you can expect the values to be erased.
If you really want to change the theme for all users, you should use Group Policy to apply the theme, as seen in this link. Group Policy Settings for Windows Personalization.. Look in the section under "Set a Specific Theme".
I've done this for clients a number of times. You can also set a specific theme as the default by logging on as the Default Profile and making changes. Keep in mind that this approach should be done when you build a system image to deploy to the environment.
I have the following problem: I've created scheduled jobs that are only containing calls to a cmd and have parameters that contain things like project name etc.
I know about the fact that you have to set it to "Run only when user is logged on" if you want to see the window (cmd in this case) and also have to uncheck "hidden".
Until a week or two ago that worked fine, the box was showing up. Now the exact same job does no longer show the dos box. I suspect a windows update but I couldn't find anything useful in the update history of the server.
Do you guys have any idea what it might be? I tried switching the settings between the two "run as" options, tried setting it to hidden, tried switching "configure for" around...
The jobs run ok most of the time, the output is generated in most cases but if things go wrong I want to see the shell and not have to pipe everything to a .txt :/
I tried looking on google etc for a solution but only found other problems or the "my tasks run hidden if I choose run whether user is logged on or not" solutions.
Any ideas or hints? Anything would be really appreciated!
As you use scheduler to automate running of some rutine task, what's the point of manually checking/controlling it's execution? It is sort of negates benefit of automation and should be done through some basic logging (you can built in in your task scripts or whatever it is) and even viewer where you can check whether your tasks was run successfully.
Why it is required to you to see this window? Are you really need it?
If you state that it used to work OK then check logs does your tasks run successfully all the tine but hidden from you or it's something else?
Try to re-create / create new task & check whether it is not run hidden with settings you use.
From your description your scheduled task indeed configured so that it should be visible, namely:
- It is scheduled under your current logon account.
- It is configured to Run only when user is logged on.
These 2 conditions required for task to be visible.
The Hidden checkbox in the Windows Task Scheduler has nothing to do with how the scheduled program is displayed (in fact, there are no display options for scheduled tasks like there are with shortcuts). The Hidden checkbox controls whether or not the task is displayed in the Task Scheduler. If you set check it, then Task Scheduler will not display it unless the View Hidden Tasks option in the View menu is selected. You should still see the program window when it runs even if it is checked.
You did not indicate what changes you had made to the task between the time it worked and when it stopped, but one change that would prevent the window from being shown is if you had changed the account that runs it to the SYSTEM account. That is a trick that people use to hide the window (which is not a good solution, especially since there are much safer options), so if you had changed that, then you would not see it.
(The OP may have already fixed this by now), but if anyone else has the same problem, check the user account. If the task is not too complicated, you could do as Mikhail suggested and re-create the task from scratch.
I have a question about my Mac program's preferences window. I have an application with a CoreData-based back end. My program includes a feature that allows users to switch out the database for a different one. I do not expect users to do this very often—perhaps once or twice a year.
Now, many of the options that users can tweak are stored in the database. These options need to be configured once every time that a new database is used, because they are specific to the database itself.
The Apple Human Interface Guidelines on Preferences state this:
As much as possible, ensure that users rarely need to reset
preferences. Ideally, preferences include settings that users might
want to change only once. If there are settings users might want to
change every time they open your app, or every time they perform a
certain task, don’t put these settings in preferences. Instead, you
could use a menu item or a control in a panel to gives user modeless
access to these settings.
My question is this: Are my database-level settings valid candidates for the preferences window? Does "once or twice a year" count as "rarely"? If not, are there any downsides to creating a second panel (with many panes that are controlled by an NSToolbar) that looks just like a preferences panel but is accessed from a different menu item ("Database Preferences" for example)?
I see database-level settings all the time under Preferences in various apps (1Password and MacJournal come to mind). Thus, Preferences often contains both database-level settings and "actual" preferences that go in a plist file. The former (the data-base level settings) is absolutely crucial, being the actual data. The latter (the plist file) isn't as important and losing this data shouldn't cause too much harm, as it's just simple settings the user can easily get back to manually.
On the other hand, I see nothing wrong with separating the two, especially if your app is a multi-window (document-based) app that can have many databases open at once.
But I do think it's simplest to just put it all into the Preferences. That's what you probably should do, unless you have a good reason to do otherwise.
To answer some of your questions directly:
Are my database-level settings valid candidates for the preferences window?
— Yeah, I think they are. And many apps (such as 1Password and MacJournal) do this too.
Does "once or twice a year" count as "rarely"?
— Yeah.
Are there any downsides to creating a second panel?
— If you have a good reason to separate the two, I see nothing wrong with it.
Just my two cents.