New Parser Features
Prev
Next

New Parser Features

Types

Each value is of one of three types: string, integer or double. Type conversion is automatic and chooses most appropriate type (for example, if you add double to integer, result will be double). If one of the values is string, result will be string too.

Places you can get into trouble here are getting a numerical value from a widget and trying to perform a mathematical function on it. Since Kommander uses + to concatonate two strings of text it can treat LineEdit1.text + 2 as 22 instead of 2. See the conversion functions in String functions to avoid problems.

Expressions

The following mathematical operators are supported: +, -, *, mod, . Standard brackets are of course supported as well.

All kinds of comparisons are supported: <, >, <=, >=, ==, !=. Instead of != you can also use <>. Also, logical operators and, or, not are supported, as well as their C equivalents (&&, ||, !).

For strings you can use + operator for string concatenation.

Some examples of valid expressions:

2+3
-5 * (2 - 13 mod 3)
"This list has " + 12 + "items."

Variables

Variables don't need to be declared. Once you use variable, it is considered declared. Type of a variable is recognized automatically and can be changed later.

Associative arrays are supported as well. They map string keys onto values of any type. To declare such array, you can just add some element to it, for example: A["Quanta"] = "Web editor". Arrays are also handled by foreach command and array functions.

Local and global variables are supported. Global variables are marked by leading underscore. So, myVar is a local variable, but _myVar is global. The same applies to arrays.

a = 5
b = 2 * 5 - (a + 1)
c = "[Item " + b + "]"
d["MyKey"] = "MyValue"
d["MyKey2"] = 5

Using variables for widgets works much as you would expect. This is useful when looping widgets into a table.

for i=0 to 10 do
  mycombo = "ComboTable"+i
  createWidget(mycombo, "ComboBox", "Form1")
end

Comments

You can use comments in Kommander using the two traditional program language comment forms for line comments. For those users who are new to programming wondering “what traditional form?” see below. You can copy and paste the text below into a button or dialog initialization and see how comments behave in action.

// this is a comment for one line
message_info("Hello World") //traditional first program
// the above comment also ignored - the messagebox is not
# this is also a comment
message_info("This message will show")

Using the following multi-line comment will not work and will cause the rest of the widget execution to fail.

/*
Hi, I was supposed to be a comment 
None of the script after this will execute
DON'T USE THIS TYPE OF COMMENT IN KOMMANDER!
*/

Built in Globals

Kommander has some built in globals you may find handy.

  • _ARGS - the argument string passed to the dialog on opening

  • _ARGCOUNT - the count of arguments passed. These can be retrieved as ARG1 to ARGn where n is the total number of args passed

  • _KDDIR - the directory from which the dialog was run. Kommander will default to your home directory, or a directory change if asked for it's current directory. This is useful for saving and reading files with the Kommander file.

  • _NAME - there is no reason to use this so don't

  • _PID - the process id the current dialog is being run from - also available as just pid Avoid using this name for your variables!

  • _VERSION - this is handy if you want to display the version of Kommander that is running

Passing arguments in Kommander

You can pass arguments via script parameters, signals and slots, command line parameters and DCOP. Let's look at scripts. Call your script like:

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 arguments. Unnamed look like

kmdr-executor myprog.kmdr 100 red
Where 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 global variables.

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(TQString,TQString)", "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 parameter, "setText(TQString,TQString)" is important because it prototypes the parameters allowed. Otherwise Kommander could not validate the call. 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
Next
Home


Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team