![]() | Passing arguments in Kommander |
| Prev | Parser features | Next |
You can pass argements via script parameters, signals and slots, command line parameters and DCOP. Let's look at scripts. Call your script like so.
result = ScriptObject1.execute("Hello World")
debug(result)
Inside your script you might have the following
var = str_upper(Self.Item(0)) return(var)Now you will get a return in your Stderr message log of HELLO WORLD
Receiving a signal connected to a script slot works the same way. Self.Item(0) is parameter one and so on. You can retrieve the count of arguments passed with ScriptObject.count.
Command line parameters allow for named or unnamed aruments.Unnamed look like
kmdr-executor myprog.kmdr 100 redWhere you will find _ARG1 = 100 and _ARG2 = red. One quirk is passing strings with spaces as an argument means they need to be quoted. Using the dialog command complicates matters as the entire argument string must pass as one string, meaning in quotes.
dialog("mydialog.kmdr", 100+" \"Hello World\"")
This returns _ARG1 = 100 and _ARG2 = Hello World. Without the escaped quotes you would have _ARG2 = Hello and _ARG3 = World. Using Named Parameters is rather nice and potentially less confusing.
dialog("mydialog.kmdr", "xcount=100 xquote=Hello world")
And now you access those with _xcount and _xquote
DCOP can be complex, which is why we recommend using the tools we develop to enable creating DCOP for remote Kommander dialogs with something like a function browser. Here is an example DCOP call issued from a dialog opened from a parent Kommander window. Since it knows who its parent is it can send information back while it is open and freely access all its parent's functionality with the exception of slots. Of course that can be done internally with a script which can be called externally, so in practice there is no limit to what can be done.
dcop("kmdr-executor-"+parentPid, "KommanderIf", "setText(QString,QString)", "StatusBar8", "Hello")
Let's look at this piece by piece. First of all we add parentPid to "kmdr-executor-" as we make no assumption a Kommander window was the caller. You could use this with Quanta or KSpread or whatever. Next we are addressing KommanderIf, which is a nice interface for end users which has been cleaned up. We hope eventually as KDE moves from DCOP to DBUS on KDE4 that more applications adopt a nice interface for integration. The next paramter, "setText(QString,QString)" is important because it prototypes the parameters allowed. Otherwise Kommander could not validate the call and could crash. So without a definition of the DCOP call being used you will get an error. The remaining parameters are of course what is being passed. We recommend you look at applications with kdcop to see how this works and practice dcop calls from the shell to get your syntax right.
| Prev | Home | Next |
| Built in Globals | Up | Commands |