I have a script in Marathon, a Java Swing test automation tool using Jython or JRuby, that plugs in a value to the application under test; however, it doesn't plug it in sometimes. It is very sporadic. I tried to wrap the setting of the text values with an until loop, but that even sometimes doesn't work. The code looks like this:
until get_component("foo").getText() == "blah" do
select("foo", "blah")
end
get_component("") is a function that returns the Java object. After that I'm pretty much doing straight Java so the .getText() works just as it would in Java. Select is also a Marathon function that simply selects your foo object and plugs in the blah value. Therefore, all my code is doing is waiting until the "foo" object has "blah" text value and once it does then it moves on.
The problem that I have is that sometimes the application doesn't hold the "blah" value. I considered that it was a bug, but when I do this manually I can't recreate the problem. It simply plugs in the value as I would expect it to.
Has anybody else ever ran into this with any other scripting tool? If so, how did you overcome it?
I was able to get around this by putting a wait_p("foo", "blah") immediately after select("foo", "blah")
select("foo", "blah")
wait_p("foo", "blah")
This basically forces the application to wait until the foo component has the blah text before moving on.
Related
I'm working with python scripts in Inductive Automation's Ignition HMI (java backend) software. I'm trying to write a script that locates other scripts that are tied to certain objects. Currently I have
result = window.getRootContainer().getComponent("Group 1").getComponent("TheObject").mouseClicked
which gets the window displaying my object, enters the root container of that object, then the group that the object is in and then finally the script tied to the mouseClicked event on TheObject. When I run this and print the result, I don't get an error, but:
<CompoundCallable with 0 callables>
Has anyone seen this before? Does anyone know what I may need to change in my first line of code to access the actual data stored in the mouseClicked script?
Looks like there is no code associated with the mouseClicked event of that object.
CompoundCallable is a "composition of callables", something callable that calls multiple callables - kind of a callable container. It is used to allow registering multiple functions to be called in a single event handler.
However your CompoundCallable contains zero callables. That means nothing will be called if you call it.
If I understand what you're asking, I don't believe you'll be able to access the data that is in that script (variables, etc.). You could have the mouseClicked script write data to something else in order to access data. There are multiple possibilities for that: Custom Window Property, Custom Component Property, or a tag.
I have a Java project in eclipse which is divided in two parts; two different main classes that run two different Threads basically.
One contains loading, initialization and debug-showing procedures that are quite slow. While, the other manipulates the initialized data. In order to retrieve the information in the second part, the first one "saves" all the references inside a static map which contains instances of classes.
Does exist a way to run the first part only once, and then compile and run the second part more times? I tried with just set two different console and pressing the run button in different times but the static field of the first class looks not existing when the second runs.
I am working now only in the second part, so I need to test and start it many times. I really appreciate an help to save a lot of time wasted in always initialize the same thing.
ps : Everything works fine if I run both parts together.
thanks in advance
Luca
thanks to the replay (Multithreader, Stephen C) I am trying to make the question more clear and to ask how to solve it since my solution does not look the best one.....
EDIT 1 : The "first part" initializes the program and then runs an easy GUI which is periodically update. So as long as it shows up we shouldn’t care about how to manage input and output from the user
EDIT 2 : the "second part" reads information from the previous and send back strings to the GUI for debug purposes.
EDIT 3 : I do not have specific constrains in the shape of the project, so I can change the structure if there are better solutions. As well as for the way to run it.
FARTHER QUESTION 1 : there is a possibility to compile only one part of the project in eclipse while it runs all together? I mean, if two threads are running, can I stop one, re-compile it and run it again in a way that it can see the instances created from the first thread which never stops? Basically I need to refer at the same static variable loaded in memory, if it exists.
FARTHER QUESTION 2 : or more luckily does exist a way to store and load in a file instances of Java classes avoiding to write from sketch a mapping mechanism from/into txt files?
It is not entirely clear what you are asking here, but I'm assuming that you are talking about running the "first part" and the "second part" in the same JVM ...
Yes, it is possible. But it is not straightforward.
Basically, you need to refactor your code so that there is some kind of "control box" that the user can interact with from the outside. For instance, this might just be a simple command loop that reads commands from standard input and runs them. (Alternatively you could turn your application into a "service" that accepts requests over a network socket, via RMI, via HTTP, etcetera.)
Then you wire things up so that there is a "command" to run the "second part" of your application in response to the user's request.
That's the basics. The other thing you want to do is to "compile and run the second part [many] times". That implies that you need to set up your "control box" so that it can load a fresh copy of the code for the "second part" after you have modified and recompiled it. To achieve this, you will need to create a new ClassLoader object (each time) and use that to load the classes that make up the "second part". This is possible, but a bit tricky. The problems you are going to need to address include:
Splitting the "first part" and the "second part" into separate JAR files (or directory trees). The "first part" needs to be self-contained ... no dependencies on classes in the "second part".
Make sure that there are no runtime references from the "first part" data structures to instances of objects / enums in the "second part".
If you don't get the above right, you are likely to experience "permgen" storage leaks and mysterious type cast errors.
All in all, there's a lot that needs to be done to make this work. Unless you already understand all of the technologies involved, I'm doubtful that it will save you time overall. A better idea might be to figure out how to speed up the initialization of the "first part"; e.g. by doing lazy initialization, or caching the data structures using some fast / light-weight persistence mechanism.
I think it is better to change your design unless there is a requirement for it to stay the same.
Although I do not have the requirements or what you are actually trying to accomplish, I suggest you the following design:
1. App_1 does the calculations and then writes the results into file
2. App_2 reads checks for the file, if NOT exists display error message; otherwise read the file and keep going...
I guess I found a tricky solution. It is dirty but it works natively in the eclipse debugger.
I am running in debugging mode a main method which create a thread that works as a caller. This runs the first part of the project and wait until the initialization is complete (note that the first part doesn't end here, it remains looping to show debugging information based on a static class which evolves with the second part of the program). Then it starts with an infinite loop where it just calls the second part that I want to test and change: here there are also a breakpoint.
Well, now I can coding in the second parts while the eclipse debugger is waiting in the breakpoint than save it and hit F8. The debugger resumes, the algorithms runs and then it stops again in the breakpoint. Just check if works, eventually change something then save and hit F8 again without wait to re-initialize the first part of the project.
Probably this method has to be restarted after a while but still, it better then restart every time :)
many thanks to all your help.
If somebody has more elegant way to do that they are welcome!!
I have the following problem, we might even call it a classic one:
public void myMethod(Map<Object, Object> parameter){
someOtherObject.method(parameter);
.
.
.
someOtherThirdPartyObject.method(parameter);
}
And suddenly, in the end some method touched the input parameter Map, and I don't know where and how. Now, I know it would be desirable to make the parameter immutable, but it is not and that is the root of the problem. For instance, the methods inside myMethod are intended to perform some validations, but they do some more as well, which is wrong by design.
So, the question is how to create a breakpoint in this method where the execution pauses if an attribute of this parameter Map changes? It might be a good idea to put a conditional breakpoint after each method call, but if you have 20-odd methods, it's rather painful.
How can I debug when this input parameter is changing?
What you want appears to be called a "watchpoint". I actually didn't know this functionality existed and I used to work on the Eclipse Project!
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_add_watch.htm
It looks like you'll have to figure out what fields are being editted and then set a "Write" watchpoint using the help document above.
Additionally, Eclipse highlights variables which are modified, so if you step over your method calls one by one you will be able to see which one is modifying the value (and which field is being modified) because it will be highlighted (bright yellow, by default) in the "variables" tab in the "debug" perspective. Once you know which method if modifying the data you can run debug again, but this time debug the method that changes the value and just keep repeating until you find the problem.
This is a classic problem solving scenario where you start with a very large search space and systematically and methodologically narrow it down until the search space is small enough for you to locate the problem.
If you're trying to locate a spot where your map is being modified incorrectly, you might want to first start at the higher levels of the myMethod. Put breakpoints around the methods called inside the myMethod method. At each breakpoint, look at the contents of the Map. Eclipse has a variable watch panel where you can see the contents of every variable at a specific moment in time.
When you hit the breakpoint where you notice something is wrong. Stop. You now know to dig into someOtherObject.method(parameter); assuming the data was changed at it's breakpoint.
Now, someotherObject.method will likely have other methods inside it. Put your breakpoints inside this method around all of it's function calls and repeat the process. Continue repeating until there are no more methods left. Eventually, you will narrow down the problem and have the answer.
Unfortunately, there is no magic "fix my code" button for these types of problems. It just takes good, old fashioned Sherlock Holmes style investigative skills and reasoning to eliminate areas of the code that you know aren't the problem until you're left with a smaller section that allows you to get at the root cause.
If no code modification is allowed, you can
use the watchpoints method described by acattle to watch changes at this specific map instance or
have breakpoints in the Map methods modifying its state (if you want to do that for multiple instances). It does not matter that the Map code is binary only, you can still open it using Ctrl-Shift-T (Open Type), select the methods like put(...) or remove(...) in the outline view and add breakpoints using the context menu in the outline view.
I've been bitten by this old bug/missing feature in Java:
http://bugs.sun.com/view_bug.do;jsessionid=b2ac8ea11f05c16d948e24d36fb5?bug_id=4673406
The thing is that the "Properties" button in Java's standard print dialog is seemingly always disabled on Windows. The button is only enabled if PrintService.getServiceUIFactory() returns something that isn't null. Unfortunately Win32PrintService instances always return null. Always.
By googling, I discovered that you can invoke Windows' own print properties dialog thingy by calling rundll32:
rundll32 printui.dll,PrintUIEntry /e /n "name of printer here"
I'm hoping I can use this to circumvent the bug/missing feature in Win32PrintService. However, I don't know how I can query the PrintUIEntry-dialog for the user's choices.
In other words, how can I get a result of the above rundll32-invocation? (If I have to write something in C/JNI and use the Windows API directly, so be it. I'd rather not, though.)
Or is there a better way to solve this problem?
rundll32 does not give you any return value, its exit code is always zero.
I think you'll have to find another way.
I just had an idea that I wonder whether is possible in java. Let's say when doing debugging using eclipse or netbeans, you could record an object and save it. Then when going through the second round of debugging, save the object again. Now you could compare the first object recorded with the second object for all properties and find out any differences. Is this possible?
You can do this in plain Java code (assuming your objects are Serializable), but I don't think any debuggers have this feature built-in.
It would simply be a case of serialising the first object during the debugging run (which if you had a static method to do so, you could generally call from the debugger) and saving it somewhere. Then, during the second run, call another method to reconstitute the object from it's serialised form - and then compare the objects (either with their equals() methods, or some more bespoke comparison method).
In practice though I find that whenever I want to do this I just scribble down the relevant properties on a piece of paper and compare them manually. Rarely am I looking at thousands and thousands of properties that might change between a run; if you think about the symptoms you're seeing and the behaviour of your object, you can normally have a very good idea of what might be changing before you even fire up the debugger, and then use the latter to confirm your hypothesis and backtrack to see where the value "went wrong".
Give your object a useful toString() method and then use unit tests to compare the result with what you expect.
But I agree: The wire protocol for remote debugging can serialize any object, so it should be possible to write a program that does this automatically.
OTOH, objects which aren't meant to be serialized can be dangerous. If you accidentally use this on a classloader, you'll get all objects and classes and everything back as one big lump. So you need a way to stop the serialization to make sure it can't run havoc in a deep object tree.
On top of that, I'd like a feature to save the current state of the app and be able to go back in time.
I don't think any debugger can save object to compare them later. What you can do though is to create a watch variable on the variable, but wrap it with the ToStringBuilder() of the apache commons and dump it in the console, like so:
System.out.println(ToStringBuilder.reflectionToString(object));
Each time the breakpoint is reached, the content of the object will be shown in the console. You can even see the private data.
Therefore, you do not need to modify the toString() method of the object directly (this is useful for library object for example). You can then compare the output of your two passes.