Am new to IntelliJ IDEA (am using 2017.1.3)...
Accidentally, made my Console tab window float and can't seem to reattach it to IntelliJ IDEA. When I run the Debugger, it launches as a separate window (which is very annoying).
Is there a way to reattach it back to the main window but on right of the Projects view and right underneath the Source Editor view?
Attached is a screenshot of the issue, at hand (which one can click on to see it in high res):
Update
Okay, somehow (by doing a lot of clicking and dragging), this is the closest that I've come to what I've want. The thing that's bothersome is that I can only see the Console (stdout) updated when the debugging session is over (not in real-time, as I've would been able to do in Eclipse). :(
Update the console in realtime:
If you want all the JUnit test output to the console in real-time, just do as follows:
choose the configure
do configure for JUnit
floating separate tab of windows need restore on the tab.
You have two methods to restore floating windows:
uncheck the floating mode in the terminal windows
uncheck the floating mode in the Windows/Active Tool Windows
Let me show the 4 location of Console in the Debug view, I think there should be one which is what you want:
first
second
third
last
My goal is to launch a file using this in vb.net via the click of a button..
System.Diagnostics.Process.Start("X:\Desktop\Brutal Doom\PLAY ME BRUTAL DOOM!!!.pk3")
Which works, however as soon as I move to my laptop or another computer the button can no longer find the file as the drive letter has changed.. is there a way to code this so that it is no longer dependable on the drive letter and only will see \Brutal Doom\PLAM ME BRUTAL DOOM!!!.pk3 thus working on whatever computer I put the folder on...
Are you basically looking for this? How to get a path to the desktop for current user in C#?
ie System.Diagnostics.Process.Start(My.Computer.FileSystem.SpecialDirectories.Desktop & "\Brutal Doom\PLAY ME BRUTAL DOOM!!!.pk3")
I am considering writing a graphical tool that will show you what gnu-screen sessions you have and what windows are available in them. You would then be able to, for example, click on the window title and it would take you there. I do not want to modify gnu-screen in any way so that my tool can work with existing installations on other machines and so on.
I can get ordinary output from programs running inside screen out of the screen session by using a log-file, or by copying the last few lines into the exchange-buffer. What I really need in order to make a nice user interface though is the contents of the status line (the line that temporarily appears at the bottom of the window). For example, to get the list of windows in a session I can send the windowlist command, but the result is never part of the output. Does anyone know if there is a way to make screen put its messages into the log, into a paste-buffer, into the current window, or anything similar where I can grab it from another program?
I picked vb.net for this question since it's the only prgramming language I am fairly familair with, but if C++ or something else is more suited for this, I am willing to learn something new.
What I am trying to do is:
Retrieve text from database (this already works in vb.net) and copy it to clipboard
Switch primary screen to the external application I want to work with (example: word or open office)
Emulate key-press Enter
Paste text and hit Enter again
Emulate key-press Ctrl and then emulate a click on a pre-defined spot on the screen (like 500pixels from left, 740pixels from top).
Save screenshot, using a second value from the database as the filename (the naming part should be easy)
Emulate another click on another pre-defined spot
Repeat for next text in database.
I wouldn't know where to start, though. I guess the most important part of what I'm trying to achieve is; switching focus to an external application and emulate keypresses and mouse clicks on it.
use http://www.autohotkey.com/
write a console app to get the value from the database
1 - get autohotkey to run the console app and put the return into the clipboard
then continue as described in your list.
I have a virtual machine (VMware) with Mercury Quick Test Professional 9.2 installed. I have a script to test an application, written in VB.NET using the Infragistics library.
If I access this virtual machine using my laptop (using Remote Desktop), everything works fine, the script completes without a problem. My laptop runs XP, with Windows Classic theme.
If I access this virtual machine using another machine (using Remote Desktop), the script starts fine, but stops halfway through, without no error message from QTP, nothing. This machine runs XP, with Windows Classic theme.
One difference between the two setups is the size of the screen, the laptop is 1920x1280, other machine 1280x1024.
The step where the script stops involves checking a checkbox within an UltraWinGrid. The checkbox itself is displayed, is on the screen in both cases.
Has anyone had this problem before, or have any idea why the behaviour is different between the two machines?
Thanks.
OK. I've found the problem. In fact, the script was failing silently because that's what the person who wrote the script told it to do. It couldn't validate something which was off screen, so the script failed.
The problem was the QTP definition of 'off screen'. I have two screens attached to my laptop, the screen for the laptop itself (1920x1200) and another screen (1280x1024). I connect to the VM for QTP using remote desktop, and it uses the settings of the screen for the laptop. This means that when I launch my QTP script, and move it to the other screen, it doesn't fit, so the screen is no longer maximized, and the object is partially off screen, so can't be found.
The fix is simple: in the Remote Desktop, use the Display tab, and set the size of the screen to a size to 1280x1024, and QTP doesn't have any more problems.
Voilà.
If you are not using Expert Mode, and / or are allowing QTP to do most of the work to create your repository objects, then yes it is referencing everything by pixels.
I create all of my repository objects by hand, viewing the source (in the case of automated web-application testing) and using the Object Spy for assistance where needed. I make a point to not have any positioning information as part of my object definition, for the very reason you are running in to.
For the parts of my web-app that interacted with Windows (opening a file to upload, etc.) the Object Spy was essential for the trial and error necessary to create a unique identifier for creating the repository object. But it can be done.
Ex1: File Browse Dialog
text = "Choose file"
nativeclass = #32770 (apparently some Windows VooDoo for a file open dialog?)
Ex2: Filename textbox in Browse dialog:
nativeclass = "Edit"
attached text "File &name:" (more Windows VooDoo? It woudn't work for me without the "&")
Ex3: Open Button in the dialog:
text = "&Open"
object class = "Button"
Good Luck!
Point of clarification: You mentioned that QTP stops with no error message. Does that also mean that the test results log file also has no error message? If the log has any information, that may be helpful in diagnosing the problem. Could you share the lines of code at the point where the script fails?
Also, remote desktop will resize the desktop on the remote machine. Although QTP scripts are not inherently coordinate based, individual statements can be coordinate-based relative to an object. The resolution could be an issue in that regard. For example, imagine you had a line like Button.Click(5, 150) recorded on a higher resolution machine. But if you attempted to play it back on a lower resolution machine, and the 150 is out of bounds of the object on the lower resolution, it could cause an issue.
QTP does not use screen coordinates except as a last resort, if the objects are identified as high level objects (SwfTable in this case) you should be OK, if however QTP doesn't recognise the object it falls back to WinObject and screen coordinates.
If you're using Infragistics then you should know that they extend QTP's support with their TestAdvantage product which will probably solve your issue.
Edit:
#MatthieuF said:
In fact, we use the Infragistics plugin for QTP, and we still have the problem
Can you give me an example of a line that fails?
A few things:
You should be able to debug on the VM easily - just wait for it to stop, go into your object repository, and see if it can identify the object. If no then use object spy to figure out what properties are different between the OSes. If there is a difference then you can always set that property to a regular expression and have it check for both possibilities.
Assuming that isn't the issue we've run into problems using remote desktop with QTP if the Remote window is closed or minimized. For us, it was an issue where the clipboard can not be changed when an RDP window isn't visible, but there could be other surprises when using QTP that way.