When I update my system with a new NK.bin file, I want to keep same language configuration I had before.
A suggestion was made that I read the information from the registry, then copy my new NK.bin file, replacing the current NK.bin (yes, you can do this while windows is running using that NK.bin file).
When this is done I write the values back to the registry.
My understanding is that this will affect the NK.bin after restart. This mean that the system shouldn't notice here that it is a new NK.bin file during restart.
And it works fine, the registry changes its value. HOWEVER, when I'm doing the update, it ends with a restart of the system.
When I login after that restart, the regsitry is changed to correct/loaded value, but it shows wrong language. Then after another restart the language is correct.
I want to handle this directly, making the system start with correct language from the start.
The code below shows last step of my update before restart. The new NK.bin file is just copyied and replaced the old one.
Should also say that following register is changed but wont take effect until the second restart:
cSysLang = #"MUI";
cDefaultLCID = #"nls";
cTouchCalibrationData = #"HARDWARE\DEVICEMAP\TOUCH";
cKeyboardDefaultSubKeyStr = #"keyboard layout\Preload";
cLangSubKeyStrCurrUsr = #"MUI";
cLangSubKeyStr = #"nls\overrides";
private void LoadDataAfterInstallation()
{
//langauge
Microsoft.Win32.RegistryKey regLanguage = Microsoft.Win32.Registry.CurrentUser.OpenSubKey(cLangSubKeyStrCurrUsr, true);
if (!(languageRegInfo==0))
regLanguage.SetValue("CurLang", languageRegInfo);
First let's discuss how a persistent registry works. I'm going to assume this is a newer device and it's using a hive-based registry (there was an older mechanism for persistence that worked in a completely different manner, but I've not seen much of it since the 4.x days).
The device has a baseline registry hive that the OS loads up when it's first booted (system.hv). It then applies your changes (user.hv) to that baseline registry. Now before either of these is loaded, the OS should be doing a checksum of the NK.BIN, and if it's different, it should toss out both and recreate them. A registry from an old OS is not guaranteed to be valid for a new OS, and for sanity's sake they should never be used.
So the order should be something like this:
Read registry
Update NK.BIN
Restart
OS deletes the old registry
OS loads the default language in the default registry
Write your registry values for the new language
Restart
OS loads new registry changes
OS loads new language
This, I think is where you are, yes?
The second restart is necessary for the OS to be able to see the registry changes you made. You may be able to avoid the second restart (I'm not sure - it's been years since I tested this and don't recall) by broadcasting a WM_SETTINGS_CHANGE after restoring the value. As a definitive resource, look at the Control Panel source code to see what it's doing when the user changes the OS language with the UI.
If you are using MUI I think you can't avoid the restart. Some settings may be refreshed dinamically, but language isn't. But you can programmatically restart your device as soon as you re-imported the registry. Isn't that an option? You can include a key in the reg inside the image and change it when boot is completed. If you have the image value it means that the registry need to be restored. You restore it, setting the new value, and then automatically restart the machine. This should be a minor inconvenience for your users.
Related
I have 2 instances of Odoo v9 running in the same server (Ubuntu 14.04). I want to make changes (install modules, change source code or anything) in the developement instance and after confirming they are OK, move the changes to the Production Instance. Is there anyway of doing that without repeating the whole process of development?
Thank you.
As I can understand you do not want to stop the production instance.
If they are only XML files you might be able to get away by only updating the module from the frontend (Apps-> Your Module -> Update. Although if you have modified the __openerp__.py file inside your module you have to enter the debug mode and click Update Apps List first of all.
For changes in files that are inside the static folder of your module, you do not need to stop the server. Although, your users must click ctr + shift + R in order to flush their caches and bring to their browsers the new content.
For Python source code I am afraid that you have to stop both instances of the server so that the code can be correctly recompiled.
(See note 1 on this)
In the end you should stop and update everything because unexpected things might pop up at random times due to resources not been properly updated.
Note 1: The Python documentation about the compilation of Python modules above others mentions:
As an important speed-up of the start-up time for short programs that
use a lot of standard modules, if a file called spam.pyc exists in the
directory where spam.py is found, this is assumed to contain an
already-“byte-compiled” version of the module spam. The modification
time of the version of spam.py used to create spam.pyc is recorded in
spam.pyc, and the .pyc file is ignored if these don’t match.
So theoretically if you modify fileA.py in a module and a new fileA.pyc is generated the server will be able to interpret and use it. In any case I had an issue with two instances running where the py file was creating the field and the XML file was using it and the server reported that a filed had not been created for the XML view, that means that the server did pick up and parse the XML file but did not recompile the py.
We have some hyper-v server images that if possible we would like to not rebuild. However the original machine they were installed on is no longer available.
So we have 1 vhdx and 8 avhdx. The vhdx is the virtual disk and the avhdx are check points if I remember correctly.
The process I used to build these machines was such as base install...checkpoint..install SQL Server...checkpoint...install visual studio...checkpoint etc...
I created a new vm on my windows 8 box and in the create wizard I told it to use an existing vhdx then pointed to my previous one.
The system boots and takes the correct password. However it comes up at the base install point. The checkpoints do not show in Hyper-V manager and consequently they do not get applied to the VM.
Now I have found that there is a sort of checkpoint database (xml) and several related folders in
C:\ProgramData\Microsoft\Windows\Hyper-V
thinking maybe there are some pointers I could realign but it seems editing them is not supported.
I also tried under the settings option of the test vm to change the checkpoint location. That seems to be a place for checkpoints to be stored and it doesn't seem to pick them up if any exist........this behavior makes sense as the pointer xml / database thingy is where that information should come from.
So is there a way to get these checkpoints associated / recreate / make use of these existing hyper v machines?
Thank You
I am trying to get this IndexedDB stuff working in a Metro (Windows 8) app, using JS.
I thought I was good, but then I ran the WACK tool a couple of times, just to see if I ran into any issues.
After these tests the IndexedDB.open call no longer opens my database (which has 7 entries in it) instead it fires onupgradeneeded, and gives me a blank (new) database (since I create an object store in the onupgradeneeded handler).
I did not change my version number, I did not change the database name. So I am guessing the applications domain somehow changed during the WACK tests.
Does anyone now how to get my database domain back?
One of the things the WACK test probably does is doing a fresh install of the app checking if everything goes fine. So when the app is installed for the first time you have to provide a creation of the database, this is done in the onupgradeneeded event.
I think you forgot to provide this, and that is why he creates a new blank database. Instead of a new database with the required structure.
When creating Metro applications in XAML/C#, how do I detect when the application is first installed or run for the first time since installation (or potentially upgrade)? I need to use this opportunity to ensure that my database schema is correct and potentially synchronise some base data.
I had hoped that I could pick this up from the LaunchActivatedEventArgs within the OnLaunched method, but there does not seem to be a valid value for the Kind or PreviousExecutionState that I can use.
Thanks.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.localsettings.aspx#Y0
When your app starts, write a setting called "AppHasBeenStarted" or something to LocalSettings. If the setting has not already been written, you know your app hasn't been started before. And you could improve on this, by making it "AppVersion", and writing the app's version. This way your app can detect upgrades by comparing the stored version with its own version.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions