While I realize this is an older version of Firefox, the system I'm using it on is around 11 years old and it can't take newer versions without the browser and flash content getting sluggish and choppy. This system serves as a public access station and recently I've had someone try to bypass my internet content filters to access material they're not supposed to and they reset Firefox as part of that attempt.
Is truly disabling safe mode possible and if so, how do I easily do this?
If not, I've also read from here...
Disable/Change Firefox Safe Mode Hotkey (Shift)
that disabling the safe mode hot key (Shift key) is possible. At the very bottom, there is a environmental variable that can be used to do this: MOZ_DISABLE_SAFE_MODE_KEY=1. How and where do I insert this variable?
Thank you in advance for your time. :-)
Regards...
Probably too late to help, but maybe this will be of use to fellow Googlers. This blog explains how to disable safe mode in firefox 17, so it may apply to 12 as well:
https://mike.kaply.com/2013/01/11/disabling-safe-mode-in-firefox-17/
If that doesn't help, the regarding the environment variable, that's done from control panel > system > advanced system settings > "advanced" tab > environment variables. You can put the variable in the upper box if you want it to apply to the current user only, or the lower box if you want it to apply to the whole system.
I use Paraview (3.98) to display results from FEM simulations. The Properties detachable window accomodates some settings under Display (UnstructuredGridRepresentation), which creates GUI entries for "Opacity Table Values" and "Radius Table Values", which are very large and make the other settings go beyond the edge of the window. AFAIR it was not an issue in orevious version os Paraview. Is there a way to make the GUI less wide again?
I had a tough time overcoming this problem too, the solution for paraview 3.98 is to use the option --use-old-panels.
Or you could upgrade to PV 4.0.1 where this annoying bug has been fixed.
The problem occurs with 3.98 when the PointSprite plugin is loaded. You can not load the plugin if you're not using it and that will overcome the issue. As Zony suggested, you can always upgrade to 4.0.1 and this issue will disappear.
This may be a simple fix and maybe I'm missing something obvious, but when I split my DB it wasn't entirely finished, and there have been modifications requested which require me to edit my backend.
How come it's not the same GUI layout (exactly)? Tables open in "windows" within Access, and when maximized, cannot be closed, etc. It's annoying as hell as I can't close my table to deal with its relations. I can only get to design view by finding it in the Tables list and RightClick->Design instead of on the bar above the tables, etc.
Is there a setting somewhere that caused these minor GUI changes when I split the DB? How do I put it back, as it's bugging me greatly; slowing down modifications by a lot.
EDIT: It seems that the "tab windows" option was removed for the backend for some reason..
Appearance of the windows in MS Access 2012 is controlled by the Options settings:
File->Options->Current Database under Document Windows Options
We have an 'enterprisey' system with a scheduling component which gets floored if any dialogs come up. If any modal dialogs come up in the processes it is running, it gets 'paused' and can't kick off any new processes.
Excuse me a minute ...
*goes outside*
*laughs*
*cries*
*comes back*
.. ahem ... so anyway we need some sort of tool/technique that can lurk in the background and automatically detect specific dialogs and click OK on them. Any recommendations?
The offending system is running in Windows XP.
(NB: changing the third-party-enterprisey system or making its developers sit on the naughty step until they improve it are not options in the short term)
From this similar question I found:
Buzof by Basta Computing
which did the trick.
There is also a product called DialogDevil which looked promising but didn't work in our situation for some reason.
AutoIT is absolutely perfect for this. You can use the tool to help identify the dialog, write your own simple code and distribute the "auto clicker" via exe. It lurks in the background by running from the task tray.
DialogDavil will require exact same parameters on your dialog (for which you want buttons to be autoclicked) every time that same dialog pops up. And thats why it didnt work for me in first pass. Then i changed the control file at the following path to remove the changing items (a text box text in my case)
C:\Users\userName\AppData\Roaming\DAIR\DialogDevil\control.xml
And then it worked like a charm.
HTH,
I'm running Visual Studio 2010 with SP1, as well as R# 5.1, and a few other extensions (like PowerCommands and Productivity Power Tools). Somewhere along the lines, my debugging got super slow. If I use the F10/F11 keys to step, VS hangs for a bit and then steps. If I use the toolbar buttons for stepping, it's snappy as expected.
Any idea what's up with my shortcut keys?
I had exactly the same problem - extremely slow debugging with keyboard (F10 for example). Some symptoms:
if I click Step Into on toolbar, then everything works normal,
the lag during debugging is present not only in Visual Studio but anywhere (notepad, browser,...),
if I set any other browser as default browser in Visual Studio (I tried Firefox), then it works OK,
if I disable third-party browser extensions in IE, then it works OK,
if I enable third-party browser extensions and disable LastPass, then the problem is gone and debugging with keyboard is fast again!
So, try to disable LastPass extension if you have it or all extensions and try it.
Edit1 - somebody allready posted this on LastPass forum: http://forums.lastpass.com/viewtopic.php?f=12&t=61029
Edit2 - and here on SO also :) https://stackoverflow.com/a/8186670/1110039
I've found a deeper explanation for this problem.
I had this problem, with the symptoms user1110039 described BUT I haven't installed LastPass toolbar. And my default browser is Firefox.
Well, my application uses SetWindowsHookEx() function for setting a system wide shortcut. Which happens to be the reason for blocking F10/F11 debug keys (only in Windows 7 64 bits) It doesn't happen under 32 bits.
I've just removed the hook from the debug build and it works ok. I reckon the problem with LastPass is some system wide hook in the code of the extension.
I had exactly the same problem.
The problem was solved by closing the Watch window.
Try debugging with Firefox or Chrome. There must be something about the interaction with IE that is causing this behavior.
Disable "show threads in source" worked for me!
Calling DirectInput's Acquire() function on a keyboard device is what caused the slowdown for me. This is potentially related to the SetWindowsHookEx() caused slowdown - ie. that might be using DirectInput.
It's really odd that the keyboard stepping is slow while the toolbar buttons are not. Typically whenever I hear about a slow stepping experience my recommendation is to disable automatic property and ToString evaluation as this is the most likely cause
Tools -> Options
Debugger -> Uncheck "Enable property and .ToString evaluation"
I'm not very hopeful that will fix this instance. It sounds like a problem with a misbehaving extension that processes keyboard input. Your best bet is to disable the extensions one by one and see which one fixes the problem. I would do it in the following order
Productivity Power Tools
Power Commands
R#
Make sure you've installed Service Pack 1. I believe they fixed at least one significant performance problem in the debugger.
I experienced that very slow step by step debugging too, and fixed it by closing the threads window.
(Making a note here on an old thread, so it can be found in a web search.)
I normally leave the ==Disassembly== window open during debugging (I have a big screen.) I just discovered that single-stepping in the debugger can be speeded up by 50% if I hide that window too. The -tab- for it can exist and be handy - makes no difference - but the window itself shouldn't be showing. Ahah.
Have followed all the other suggestions and more from elsewhere, single-stepping is now about 8 times faster overall. (About 2.5 steps per second now.) Woo-hoo! Thank you all.
(I don't understand how they can write such slow UI code... I have a CPU here that's running at two billion cycles per second... that works out to about 400 million instructions per single step. Seems like Microsoft code could be a -little- faster... but then, I've never had the pleasure of using .NET etc.)
I tried all the suggestion and finally found that When I uninstalled VS2005, this issue got resolved. Note that in that machine VS2005
I was having this problem in my new job, where we use Visual Studio 2008 SP1. (Yes, I know, I know). Long delay on step with flickering hourglass. I always use F10, I don't even think about it, there's no way I could tolerate changing to the mouse or waiting multiple seconds for a simple step command.
I read through all the solutions provided here and elsewhere on the net with no joy.
Finally found the issue - I had set up my default language for the IDE as C#. It turns out the project I'm working on actually uses VB.NET, and when I set the default language to VB.NET (via Tools - Import and Export Settings) the debugger got so fast that I couldn't keep up with it and accidentally pressed F5 on the breakpoint I want to examine.
I hope this helps someone else.
In the end, the disabling of Last Pass in my browser (IE) was what solved this problem for me, but along the way I learned a lot of other things that could have just as easily been the cause. A variety of other valid answers to this question (Some in the various answers on this page) are validated and explained here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
This article explained that this F10 slowdown can be from having various diagnostic windows and toolbars open, Symbol loading issues, etc. and also explained what to do about debug slowdowns in general. It was an eye opening education that I think will continue to help me in the future should the F10 slowdown rear it's head again.
In my case it was the Call Stack window (Visual Studio 15.9.13) that caused the lag!
Even when I stepped over a very simple line like ++i; it took around 1-2 seconds until the debugger stepped over to the next line. Closing the Call Stack window or hiding it fixed the lag for me immediately.