I have two monitors. My laptop (monitor #1) and an HDMI monitor (monitor #2). Postman will only open on #1 forcing me to drag it to monitor #2 for use. Is there any way to force Postman to always open on monitor #2. (And the windows key + alt + enter doesn't work for me.)
I think it's opening on the main monitor. You could use e.g. DisplayFusion to memorize the window location.
https://www.displayfusion.com/ works for me. If it's a corporate laptop then use
Windows key + Shift + Enter
Using the latest version of Windows 10, I have found that Postman consistently opens on the display I last had it open on. Simply backing up and reinstalling Postman could fix this, or forcing a windows update if you're on an older version.
If not a solution such as PowerToys' FancyZones or DisplayFusion could work for you, although I have no experience either of these so I couldn't say for sure if they would work.
I think you can try following below steps:
Open the program.
Move it to the monitor on which you would like it to open by default.
Hit the Windows key + Shift + Enter
And now, it will be open each time on the monitor of your preference.
Related
I don't want to find some disabling of gatekeeper where I just turn it off completely.
However, I use SQLiteStudio probably more often than majority of the applications on my computer, but every single time I open it (which I try to avoid and just keep it open constantly) it requires that I go into Security & Privacy and hit "Open Anyways" to force it to open since it's apparently from an unidentified developer...
Anyways, I'm hoping there's some fix or something I can do to permanently disable the warning for this particular application only?
Most other applications when I download them and open them and they have that issue it only occurs the single first time I open it - and then when I hit "Open Anyways" it disables the warning from then on. But this application is the exception and I'm really hoping for a solution. Any help???
Im trying very hard to like virtualbox, but so far I find it so much worse than vmplayer in so many ways. If it wouldnt take me hours to install everything back into vmplayer i would have moved back days ago
When I open my ubuntu vm my host OS's (windows 10) toolbar is still visible at the bottom of the screen, cutting off the actual virtualbox toolbar
Please help me
(edit) It is in fullscreen mode already, it just still shows the toolbar/taskbar from the host OS
Open Task Manager of Windows 10, Select "Windows Explorer" and Restart.
Reference Link
I had this same issue. The Windows 10 taskbar was still showing when I had VirtualBox in fullscreen mode, and what caused it for me was I had a program called Rufus (for creating bootable USBs) open and it was keeping the taskbar from hiding. Once I closed Rufus, everything worked as it should. So, maybe you had a program keeping focus on the taskbar, something that needed attention, and wouldn't let the taskbar hide.
I ran into the problem once. Not sure what had caused the that but I managed to find a solution by enabling "task bar" hiding option in host windows 10 machine.
Right Click on Task Bar -> Task Bar Setting -> Enable Task Bar hiding Option.
You are able to switch to fullscreen mode on the VM, this should hide the Host OS.
This image shows you where you can find the option:
If this is not what you are looking for, please elaborate on your problem, maybe add a screenshot showing the problem you are having.
I just experienced this exact problem, namely Windows 10 host taskbar would not go away despite the guest being in full screen. Even though this question is old, since this question got the top google page rank, I thought I would share how I fixed it.
I fixed it by shutting down Virtualbox and then rebooting the Windows 10 host. It is possible as others have pointed out that some app was keeping the taskbar active, but I couldn't find any such app. If it was some rogue app that was just running as a process (with no taskbar presence), the reboot nuked it from orbit and fixed the problem.
After installation virtualbox tools You can press
host + F (in my case Ctrl + F)
buttons to run fullscreen in virtualbox.
I have a remote desktop and i'm trying to run a simple script to prevent idle session timeout, which is 3 min (quite annoying). The script should, for example, press "A" key every 2.5 min or so.
Problem is, the remote desktop window is often inactive/minimized and:
1) if i try to run such a script "inside" the remote desktop, i still get disconnected, despite it actually works (continues to type or create/delete files etc even as the "idle timer expired" message is on screen). i believe the system wants some "external" action.
2) if i run the script on my PC, it doesn'do anything at all on the remote desktop (i had an open notebook there, and there was no typing):
ControlSend("[CLASS:TscShellContainerClass]", "", "[CLASS:OPContainerClass; INSTANCE:1]", "{A}")
I think the problem lies with the "controlid" part, which i got via autoit window info. If i set controlid as "" - it works, but only if the window is currently active.
I've seen a registry key solution, but doesn't seem to work for me.
If anyone has any ideas about fixing this, please, don't hold back:)
I know it's late but here's the ONLY thing I could get to work; it involved activating the window. I tried ControlFocus but to no avail, so here's what I got.
You should be able to modify your script as needed.
#include<Array.au3>
OPT("WinTitleMatchMode",2)
$a = WinList("Remote Desktop Connection")
;_ArrayDisplay($A)
ConsoleWrite(UBound($A)& #CRLF)
FOR $N = 1 to $A[0][0]
$hActiveWindow = WinGetHandle("")
WinActivate($a[$N][1]) ;comment if using controlfocus
;ControlFocus($a[$N][1],"","") ;comment if using winactivate
ControlSend($a[$N][1],"","","^+{ESC}")
WinActivate($hActiveWindow)
Next
So I keep getting this error when trying to compile C++ code using CodeBlocks.
cannot open output file [filename.exe] permission denied
It only started today, and it's sporadic and inconsistent. It usually goes away if I shut CodeBlocks down and restart the project, but not always. Sometimes it even goes away when I just press F9 (build & run) several times. I always check Task Manager, but there are never any .EXEs running with my file's name, or anything related to it.
I've also noticed that if this problem occurs and I then try to delete the .EXE manually or otherwise interact with it, Windows tells me I need administrator permission to do so (this is a private PC, and as far as I know I am an administrator on it).
The first time it occurred, the only thing I had added to the code beyond what was in the previous version was a debugging report sent to cout - hardly anything arcane. It sometimes occurs even when no code was changed from a previous version.
What could this be? It's not game-breaking, yet, but it's irritating and I'd rather it didn't get worse.
EDIT: This is old by now, but just in case anyone else is having similar problems, the workaround I currently use is just to consistently delete [filename.exe] before trying to run the code again. This avoids the problem, though it is annoying.
check that "filename.exe" is not running, I guess you are using Microsoft Windows, in that case you can use either Task Manager or Process Explorer : http://technet.microsoft.com/en-us/sysinternals/bb896653 to kill "filename.exe" before trying to generate it.
I have encountered the same problem you have. I found that it may have some relationship with the way you terminate your run result. When you run your code, whether it has a printout, the debugger will call the console which print a "Press any key to continue...". If you terminate the console by pressing key, it's ok; if you do it by click the close button, the problem comes as you described. When you terminate it in the latter way, you have to wait several minutes before you can rebuild your code.
I just had the same issue. And i experienced that it always happens when i run the programm and change some code without finishing the programm still running. After that the "cannot open ..." message appears.
However i got rid of it by clicking the "Terminate" button at the very top-right side of the console window (red button) and after that "remove all terminated launches" (two x'es right next to the terminate button).
This seems to close the running programm and everything works fine after :) hope this may help anyone
I was having the same problem too and it was driving me crazy:
Windows7 64 bit, MinGW, Eclipse, CDT
Permission denied errors, executable disappearing, ld.exe errors. It would work once, but never again.
Statements like: "cannot open output file ***.exe: Permission denied"
Check your ANTIVIRUS Software. Once I turned off my Antivirus software in workspace then cleaned the workspace and started the project over again I never had the problem again.
This error usually occurs when the IDE has a problem due to a crash or other failure and it still has a hold on the EXE, preventing the user (yourself) from overwriting / deleting the EXE during a rebuild.
Hello I realize this post is old, but here is my opinion anyway.
This error arises when you close the console output window using the close icon instead of pressing "any key to continue"
The problem is related to Sam´s response:
"have encountered the same problem you have. I found that it may have
some relationship with the way you terminate your run result. When you
run your code, whether it has a printout, the debugger will call the
console which print a "Press any key to continue...". If you terminate
the console by pressing key, it's ok; if you do it by click the close
button, the problem comes as you described. When you terminate it in
the latter way, you have to wait several minutes before you can
rebuild your code."
Avoid kill processes, and we have two choices, wait until the process release the .EXE file or this problem will be solved faster restarting the IDE.
You can use process explorer from sysinternals to find which process has a file open.
Try restarting your IDE. It worked for me.
Although I tried to end the process in the task manager, the process never got killed.
I re-installed C::B in drive D, whereas my program files folder is in drive C
I don't know the reason , but it works :)
well,once i had the same problem and after tracking down the process that was getting the file in use i discovered that it was the anti-virus (PANDA) ...i just unlocked the file and simply worked out ....well for my experience i used Unlock 1.9.2 ...try iy out ..
A major cause of this (which I had recently), is if you have this on for example a flash drive.
You can develop and do everything, but on most systems it stops you from running the .exe file from there, whether it be the debug or release version.
In my case - I found a process called
cb_console_runner
I stopped this process and things were ok again.
I had the same Problem. Just rename your .CPP file to other name and try it again.
It worked for me.
FOR LINUX OS...
go to file where u r created file.then usually
......project_name/bin/Debug/project_name.executable here for this executable file you wont be having execute permission then the execute permission.Either by right click if you are unable to change permission then use use open terminal(command promt) to change permission.
first go to that executable file using 'cd' command then use "chmod u+x" then permission is going to change.then go to c::b open and execute you will get output.
only thing for all file u need to do it.
The problem is that you don't have the administrator rights to access it as running or compilation of something is being done in the basic C drive. To eliminate this problem, run the devcpp.exe as an administrator. You could also change the permission from properties and allowing access read write modify etc for the system and by the system.
Make sure to run 7zip in 'Administrator mode' for extracting to Program Files.
Also, temporarily turning off virus protection worked for some people in the past.
I tried what #willll said, and it worked. I didint find exactly the .exe named after my project, but I did kill some weird looking tasks (after checking on the internet they were not critical), and it worked.
I have tried and get output after end task IDE from task manager. Later clean all temporary files from your drive. Start your IDE. Now your .exe working good.
Sometimes a network drive that is already mapped to a drive letter because "disconnected". Using the normal Windows functions to access files / folders on that drive fail. As soon as the user manually clicks on that drive it the Windows Explorer dialog, it's magically repaired.
Since my program is a batch program I'd like to start this "magic" from my program (C++) but I haven't found a Windows function for that. There's nothing in the usual WNet... functions...
NET USE V: /DELETE
NET USE V: "\\server1\videos"
NET USE L: /DELETE
NET USE L: "\\server2\archive"
When the path is inserted, you could check to see if it is a network resource and before opening files, use WNetGetConnection() to get the network resource.
You could also try to use WNetRestoreConnectionW(), which seems to have more spurious support, depending on the environment.
Try re-connecting to the share via net use:
net use \\server\folder [/user:[domain\]username] [password]
If that doesn't work, you can net use /delete it first, then re-connect.
Isn't this what WNetAddConnection and WNetAddConnection2 are for?
I suspect that is really the same thing, though. Explorer probably caches the connection info somewhere in the registry. When the user tries to go to that drive Explorer sees that the mapping is disconnected, reads the connection info from the registry, and re-creates the connection. Maybe you could try running regmon while you create a drive mapping and see if you can figure out where and how the connection information is cached.
I had trouble with this at a client of mine not long ago. I don't know if it's possible in your situation, but our fix was to tweak the Server's network settings to stop the timeouts and disconnects. See MSKB 297684 for details.
I agree with the comment from CMB, above. I've been down this path (excuse the pun) in the past and it caused me no end of trouble.
If the path is user configurable, they could use m:\pathonserver or they could use \server\c\pathonserver.
It shouldn't make any difference to your code, opening a file as m:\blahdeblah.dat or \server\c\blahdeblah.dat will be identical.
Using the UNC path is far more reliable, Windows will reconnect to that path automatically whether or not the mapped letter is there.
If you map a drive to a network
share, the mapped drive may be disconnected after a regular interval
of inactivity, and Windows Explorer may display a red "X" on the icon
of the mapped drive. However, if you try to access or browse the
mapped drive, it reconnects quickly.
To avoid this behavior use the following command:
net config server /autodisconnect:-1
Explanation of Microsoft on this topic:
https://support.microsoft.com/da-dk/help/297684/mapped-drive-connection-to-network-share-may-be-lost