i am calling an old vfp procedure through DO WITH PARA COMMANDS
when the command executes, it displays a form and Waits(Read command)
Can i skip this Read, through programing? so that it doesn't wait..
Sounds like a VERY OLD program with an explicit "READ" command... If you just comment out the read, will that work for you. Are you trying to otherwise bypass some functionality based on parameters and just have the function continue? If so, you could put an IF around the read for only the condition that you NEED it to stop.
Also, if the form is a "MODAL" (WindowState = Modal), it will stay on that form until it is closed (or set to hidden) and returns back to calling source to continue execution.
Showing some context of the form, procedure might help other options.
Related
When setting the delimiter via vorpal.delimiter('foo'), it does not update immediately, but waits until a command was submitted.
I'd like to update the delimiter on receiving a keypress event. Is there any way to force the visual change?
As you stated, vorpal.ui.delimiter will induce a temporary change in the delimiter. For a permanent change that redraws right away, do this:
vorpal.delimiter('foo');
vorpal.ui.refresh();
The vorpal wiki went up since I asked this, and it included some additional documentation.
What I needed was vorpal.ui.delimiter rather than vorpal.delimiter.
Working code:
vorpal.ui.delimiter('foo');
I am using Rstudio and not sure how options "run" and "source" are different.
I tried googling these terms but 'source' is a very common word and wasn't able to get good search results :(
Run and source have subtly different meanings. According to the RStudio documentation,
The difference between running lines from a selection and invoking
Source is that when running a selection all lines are inserted
directly into the console whereas for Source the file is saved to a
temporary location and then sourced into the console from there
(thereby creating less clutter in the console).
Something to be aware of, is that sourcing functions in files makes them available for scripts to use. What does this mean? Imagine you are trying to troubleshoot a function that is called from a script. You need to source the file containing the function, to make the changes available in the function be used when that line in the script is then run.
A further aspect of this is that you can source functions from your scripts. I use this code to automatically source all of the functions in a directory, which makes it easy to run a long script with a single run:
# source our functions
code.dir <- "c:\temp"
code.files = dir(code.dir, pattern = "[.r]")
for (file in code.files){
source(file = file.path(code.dir,file))
}
Sometimes, for reasons I don't understand, you will get different behavior depending on whether you select all the lines of code and press the run the button or go to code menu and chose 'source.' For example, in one specific case, writing a gplot to a png file worked when I selected all my lines of code but the write failed to when I went to the code menu and chose 'source.' However, if I choose 'Source with Echo,' I'm able to print to a png file again.
I'm simply reporting a difference here that I've seen between the selecting and running all your lines and code and going to code menu and choosing 'source,' at least in the case when trying to print a gplot to a png file.
An important implication of #AndyClifton's answer is:
Rstudio breakpoints work in source (Ctrl-Shift-S) but not in run (Ctrl-Enter)
Presumably the reason is that with run, the code is getting passed straight into the console with no support for a partial submission.
You can still use browser() though with run though.
print() to console is supported in debugSource (Ctrl-Shift-S) as well as run.
The "run" button simply executes the selected line or lines. The "source" button will execute the entire active document. But why not just try them and see the difference?
I also just discovered that the encoding used to read the function sourced can also be different if you source the file or if you add the function of the source file to your environment with Ctrl+Enter!
In my case there was a regex with a special character (µ) in my function. When I imported the function directly (Ctrl+Enter) everything would work, while I had an error when sourcing the file containing this function.
To solve this issue I specified the encoding of the sourced file in the source function (source("utils.R", encoding = "UTF-8")).
Run will run each line of code, which means that it hits enter at the beginning of each line, which prints the output to the console. Source won't print anything unless you source with echo, which means that ggplot won't print to pngs, as another posted mentioned.
A big practical difference between run and source is that if you get an unaccounted for error in source it'll break you out of the code without finishing, whereas run will just pass the next line to the console and keep going. This has been the main practical difference I've seen working on cleaning up other people's scripts.
When using RSTudio u can press the run button in the script section - it will run the selected line.
Next to it you have the re - run button, to run the line again. and the source button next to it will run entire chuncks of code.
I found a video about this topic:
http://www.youtube.com/watch?v=5YmcEYTSN7k
Source/Source with echo is used to execute the whole file whereas Run as far as my personal experience goes executes the line in which your cursor is present.
Thus, Run helps you to debug your code. Watch out for the environment. It will display what's happening in the stack.
To those saying plots do not show. They won't show in Plots console. But you can definitely save the plot to disc using Source in RStudio. Using this snippet:
png(filename)
print(p)
dev.off()
I can confirm plots are written to disc. Furthermore print statements are also outputted to the console
Xcode's auto-completion is often getting in my way by giving me argument placeholders when I already have them. Here's an example:
I want to change that second MoveToPoint to AddLineToPoint, so I delete part of the name, and hit control + space for the Show Completions command. I get something like:
You see the annoyance. I tab complete the name, but now I have to delete the 3 arguments, the commas, and the parentheses. This kind of thing annoys me and throws off my flow when writing code.
Ideally I'd like a way to delete these placeholders with one command, or have a separate auto-complete command, so along with Show Completions (control + space), I could bind something like Show Completions without Placeholders. Does anyone know how to do that?
XCode does support this actually. They call it "Select Previous Completion". Check it out here (under Code Sense).
You essentially just hit ⌃> (hold control and press >) for XCode to choose your previous completion. It think it only works well though if the new method you're calling takes the same number of arguments as the previous one.
Hope this helps
I'm trying to determine how the system prints characters to standard input -- that is, how it prints characters which the user can delete and which are considered input if the user hits "Enter."
I happen to be using C, but I would be very surprised if the solution were language-dependent.
Thanks for any insights! : D
As iny says, bash uses readline for its input. The source is available here, and there's a file called complete.c.
To answer your question, I don't think they're actually printed to standard input. Readline contains some kind of buffer for the contents of the line the user is editing, and completion prints into this. When the user presses enter, the contents of the buffer are sent to whatever program wanted to read a line, and in the case of bash, passed along into standard input. (Readline doesn't do this - other programs which use readline might simply store the value into a string for later use.)
Several people have pointed out that bash uses readline, which is true, but I think what you're really asking is how is it able to see what you've typed before you hit enter.
The answer is that ttys (ie: terminals) can be switched into "raw mode", where input processing of the terminal is disabled, and then you'll see every character as it comes in. This also disables automatic echoing of typed characters.
See this guide on Reading a single character from a file or a terminal for more info.
It uses readline library to handle the input and readline provides the history and the completion.
To actually implement completion, access to the keyboard input handling is needed. The completion must be able to modify the buffer used by it. After that it is just about looking at the current input and checking what completions is found. The actual completion logic can work in many ways.
Here's a C snippet that implements tab completion via readline:
http://github.com/rupa/el
I have an application that has 'macro' capabilities. When I map some keys on the keyboard to perform the 'macro', I can also have it launch vbscript instead.
What i'd like to try and do is within my vbscript figure out what keys were used in order to launch the script. Is it posible to do this? Could there be a way in vbscript to figure out what keys were last touched on the keyboard and then I could apply my logic.
The purpose of doing this is to keep the code in a single .vb file instead of several seperate .vb script files(one for each keyboard mapping, possible 3-4). Obviously we are looking to just maintain 1 file instead of multiple files with essentially the same code in each one.
I am leaning towards the idea that this is not possible, but i figured this would be a worthy question for the masses of StackOverflow. Thanks for the help everyone!
What you are asking for is not possible.
Can you change your VBScript to accept parameters and then call it with a different parameter based on which hotkey was selected?
I agree with aphoria, the only way to make something like this possible is if your keyboard mapping software allows you to assign a script/command with parameters/arguments. For example if you used
c:\Temp\something.vbs
then you would change this to
%WINDIR%\system32\wscript.exe c:\temp\something.vbs "Ctrl-Alt-R"
Then in your vbscript code you could collect the argument using the wscript.Arguments object collection to do actions based on what argument/parameter was passed. See the following two links for more info:
http://msdn.microsoft.com/en-us/library/z2b05k8s(VS.85).aspx
http://www.microsoft.com/technet/scriptcenter/resources/qanda/sept04/hey0915.mspx
The one possible approach you may use is to install keylogger and read its log in your VBScript.
For example save script start time in the very beginning of the script
StartTime = Timer()
and then read one log record of your keylogger before this time.