I've written a short script (in another language, happens to be Python) which passes arguments to the command line as follows -
ildrt <path/filename.sav> -args p1 p2 --o1 --o2
where p, o are positional and optional arguments respectively (obvious). To get to the point, this script calls an IDL routine any number of times. Each time, the IDL virtual machine is loaded, the IDL routine runs until completion, rinse and repeat.
Unfortunately if an error occurs in the IDL routine execution a dialog box will popup and halt program execution until manually clicked. Since the idea is to run this as a batch process I want to ignore the dialog boxes, (accepting the error), and continue to the next run. Any thoughts on preferences or optional commands I can run IDL with to prevent the popups? Thanks in advance.
I guess I'm not following. Can't you just pass a flag to your program and then check that flag before popping up a dialog in your code? If you don't have access to the .pro code, then I don't think you can prevent the popups.
Related
Would really like to retrieve the entire line as it is typed before it is submitted so checks can be run before the user adds a line break? How would one accomplish this?
Thank you for reading.
You can archive this by setting stdin.lineMode to false. In that case you get a stream event for every character typed instead of only one per line. If you want to handle the outputing of the entered character on your own, you can also disable stdin.echoMode. In that case you have to pring the entered characters on your own. You have to enable it again after your program exits, otherwise the terminal stays in that mode.
One problem is that you are unable to reactivate echoMode in case of a program crash as there is no global crash handler. See issue 17743 for that.
I'm working with a fairly large dataset and any time I perform an operation, if I forget to include the semi-colon at the end of the statement it takes several minutes because it outputs all the data to the console window as it goes. How do I halt execution of the current statement?
I've tried using Ctrl-C like in MATLAB, as well as using the Abort and Interrupt options in the Control menu, none of which seem to be working. Is this a bug, or am I missing something? I'm running on Windows 8 64-bit in case that helps.
To halt execution, press Ctrl-C in the console window of Scilab. This will display
Type 'resume' or 'abort' to return to standard level prompt.
-1->
Entering abort abandons the computation completely. Entering resume resumes it.
I did not check it but this tutorial gives as option the ESC key
"To abort a command midway without executing it, press the Esc key on the keyboard."
Is there a way to detect whether execution is currently in the middle of QDialog.exec()?
I'm the author of DreamPie, a Python shell, and it lets you run Python code while Qt GUI is being displayed. It does that by running the Qt event loop for 1/10 of a second, and then checking if any Python commands need to be executed. The event loop is stopped by a QTimer which calls QApplication.quit() after the timeout.
If a QDialog.exec() is active, however, I don't want to call QApplication.quit(), because it will break the code. The current solution is to check whether there's a modal dialog active, by checking if QApplication.activeModalWidget() is None. However, I currently have a modal dialog which is not run with QDialog.exec(), and it's blocking Python commands for no reason.
Is there a way to exit the event loop only if it's not called recursively by QDialog.exec()?
Thanks!
You can check whether your dialog is visible with QDialog.isVisible. Normally, a modal dialog is visible only while it is being executed.
I'm currently writing a macro that performs a series of control sends and control clicks.
They must be done in the exact order.
At first I didn't have any sleep statements, so the script would just go through each command regardless whether the previous has finished or not (ie: click SUBMIT before finish sending the input string)
So I thought maybe I'll just put some sleep statements, but then I have to figure out how best to optimize it, AND I have to consider whether others' computers' speeds because a slow computer would need to have longer delays between commands. That would be impossible to optimize for everyone.
I was hoping there was a way to force each line to be run only after the previous has finished?
EDIT: To be more specific, I want the controlsend command to finish executing before I click the buttons.
Instead of ControlSend, use ControlSetText. This is immediate (like GuiEdit).
My solution: use functions from the user-defined library "GuiEdit" to directly set the value of the textbox. It appears to be immediate, thus allowing me to avoid having to wait for the keystrokes to be sent.
I want to use function:
pid_t tcgetpgrp(int fildes);
How to retrieve the fildes(to be passed to this function).
And is process group id returned by this function is same as the one returned by
getpgrp(0)//0 for the calling process
??
Often standard input, output, and/or error (0, 1, or 2) will be connected to the controlling terminal. To be sure just open /dev/tty, which will always be the controlling terminal if you have one. The file descriptor returned from open() can be passed to tcgetpgrp() and then closed if it is no longer needed.
The tcgetpgrp() function returns the foreground process group id, whereas getpgrp() returns your process group id. They would be the same if your process is in the foreground, or different if your process is in the background. tcgetpgrp() would return an error if your process had no controlling terminal, and is therefore not in the foreground or background.
You can pass any file descriptor that is open to a terminal; the call will retrieve the information about that terminal. A process may have file descriptors open to a number of terminals, but at most one of those is the process's controlling terminal. A given terminal may, in fact, have no process group associated with it for which it is the controlling terminal (though it is relatively unlikely to be opened in that case).
Michiel Buddingh' suggested STDIN_FILENO from <unistd.h> (which is normally a fancy way of writing 0); the trouble with that is that programs can have standard input redirected from a file or have the input piped to it, in which cases the standard input is not a terminal. Similar considerations apply to STDOUT_FILENO (aka 1). The best descriptor to use, therefore, is often STDERR_FILENO (aka 2); that is the least likely to be redirected.
The second half of the question is 'does tcgetpgrp() return the same value as getpgrp()'. The answer is 'No'. Every process belongs to a process group, and getpgrp() will reliably identify that group. Not every process has a controlling terminal, and not every file descriptor identifies a terminal, so tcgetpgrp() can return the error ENOTTY. Further, when tcgetpgrp() does return a value, it is the value of the current foreground process group associated with the terminal, which is explicitly not necessarily the same as the process group of the current process, which may be part of a background process group associated with the terminal. The current foreground process group can change over time, too.
You need a file descriptor number attached to the current terminal. For example, you can use 0 or STDIN_FILENO from unistd.h.