Am since long trying to add objects from a Java based application in UFT 14.52 but not able to.
Made sure that all hooks are added to env vars. UFT is behaving weird ie it spies the object correctly, but the moment I try adding it doesn't. In some circumstances, it does add it but then again doesn't highlight it. Even though when I try adding the same, it adds exactly the same object but again doesn't highlights.
I have tried
. Reinstalling UFT
. Reinstalling java 1.8 (202)
. Enabling and disabling plugins
. Installed UFT with admin privileges
( In all the cases, am launching UFT first)
. Deleting and resetting java env vars
The machine am on has security policies in place and I can not do much modification to system or registry except the user ones.
Am able to add Windows, wpf or web objects. It is the java am having issues with.
Any help or insight Will be helpful.
Good night.
Make sure that
Your system display setting are set to 100%
and
your browser zoom % set to 100%
I see similar problem with Java application and after setting both setting it worked like charm.
Related
I created a new application with react native windows, and it works well the first (few) times I run it, however, when closing the application I always end up with the following warning:
Attempt by security transparent method 'System.Reactive.Concurrency.CoreDispatcherScheduler..ctor(Windows.UI.Core.CoreDispatcher)' to access security-critical type 'Windows.UI.Core.CoreDispatcher' failed.
I've tried this on more than one computer and all of them get the same error but I can't find a way to fix this, meaning I cant proceed with my Native project in fear that it will malfunction every day.
How do I fix this, to stop this from happening again, or is it a bug?
I'm a novice in React Native myself, but here are a few suggestions:
1) There's an issue logged in GitHub on this exact problem: https://github.com/Microsoft/react-native-windows/issues/1954
2) I personally find that I get this with command-line execution (react-native run-windows) but I don't think(?) that I've seen it when running from inside Visual Studio. Try that approach to running instead.
3) As described at GitHub - I've found that deleting windows\Debug folder before running tends to resolve the issue.
After recently updating my project to meteor 1.2 and including the new ecmascript package (to use ES2015 features), I realized that my server debug breakpoints will never run, no matter what I do.
After reading about different ES6 posts on meteor forums and jetbrains , I tried setting up file watchers to create sourcemaps, but:
meteor complains about the generated files(so you have to move them to special folders in order to keep going)
It still doesn't work :(
Setting up spy-js also didn't work (never tried before so maybe I did it wrong)
I could reproduce the problem with the basic TODOs application and debugging with default options.
It is fixed for now in EAP 11 builds.
Known issue, please follow WEB-18074 for updates. Unfortunately I can't offer any workarounds:(
I refer this to enable the debugger in the PostgreSQL server in order to debugging the plpgsql function by stepping through the code using pgadmin.
I have already set shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' in the postgresql.conf, run pldbgapi.sql , and restarted the server.
These steps should have been run successfully and plugin_debugger.dll should be loaded successfully as can be verified by using the command show shared_preload_libraries, and I can see the debugging option in the context menu with a right click on a function in pgAdmin.
When choosing "Debugging" --> Debug, a window pops up to allow me to enter the values for the input parameters. But after that, when I press OK, it does not respond at all.
Any ideas or did I miss something in the setup of the debugger on the server?
I am using PostgreSQL 8.3 and pgAdmin 1.14
You have to enable debugging in two places. On PGAdmin and on the database itself. That article you referenced does a wonderful job explaining it but there were some nuances.
PGAdmin
When updating your postgresql.conf file to load the debugging library, I was running PGAdmin on Windows so the file was here:
C:\Program Files\PostgreSQL\9.4\data\postgresql.conf
And the path to the plugin_debugger.dll was actually
$libdir/plugin_debugger.dll
not
$libdir/plugins/plugin_debugger.dll
as specified in the article. So your postgresql.conf would need a line like this
shared_preload_libraries = '$libdir/plugin_debugger.dll'
Search for the actual .dll if you're in doubt. If you're on Linux the file you'll be looking for is plugin_debugger.so. Don't forget that changing the postgresql.conf file will require a restart for the change to take effect.
PostgreSQL Database
Assuming you're running your PostgreSQL database on a Linux server this gist does an excellent job at explaining how to download the dependencies for enabling debugging. Make sure you're running as root when you install.
The part that's easy to miss is issuing the command against the actual database you want to debug. For newer versions on PostgreSQL all you'll need to do is this:
CREATE EXTENSION IF NOT EXISTS pldbgapi;
If that doesn't return an error, you should be good to go.
Some additional things of note:
As mentioned above, you can only debug when running as a super user account
From their docs you can only debug pl/pgsql functions. So if your function says something like LANGUAGE c PGAdmin won't even show a right-click Debug menu option when you select the function. Look for something that has LANGUAGE plpgsql and the Debug menu should show.
Ken,
Have you tried pgAdmin 1.8 to rule out issue with PgAdmin 1.14/ PostgreSQL 8.3 interaction. It's been a while since I've used 8.3 and for the article I wrote -- which you are referring to, I was testing with 1.14/ PostgreSQL 9.1 so it could very well be an issue with the interaction with older version. Unfortunately I don't have a 8.3 anymore to test with.
I vaguely remember having the issue you had once, but it was when I had another shared library in my postgresql.conf in addition to the pldebugger. Can't remember which one that was, but removing the other shared library fixed my issue.
Hope some of these suggestions help,
Regina
I had the same problem.
Make sure the only shared lib you´re loading in the postgres.conf is the debugger.
Nothing else. Not even the profiler.
If you get a SSL error when trying to debug a function, reconnect to the server.
my current work tasking requires creating a firefox plugin. I've done this relatively easily on Linux but porting to windows has exposed a peculiar problem. To do the port, I refactored the basic windows example given in the mozilla source tree. I did this operation slowly and methodically, testing as I went. Aside from the occasional OS dependent glitch everything seemed to be going fine until I finally changed the output name of the plugin dll. So, instead of creating a dll called npbasic.dll, the filename was fubar.dll. This immediately caused the plugin to stop working: it did not get picked up in Firefox about:plugins. Changing the filename back to npbasic.dll allowed the firefox plugin tab to "see" the plugin again.
Is anyone aware of an aspect of dll linking/functionality which could be causing this observed dependency?, any help or pointers would be greatly appreciated.
Well, I've done some more research and it's clear that my approach of painstakingly refactoring the example plugin was flawed, the best strategy is to use something like firebreath, as described here : How to write a C++ FireFox 3 plugin (not extension) on Windows?
I am trying to get started in development of my website and plugins using Umbraco. When I download the binaries from Codeplex, the installation and running of the website works fine. When I downloaded the source code, All I get is a login screen even when the web.config files are the same. Am I doing something wrong or is there something I missed.
The path I use to map IIS to is
branches\4.1.0\umbraco\presentation
You need to compile the source code to get it to work.
To be honest, you shouldn't need the full source unless you really want to start hacking around in the core (which may cause you problems with future updates) or you want to see how stuff works. The Umbraco framework is pretty extensible, I've not found too much so far that I couldn't do without having to touch the core source.
I had a similar issue when running the source and that was that the hashing of the admin password did not work. So i debugged it to see what value was expected and then changed it in the database.