Is there a registry setting in the windows XP Operating system where i can change the setting so that whenever i launch my application it always sits on the secondary monitor??
Ultramon has a feature to tell certain application to open on a desired monitor/position.
Related
I'm working on an application in vscode whose behavior is impacted by the settings of a handful of specific environment variables (the three "proxy" variables). I'm doing this on an Ubuntu VM.
At one point I realized that I had to change the settings (clear them) in order for my application to work. I know that it can be challenging to change env vars in subprocesses, so I decided to keep it simple and simply restart the entire VM after I changed my .profile. After the restart, I checked a shell window and the vars were set as I wanted (not set). I then started up vscode from my Ubuntu favorites bar. In the terminal window I printed the values of those vars. They still had the values I set before. I verified that when I ran the application from vscode (not from the terminal window in vscode), it behaved badly, so it was using the old values. In the terminal window, I then manually cleared those variables to put them into the correct state. I manually ran the service from the terminal window, and it did what it was supposed so, reflecting the cleared variables.
It appears that vscode is storing environment settings on disk and never getting them from the parent shell again.
How do I control this behavior?
How can I change in setting to not automatically start my VS Code after restarting my machine?
I've tried searching in settings but could not find this setting.
Thanks
I think this may be connected with your operating system, not the application itself. Try googling "insert-your-operating-system-here startup applications".
On just one of my two Linux systems, Visual Studio Code always starts in a maximized window. It doesn't do it on the other one. Both systems are Pop!_OS 20.10, upgraded along the way from each Pop!_OS release from 18.04. VSCode is 1.51.1, and has been doing this since I started using it about 1.36 or so. I'm using the default Gnome Shell on each system. On the system where it doesn't start maximized, it remembers its previous size and placement. If I double-click on the window header on the failing system, it returns to its prior placement and size, but if I close it in that state, when I reopen it it's maximized again.
I'm guessing there's a settings file or something that's set to force it to be maximized, but I didn't explicitly set anything like that, and I wasn't able to find anything when searching that would have that effect.
The failing system is one I built up with a Ryzen 9 3900X, 64 GB RAM, 1 TB M.2 PCIe 4 SSD, and an RTX 2060. The working system is a System76 Oryx Pro v4 with 64 GB and an 8th gen Core i7. VSCode has done this on the failing system ever since I was running it on a dual-hex Mac Pro, and on a 1080p monitor; I'm now using a 3840x2160 monitor - but that's what the Oryx Pro has on it, too.
What am I missing?
Following works on ubuntu 20.10. Position VSCode window where you would like it to open next time. Then, hit <Ctrl><CloseXButton>
This will close your current session. Next time you open this project via code ., you should get VSCode to open in that last state you <Ctrl>-closed it in.
I don't know where this status is stored in the settings file.
I have this problem going on for few days, every time I open my laptop it starts Windows Powershell automatically.It's not causing me any problem as I close it once it opens, but I am quite annoyed by it and wants to know if this is some problem or just something went bad with my settings. I am using windows 10 pro.
There is probably an autorun entry for Powershell registered on your system. Without more information, it's not possible to tell how it got there.
Programs registering themselves to start up on boot is a common symptom of malware infection, but most malware would also try to hide any visual cues, i.e. the Powershell window would be hidden.
To troubleshoot further, you can try the free utility Autoruns available from Microsoft. Look for any entries related to Powershell.
I have a Windows Universal App that needs to be sideloaded. I am using NSIS with a powershell script to install it. I would like to have the NSIS installer enable app sideloading in the Windows settings. I have already looked at the documentation from Microsoft about enabling app sideloading (https://msdn.microsoft.com/library/windows/apps/xaml/dn706236.aspx).
If I run the powershell command from the documentation to set the registry in a standalone powershell window it works fine and I can install the app. However, when I put the registry command inside the installer it doesn't work. I have tried using both Powershell and NSIS to set the registry. Using the WriteRegDWORD command from NSIS and the reg add command from Powershell both say that they succeeded. Reading back the values produces the correct value. If I try to set the registry using Set-ItemProperty in the Powershell script it complains that the path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock doesn't exist.
There doesn't seem to be any way to tell whether sideloading is enabled or not from Powershell. Even outside of the installer context checking the registry is not a valid solution because enabling sideloading via Windows Settings doesn't set the registry.
So my current solution is to try to install the app. If the install fails, check the error message and see if it's complaining about sideloading not being enabled. If that is the case then open up Windows Settings to the developer features page and pop up a message saying that sideloading needs to be enabled in order to continue. Then after Windows Settings is closed reattempt to install the app.
Is it possible to enable sideloading from an NSIS installer? Or is it possible to do a check to see if sideloading is enabled or not?
64-bit versions of Windows have a 64-bit and a 32-bit "version" of the registry, this means that what you see in Regedit might not be the same as what a 32-bit application sees.
Use the SetRegView instruction to change the view used by the installer.
Process Monitor is a useful tool to debug registry issues like this...