Scope does not show enough information regarding cursor position in code.
How can I enlarge scope line in ABAP Debugger on the standard tab?
Probably a bug in your SAP GUI version. You should install the latest version.
See in SAP GUI 7.50 how the elements look better; the "scope" is left-aligned and has the biggest width possible, and all other information are right-aligned and their size is minimal:
I suppose this is resolution-dependent. On my 1920x1280 it goes fine out-of-the-box.
Did you try to drag the splitter between the editor and variable tab?
Usually it helps
Removing and clean installation of SAP GUI 7.50 solved the problem.
Backup connections before removing:
https://answers.sap.com/questions/409243/saving-connections-list-in-sap-logon.html
Related
I downloaded Windows 64-bit with JDK 8 included of SQL Developer 18.1.
To run Oracle SQL Developed I just unzipped the file and run the sqldeveloper.exe contained in the folder.
Unfortunately, as you can see in the image the size of everything is extremely small and very difficult to see.
This issue appears exclusively with this software.
How can I resolve it?
I also faced a similar issue when installed this on Windows 10. The issue has to do with compatibility settings.
I have fixed it following the steps given below:
Get shortcut of sqldeveloper at your desktop
Ensure that you have admin rights in your PC
Right Click on sqldeveloper icon and select Properties.
Go to the Compatibility tab:
Compatibility mode change it to windows 7
Check the option of Override high DPI scaling beaviour
Select "System" in drop down below
Apply
Re-Launch the application
I guess this is a subjective statement - but that doesn't appear SMALL to me.
However, if you're using an OS accessibility feature to increase the size of text in your applications, the new 'Welcome Page' can interfere with that.
Uncheck 'show on startup' in the Welcome page
Restart SQL Developer.
You should be good.
The Welcome page uses JavaFX to render some HTML and this is apparently getting in the way due to a Java bug. We're looking to mitigate or fix this for a future release.
If that doesn't work, you can also try to actually increase the UI font size.
I talk about how to do that here
This is what it looks like bumped up to font size 14
Find your ide.properties file.
Windows: It's in your OS User's AppData, Roaming, SQL Developer, systemX.Y.Z..., o.sqldeveloper directory where X.Y.Z... represents your version of SQL Developer.
Linux/Mac: It's in your $HOME/.sqldeveloper, systemX.Y.Z, o.sqldeveloper directory.
You’ll notice this file is VERY well documented. There’s a section that speaks to Windows in particular. To change the default size for all look and feels, add this line, the uncommented one:
# To modify the font size for a particular locale under all
# look-and-feels, set the Ide.FontSize.<languageID> property. For
# example:
Ide.FontSize.en=14
2018 Update
On my 4k Mac Mini (2018 build if that matters):
Oracle 8 JDK
SQL Developer 18.3
Mac OS X look and feel
Ide.FontSize=21
This is how SQL Developer looks:
I changed font style and size from available settings from SQL developer.
We can change using Tools -> Preferences ->Code Editor -> Fonts
Fixed this for myself in Oracle Linux 8, but is also worth trying in RHEL and Fedora, if you use either of those.
If SQL Developer is running, close it.
With superuser privileges, open the following file for editing:
sudo nano /opt/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf
Add the following two lines at the end:
AddVMOption -Dsun.java2d.uiScale=2
AddVMOption -Dsun.java2d.uiScale.enabled=true
Restart SQL Developer.
If the interface still looks too small, or too big, change the uiScale value (untested).
I had the same issue,
if you still could not fix the problem with the given solutions, for me also worked the following:
Go to the Display Settings;
Go to scaling and "reset it": change to another scale, for example, 100% and then to your preferred scale;
This should force the SQL-Developer Window to your preferred scale, unfortunately you have to repeat this procedure after every new SQL-Developer launch.
change the setting from "Compatibility tab" as highlighted in the above post was the only way to make the icon much more larger
In case anyone landed here looking for the same answer for a newer version of Oracle SQL Developer (like I did)…
As of v22.2.1, for macOS the preferences are now located in Oracle SQL Developer --> Settings…
You can adjust the font style and size under Code Editor --> Fonts
Hope that helps!
I have a coworker who needs to have multiple versions of LabVIEW on his computer. He has a bad habit of opening LV2010 code in LV2013. LabVIEW doesn't warn that you are about to change all of the code to a new version of LabVIEW, and this breaks the code running on a test system on the production floor.
Here is my question: does anyone know of any kind of hack or legitimate method of changing the windows title bar for a single application? I would like to be able to change the color of the title bar only on LabVIEW 2013 from blue to red or something.
If this isn't possible, does anyone have an idea of how to distinguish one application from another that looks almost identical?
Thanks for any advice you have to give.
Well, the good news is that LabVIEW 2014 on will have the version number in their icon. That doesn't help your situation much, though. I'm not sure about changing the title bar, but I think I can help with your second question.
The icons for those versions are indistinguishable, however, the mass compile LabVIEW does when you open a project from an older version is a dead giveaway. You know LabVIEW is performing a mass compile if, while the project is loading, "Compiling:" appears where "Loading:" normally does. Close out of LabVIEW without saving and open the right version of LabVIEW. If he still goofs, there's always reverting in whatever version control software you're (hopefully) using, and you can always save back to older versions in LabVIEW itself.
I currently have four (older) versions installed to support projects that are under warranty. One trick I've found to be helpful is to put a .txt document in the same directory I save my .lvproj with the LabVIEW version as the title. For example, if the code is written in LabVIEW 2012 I include a text document called LV2012.txt in my _Project folder. Not a foolproof plan, but it has definitely made me double check my open version of LabVIEW before double-clicking.
I would suggest to use get VI version property described here: http://digital.ni.com/public.nsf/allkb/0C72D335AA87DD6486256FC40069C17F
Than using version information change you title bar text or transparency(I am not sure about color) or other FP component using VI ref property node.
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.
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.
Hy everybody,
I'm wondering if it's possible to add a new button via C++ or C# to windows 7 explorer "context strip"(don't know if this is correct name) - like on picture below.
My reason for this is because a lot of times I'm switching on&off "Show hidden files, folders and drives" functionality under Tools->Folder option->View. Therefore i want to simplify this process with a click of a button.
I was looking into ShellExecteEx function, but I am not sure I can do that. Can Anybody direct me in right direction?
thanks,
regards
I highly recommend using AutoIt for this task. Second URL comes complete with examples of how to insert buttons in various programs - however, be sure to read complete topic for misc. updates to the provided code.
See:
http://www.autoitscript.com/forum/index.php?showtopic=9517
Btw: I misread topic to begin with; gui 'context' related material in Windows is often taken to deal with right-click menus
Edit: limit on urls for new users on Stack Overflow mean I had to cut out some of less essential links - google away.
To answer part of the question, I think it is possible as for quite some time we've seen small programs to add a "New Folder" button to the explorer. I think those still works with Win 7.
Look at http://tools.tortoisesvn.net/StExBar for example
[Edit] Forgot to clarify that Source Code for StExBar is on Google Code