# KScript Editor 1.1 with support for import statement and namespaces [and OSX support]



## kotori (Aug 8, 2006)

Hi everyone
If anyone is interested in trying the new import statement out http://nilsliberg.se/ksp/setup-kscript-editor-1.1beta4.exe (download the beta) [link edited] and let me know what you think.

The import statement is really neat, but it also has one problem - now the feature requests about a longer file history will come thick and fast :mrgreen:. Until I get time to look at that I'd like to say that drag-and-drop works if you drag files to the window title or status bar (it doesn't work if you drag to the actual text area because I had trouble doing that without disabling drag and drop of text which Bob said he used).

It's possible to import the same module twice under different names and for a script to import module A which in turn imports module B. Sample:
*import* "otherfile.txt" *as* mylib
mylib.myvariable := 10
mylib.play_chord(3)

All variables declared inside a function called "on_init" are implicitly global. If you still want local variables (eg. it might be needed to initialize the global ones) you can declare them using the 'local' keyword:
*function* on_init
``*declare* myvariable```_{ implicitly global }_
``*declare* local i``````_{ explicitly local }_
*end function*
The local keyword is only needed in the special on_init function. I strongly advice against using it in other cases since it only makes code harder to read.

In the current beta there is no checking for recursive imports, so please refrain from writing files that directly or indirectly imports themselves (doing so can make your system unstable because the editor will begin to eat RAM). I'll try to fix this in an upcoming sharp version.

Cheers,
Nils


----------



## Dynamitec (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils! I can't wait to check it out. But i have to wake up first  

Thanks a lot!


----------



## gh (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils!

First of all : Tack så mycket for all your efforts.

I have tried the new import function but I can't get it working. Could you please post a short example how it is supposed to be used?

Cheers
Günter


----------



## kotori (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



gh @ Tue Aug 08 said:


> Hi Nils!
> 
> First of all : Tack så mycket for all your efforts.
> 
> ...



Hi Günter,
Here's an example with two files:
script.txt (main script file):
````*import* "functions.txt" *as* f
````
````*on init*
``````f.on_init````
````*end on*
````
````*on note*
``````ignore_event(EVENT_ID)
``````f.play_transition(EVENT_NOTE)
````*end on*


functions.txt:
````*function* on_init
``````*declare* last_note
````*end function*
````
````*function* play_transition(cur_note)
``````*declare* i``
``````*for* i := last_note *to* cur_note
````````play_note(i, 60, 0, 50000)
````````wait(50000)
``````*end for*
``````last_note := cur_note
````*end function*

I hope this helps. This is a beta so everything might not yet work as intended. I'm greatful for all error reports.

Cheers,
Nils


----------



## kotori (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

I made some changes and released a >> http://nilsliberg.se/ksp/setup-kscript-editor-1.1beta3.exe (second beta) <<. Using this version it's possible to pass families as arguments to functions:

A few notes about the new namespace feature and its limitations: As soon as you import something all the user-defined variables and function in the imported code are prefixed with the namespace followed by '__'. This means that a variable declared as global in a module is not global in the sense of being directly accessible from the main script, but rather becomes a module variable - it's accessible in all functions in the module. A module has no way of accessing things in the main script namespace except things passed in as arguments to functions.

The import is similar to an include directive in C/C++. That is, it works as if the import-ed code had been inserted and replaced the import line, with the only exception that the code gets its own namespace.


----------



## kotori (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

In the versions posted earlier the 'as ...' in 'import ... as ...' was mandatory. Removing this limitation was only a matter of changing two lines of code, so I did this and http://nilsliberg.se/ksp/setup-kscript-editor-1.1beta3.exe (here)'s a new version with this small change implemented (I updated the links above). Leaving the 'as ...' part out will make import bring in all functions and variables into the current namespace (which is a fancy way of saying that it does what you'd expect it to do). 
Sample: *import* "otherfile.txt"

Günter, did the example above make it clear how to use the import statement? Feel free to ask otherwise.

Cheers,
Nils


----------



## Dynamitec (Aug 8, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils!

Just want to say thanks again. So far everything seems ok but tomorrow i'll go to use it a litte bit more than today. So maybe  *g*

[schild=1 fontcolor=C0C0C0 shadowcolor=C0C0C0 shieldshadow=1]Thank you Nils![/schild]


----------



## gh (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hello Nils!

I have tried your example with the 1.1beta3 version. The concept is clear now, I actually had expected a "plain" text import similar to the version without "as".

2 comments:

a)
Your example does not work, I get the following error message:

f.cur_note not declared. (line8):
for $_f.i:= f:last_note to f:cur_note
in file functions.txt

b)
in the current implementation IMPORT is limited to import functions. I had thought (and hoped) it could be used also for plain text import. 
I.e. in larger project a finished code segment could be put into a separate file and imported into the main document.

Although, MY perfect solution would be something I had on an old ATARI editor: collapse / expand blocks.

Cheers
Günter


----------



## Dynamitec (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Günter,

i don't think i can follow you. You mean: import is limited to import functions? And you want to have whole finished code fragments to be imported.

I think it's up to you to implement your finished code as functions...i think plaintext doesn't really make sence. How do you want for example on controller or on note events to be imported? In which order should those different on-callbacks be written to the on-callbacks from the main script? At moment this this is possible if you just pack your "on note" callback from your import file into a function and call it in the "on note" callback from the main script for example.

I do the following: for each finished script i have a "fixed area" which i can import to new projects and a (commented out) area which i copy and paste and modify in the main script. This last area is used to setup for example values of variables etc...since they can change with every new project a import of those would make less sence.

But this collapse / expand feature would be great, i agree


----------



## kotori (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Günter, 
As Benjamin says most of the time using functions is the way to go. The only useful use-case I can see in importing code fragments directly is for large lookup-arrays which are normally uninteresting to look at and take up a lot of space. However, that's possible to achieve using something like:

data.txt:
*function* on_init
``*declare* lookup_table[512] := ...
````( _{ ... a lot of values here ... }_ )
*end function*

script.txt:
*import* "data.txt" _{ lookup_table is now available }_

I too would love to have expandable/collapse blocks. I use Scintilla for the editor which as excellent support for this. Unfortunately it's tied to the lexer and I use a premade pascal lexer for the syntax highlighting since KSP is so similar to pascal (except for its keywords). If KSP had only used the 'begin' keyword to start blocks this would be a piece of cake. While it is possible to implement a C++ lexer for KSP and recompile the scintilla dll it's not something that has high priority right now. Something I'd like to do though is to have some means of navigating the code, eg. a tree-view to the left of the editor which could be shown or hidden. However, the main priority right now is to fix all the problems with the latest beta (eg. the bug you reported above). 

Nils


----------



## kotori (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi,
I corrected a mistake that caused trouble with function arguments used inside nested blocks within modules (a pretty important use-case :roll. Günter, the sample code I posted above should work with »http://nilsliberg.se/ksp/setup-kscript-editor-1.1beta4.exe (KScript Editor beta 4)«.

I also fixed some oddities in the indentation code which should restore the normal indentation and improve the new indent-on-paste feature.

Cheers,
Nils


----------



## gh (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hello Nils!

I confirm with 1.1beta4 the bug has gone. One small thing left:

on init 
declare $_f__i 
declare $f__last_note 
{begin f__on_init}
{end f__on_init}
end on

The "{begin f_on_init} comment seems to be misplaced.

I also have noticed that the indent on paste feature works better now. 

Benjamin, thank you for your feedback. 

Günter


----------



## kotori (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Günter,
thanks for the confirmation. The comments in 'on init' are normal since they wrap whatever the function does - not what it declares - and in this case the function does nothing. The declarations always go outside (eg. functions invoked in 'on note' must still have their declared variables go into 'on init'). However, I agree that it seems a bit strange so I changed this so that in the next version there will be no comments with nothing in between like these.

Cheers,
Nils


----------



## mmosc (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



kotori @ Wed Aug 09 said:


> Hi Günter,
> As Benjamin says most of the time using functions is the way to go. The only useful use-case I can see in importing code fragments directly is for large lookup-arrays which are normally uninteresting to look at and take up a lot of space. However, that's possible to achieve using something like:
> 
> data.txt:
> ...




The ability to import code fragments would enable controls created in the *on_init *function and the cooresponding *on ui_control ... end on* code to reside in an import file. The ability to show & hide controls lends itself to multiple modules in a single script i.e. legato, vibrato, humanize etc. The ability to encapsulate each module in its own source file would be advantagous. 

Thanks for a great tool that keeps getting better.


----------



## kotori (Aug 9, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



mmosc @ Thu Aug 10 said:


> The ability to show & hide controls lends itself to multiple modules in a single script i.e. legato, vibrato, humanize etc. The ability to encapsulate each module in its own source file would be advantagous.
> 
> Thanks for a great tool that keeps getting better.


Hi mmosc,
Thanks. The use of the word "would" make it sound like "the ability to encapsulate each module in its own source file" is a hypothetical future feature, but it's already possible to do this using the latest version (at least when all problems in the beta have been ironed out) so I'm not sure if I get your point. It would only take me a minute to enable import of code-fragments (lines not wrapped in functions) anywhere in a script. However, it doesn't give any benefits and only makes the code harder to understand compared to using functions. If you disagree, please motivate the advantage of code-fragments over using functions as you see it.



mmosc @ Thu Aug 10 said:


> The ability to import code fragments would enable controls created in the *on_init *function and the corresponding *on ui_control ... end on* code to reside in an import file.


There's nothing to stop one from calling other functions from within on_init or ui_control callbacks (possibly imported ones). In the compiled code that is exactly the same as importing code fragments, and by using functions the uncompiled code gets easier to read (since function names serves as a kind of documentation).

Cheers,
Nils


----------



## Nickie Fønshauge (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Nils, when I have these two lines


> declare ui_button Note_duration
> declare note_duration


in the 1.1 beta 4 version, I get a "Variable declared twice" error message. Shouldn't the editor distinguish between capital and small letters?


----------



## kotori (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Nickie Fønshauge @ Thu Aug 10 said:


> Shouldn't the editor distinguish between capital and small letters?


Although one might think so the answer is actually no, because Kontakt doesn't. Case it a bit special in KSP - builtin variables are case-sensitive but user-defined ones are not.


----------



## Nickie Fønshauge (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

I see. I was pretty sure, I had variables somewhere, that only differed in the case and worked in earlier versions of the editor. I guess my memory played me a trick then. Plus the built-in variable $NOTE_DURATION fooled me.


----------



## kotori (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Nickie Fønshauge @ Thu Aug 10 said:


> I see. I was pretty sure, I had variables somewhere, that only differed in the case and worked in earlier versions of the editor. I guess my memory played me a trick then. Plus the built-in variable $NOTE_DURATION fooled me.


Yeah, it's easy to be fooled about this. I didn't notice the case-insensitivity either until after several months of KSP programming. Btw. there has been one change in the beta and that is that variable names may no longer begin with a digit, but I have changed that back so it will be allowed again in the next file I release.


----------



## mmosc (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



kotori @ Wed Aug 09 said:


> mmosc @ Thu Aug 10 said:
> 
> 
> > The ability to show & hide controls lends itself to multiple modules in a single script i.e. legato, vibrato, humanize etc. The ability to encapsulate each module in its own source file would be advantagous.
> ...



I understand the main script can declare the on ui_control with the body of the on ui_control calling a function in the import file but the thing I'd like to avoid is having to declare the on ui_control in the main script. 

for example 

import file "module1"

function on_init
declare ui_knob c1(0,1000000,1000)
declare ui_knob c2(0,1000000,1000)
...
declare ui_knob c12(0,1000000,1000)
end function
function on_note_handling
...
end function

on ui_control c1
...
end on
...
on ui_control c12
...
end on


main script

import "module1.txt" as m1

on init
m1.on_init

declare ui_menu display
add_menu_item(display,"module1", 1)
end on

on ui_control display
select display
case 1
move_control (m1.c1, 1,1)
...
move_control(m1.c12,6,6)
case 2
... 
end select
end on

on note
m1.on_note_handling
end on

If an import file is created like above today the editor does include the on ui_control text in the importing script but they're placed in the beginning of the script preceeding the on init causing forward referance errors

Hope this clarifies my point

BTW - I do think the editor is an invaluable tool and appreciate all the work that you have put into it as well as making it freely available. Can't thank you enough for that. I also think NI should owe you a nice fat check.


----------



## kotori (Aug 10, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi mmosc


mmosc @ Fri Aug 11 said:


> If an import file is created like above today the editor does include the on ui_control text in the importing script but they're placed in the beginning of the script preceeding the on init causing forward referance errors.


Have you tried placing the import statement where you want the imported callbacks to go (after the init callback)? :wink: 

The 'import' statement will import anything but the use of 'import' isn't allowed inside functions or callbacks. As a consequence only constructs allowed at the top-level (functions and callbacks) are allowed. That's how I should've expressed myself. Sorry for the confusion. I think your point is very valid and I'll try to move the init callback to the top in the compiled output to allow import statements to be written at the top of a file.

Cheers,
Nils


----------



## kotori (Aug 11, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

I added three lines to make sure that the init callback is always the first callback in the output. This makes it possible to use import statements on a line before 'on init' that imports other callbacks since 'on init' is automatically moved to the top on compilation. This was such a small change that I didn't bother to change the version number. Just http://nilsliberg.se/ksp/setup-kscript-editor-1.1beta4.exe (redownload beta4) and mmosc's sample code will compile (variable names with leading digits allowed as well in this version).

Benjamin, have you had a chance to try out the beta yet?


----------



## Dynamitec (Aug 11, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils!

Yes, the only thing i found at moment is what you already fixed (import before on init).

At moment i'm writing a "basis" script i can use for all my scripts with a configurable UI. So far everything works ok.


----------



## mmosc (Aug 13, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils,

Does the import handle string arrays with namespaces? for example:

_import file t1_

function on_init
declare strings[3]
strings[0] := "abc"
strings[1] := "def"
strings[2] := "ghi"
end function

_import file t2_

function on_init
declare !strings[3]
strings[0] := "abc"
strings[1] := "def"
strings[2] := "ghi"
end function

_script 1_
import "t1.txt" as t

on init
t.on_init
declare ui_menu m1
add_menu_item(m1,t.strings[0],1)
add_menu_item(m1,t.strings[1],2)
add_menu_item(m1,t.strings[2],3)
end on

_compiles as_

on init
declare %0[3]
%0[0] := "abc"
%0[1] := "def"
%0[2] := "ghi"
declare ui_menu $1
add_menu_item($1,%0[0],1)
add_menu_item($1,%0[1],2)
add_menu_item($1,%0[2],3)
end on

_script 2_

import "t2.txt" as t
on init
t.on_init
declare ui_menu m1
add_menu_item(m1,t.strings[0],1)
add_menu_item(m1,t.strings[1],2)
add_menu_item(m1,t.strings[2],3)
end on

compile error 
Syntax error in declaration. (line 2):
declare t.!strings[3]
in file t2.txt

_script 3_

import "t2.txt" 

on init
declare ui_menu m1
add_menu_item(m1,strings[0],1)
add_menu_item(m1,strings[1],2)
add_menu_item(m1,strings[2],3)
end on

correctly outputs

on init
declare !1[3]
!1[0] := "abc"
!1[1] := "def"
!1[2] := "ghi"
declare ui_menu $0
add_menu_item($0,!1[0],1)
add_menu_item($0,!1[1],2)
add_menu_item($0,!1[2],3)
end on

Am I missing something?

Thanks
Mike


----------



## kotori (Aug 13, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Mike,
Thanks for pointing out that bug. It seems the '!' got incorrectly placed in the middle of variable names as they were prefixed with the module name. I have fixed this in the »*1.1 release*«. I don't guarentee that the new functions are completely stable but I think the indentation part of the editor works better now so for that reason I released a 1.1 version, and I'll do my best to fix any reported problems quickly. Btw. when posting compiled code please turn the 'compact output' off temporarily. :wink: 
Thanks again for reporting this.

Cheers,
Nils


----------



## mmosc (Aug 13, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils,
really fast turn-around - thanks, unfortunately the built in variables like $KNOB_UNIT_DB are now throwing errors. They worked before this last update.


----------



## kotori (Aug 13, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



mmosc @ Sun Aug 13 said:


> Hi Nils,
> really fast turn-around - thanks, unfortunately the built in variables like $KNOB_UNIT_DB are now throwing errors. They worked before this last update.


Thanks for letting me know. In the hope that not many others have had a chance to download it yet I uploaded the new file on top of the current one. Please redownload the 1.1 version.


----------



## mmosc (Aug 13, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils,

That did it

Thanks again for a great tool


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils!

I have a small wishlist - maybe you can do on or two things from this:

- An extra window showing all used variables (only main script! Not included ones, to keep it simple) in a table. There you can rename variables (they will be renamed in the whole script than, like in Visual.NET) Same for functions. This would be great to change variable names easily and have an overview.

- Some more inline functions. Due to the fact that there are no multidimensional arrays and sometimes 512 is way to less it would be great to have this:

Now you have to do it so:

*select* nummer
``*case* 1
````do_something_1
``*case* 2
````do_something_2
``*case* 3
````do_something_3
*end select*

You could have something like an "inline_add" and "inline_select" command

inline_select(variable, 1, 3, do_something) _{ Variable, From, To, FunctionName }_ 

Generates:

*select* variable
``*case* 1
````do_something_1
``*case* 2
````do_something_2
``*case* 3
````do_something_3
*end select*

And now it comes to inline_add(from, to):

*on init*
``
``*declare* array[100] with inline_add(1,3)
``
*end on*


*function* do_something with inline_add(1,3)
``
````*declare* i
````*declare* j

````*for* i := 0 *to* 99
```````j:= j+ array_
````*end for*
```
*end function*


Compiled:

*on init*
``*declare* array_1[100]
``*declare* array_2[100]
``*declare* array_3[100]
*end on*

*function* do_something_1
```*declare* i_1
```*declare* j_1
```
```*for* i_1 := 0 *to* 99
``````j_1 := j_1 + array_1`````
```*end for*
```
*end function*

*function* do_something_2
```*declare* i_2
```*declare* j_2
```
```*for* i_2 := 0 *to* 99
``````j_2 := j_2 + array_2`````
```*end for*
```
*end function*

*function* do_something_3
```*declare* i_3
```*declare* j_3
```
```*for* i_3 := 0 *to* 99
``````j_3 := j_3 + array_3`````
```*end for*
```
*end function*
__

Do you know what i mean?_


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils,
These are just some thoughts. Maybe there is even a much smoother way. But it think you understand what this will be good for. You can keep your uncompiled code way smaller!


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Cleared...


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

You could write a great and complex UI in much less time!


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

The same thought but more flexible:

*on init*
``
``inline_ui_add(titel1, 'ui_label global testtitel1(1,1)', 1,1, Group1) _{Name, Declaration, Position, Group}_
``inline_ui_add(titel2, 'ui_label global testtitel2(1,1)',1,3, Group1)
``inline_ui_add(button1, 'ui_button global testbutton1', 1,2, Group2)
``inline_ui_add(button2, 'ui_button global testbutton2', 1,4 , Group2)

``inline_ui_show(Group1)``
```
*end on*

*on ui_control*(button1)
``
``inline_ui_hide(Group1)
``
``inline_ui_show(titel1)
``
*end on*

*on ui_control*(button1)
``
``inline_ui_hide(Group1)
``
``inline_ui_show(titel2)
``
*end on*

Compiled:

*on init*
``*declare* ui_label global titel1(1,1)
``*declare* ui_button global button1(1,1)``
``*declare* ui_label global titel2(1,1)
``*declare* ui_button global button2(1,1)```
``move_control(titel1,0,0)
``move_control(button1,0,0)
``move_control(titel2,0,0)
``move_control(button2,0,0)```
``
``_{ inline_ui_show(Group1) }_
``
``move_control(button1, 1,2)
``move_control(button2, 1,4)
``
*end on*

*on ui_control*(testbutton1)
``
```move_control(testtitel1,0,0)
```move_control(testtitel2,0,0)
```
```move_control(testtitel1,1,1)
`````
*end on*

*on ui_control*(testbutton2)
``
```move_control(testtitel1,0,0)
```move_control(testtitel2,0,0)
```
```move_control(testtitel2,1,3)
`````
*end on*


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

maybe this would be easier to read:

UI_GROUP Group
...your ui declarations here
END UI_GROUP

UI_SHOW(Group)

UI_HIDE(Group)


----------



## kotori (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Dynamitec @ Tue Aug 15 said:


> Hi Nils,
> These are just some thoughts. Maybe there is even a much smoother way. But it think you understand what this will be good for. You can keep your uncompiled code way smaller!



Hi Benjamin,
Yes, I certainly know what you mean. Actually I've been thinking about adding a preprocessor loop construct which might be the most general solution:
*for* i in (1,2,3,4)`````_{ maybe this could be written 1..4, or 'for' should be called something else }_
``*declare* array<<i>>[100]
``do_something(array<<i>>)
*end for*

_compiled:_ 

*declare* array1[100]
do_something(array1)
*declare* array2[100]
do_something(array2)
*declare* array3[100]
do_something(array3)
*declare* array4[100]
do_something(array4)

One could also allow looping over pairs:
*for* i, action in ((1, foo), (2, bar), (3, myfunc))
``*case* i
````action
*end for*

This would make code easier to write but also possibly harder to read in some cases. I'm not really convinced that having this kind of preprocessor directives acting on multiple lines/blocks is such a good idea for readability. Having constructs such as inline_select and inline_add work on a single line (possibly expanded to many) seems more readable and might prove useful. I will consider that.

Btw. why would you want to generate a separate function for each array, isn't it easier to pass the array as a parameter?

Cheers,
Nils


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

Hi Nils!

Of course it would be easier to pass the array to the function :roll: LOL

I think your loop idea is good, too. But as you said: single terms would be more readable. That's my opinion too.

But: this ui stuff i mentioned would be really great (without having to think how to declare it).


----------



## kotori (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Dynamitec @ Tue Aug 15 said:


> maybe this would be easier to read:
> 
> UI_GROUP Group
> ...your ui declarations here
> ...



Hi Benjamin,
This looks like a very interesting idea. Maybe the name of each group could translate into a boolean variable capturing the shown/hidden state of the group. I think saving the visible-state for controls is generally a good idea. Eg. say that you use a menu to switch between different views and within each view you also hide and show controls. Now when one switches back to a previous view one expects everything to look as it did before, so one needs to save the shown/hidden state of controls within the view whose visiblity may change. A UI_SHOW function would have to take care to show any control declared directly inside the ui_group unconditionally but show controls nested inside other groups only if all groups in the hiearchy are visible. It might also be good to have a UI_SHOWHIDE(group) function which just shows/hides elements depending on whether the group variables (including nested ones) equal 0 or 1.

I wonder if it would be useful to also have a UI_TABPANEL which could have a number of nested ui_groups and the tab panel variables value could indicate the index of the group selected.

Another thing I've thought about is to make it possible to write something like:
````*declare* persistent ui_button $effect_on *with* pos=1,2 text="Active"
as short for:
````*declare* ui_button $effect_on
````make_persistent($effect_on)
````move_control($effect_on, 1, 2)
````set_text($effect_on, "Active")

I have to think more about this. Weighing practicality against readability often isn't easy. Any further input is very welcome.

Nils


----------



## Nickie Fønshauge (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

I generally maintain two arrays, an x_pos and an y_pos array, for each ui item, with an entry for each view. This makes it flexible and easy to change and edit views. And I can have the same ui item appear whereever I want. 

It could look something like:


> declare const GUI_pages := 5
> declare XpressnCC_pos_x[GUI_pages] := (0,2,2,0,0)
> declare XpressnCC_pos_y[GUI_pages] := (0,1,1,0,0)



I like the idea of ui_GROUP, but without the total flexibility to place items anywhere, it wouldn't be of much use to me, I am afraid.


----------



## kotori (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Nickie Fønshauge @ Tue Aug 15 said:


> I generally maintain two arrays, an x_pos and an y_pos array, for each ui item, with an entry for each view. This makes it flexible and easy to change and edit views. And I can have the same ui item appear whereever I want.
> 
> It could look something like:
> 
> ...



Yes, this is very important to take into consideration. I had not really thought much about controls with non-constant positions. Your solution seems very flexible but would also be overkill for scripts with mostly static controls. Maybe if one wrote:
*declare* ui_button $effect_on *with* pos=effect_posx[page],effect_posy[page]
it would work though. Hmm... finding a generally applicable solution seems to be more difficult than I thought at first... :???:


----------



## Dynamitec (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*

``inline_ui_add(titel1, 'ui_label global testtitel1(1,1)', 1, 1, Group1) {Name, Declaration, Position (Position X, Positon Y), Group} 

I had position, too! Look at my example above


----------



## kotori (Aug 15, 2006)

*Re: KScript Editor (1.1beta) with support for import statement and namespaces*



Dynamitec @ Tue Aug 15 said:


> ``inline_ui_add(titel1, 'ui_label global testtitel1(1,1)', 1, 1, Group1) {Name, Declaration, Position (Position X, Positon Y), Group}
> 
> I had position, too! Look at my example above



Yes, you're right :smile:. I didn't mean to imply that I have decided or am leaning towards any special syntax (actually I think that 'with' keyword is a bit ugly). It's all still very open. Extending the normal 'declare' syntax has the benefit of interacting more nicely with the code completion in the editor though (but things like import and family have already messed it up a bit, so...)
Btw. all ui control declarations should probably be implicitly global. I'm not sure if they are currently - I'll have a look at that.


----------

