1. Help with plugin concept
- Posted by "Judith" <camping at txcyber.com> Feb 12, 2004
- 756 views
Experts, I need some advice. I've been working on a plugin for IDE as a test of concept. I've worked up the first plugin which will open a window in Code Editor to view code statements for all windows/controls in the order exw would generate them. It all works very nice as long as in IDE.exw I hard-code the statement "include ViewCodeBase.plg". Since I will never know the plugin file names the users write for IDE or even if user is using any, what I wanted to do was place the plugin files in a subfolder named Plugins. After all the include statements in IDE.exw I wanted to read the Plugins folder and add an include statement for each file name found as follows: --get includes from plugin folder object files files=dir(the_current_dir & "//Plugins") if sequence(files) then if length(files) then for i=1 to length(files) do if not equal("d",files[i][D_ATTRIBUTES]) then include viewCodeBase.plg <=== gets ex.err end if end for end if end if Ha. I forgot Euphoria would not allow the include statement except at the highest level. So am I out of luck? Any idea how to get around the problem? ~judith
2. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 13, 2004
- 662 views
Hello Judith, ---------- > From: Judith Evans <camping at txcyber.com> > To: Eu Forum <EUforum at topica.com> > Subject: RE: Help with plugin concept > > > The corrected routine is below but it doesn't > really matter because it will never work. > > files=dir(the_current_dir & "//Plugins") > if sequence(files) then > if length(files) then > for i=1 to length(files) do > if not equal("d",files[i][D_ATTRIBUTES]) then > --corrected line > include files[i][D_NAME] <=== gets ex.err > ----------------------------------- > end if > end for > end if > end if Try please: -- code include file.e object files sequence PluginS integer P_S PluginS={} files = dir(current_dir()) -- & "//Plugins") -- just to test, any files if sequence(files) then if length(files) then for i=1 to length(files) do if not equal("d",files[i][D_ATTRIBUTES]) then -- include files[i][D_NAME] <=== gets ex.err PluginS &= "include " & files[i][D_NAME] & "\n" --<-- this is a clue end if end for end if end if P_S = open ("plugins.ew", "wb") puts(P_S, PluginS) close(P_S) include plugins.ew -- end of code Why not? Works for me ... Good Luck! Regards, Igor Kachan kinz at peterlink.ru
3. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 13, 2004
- 661 views
Hello Derek, ---------- > From: Derek Parnell <ddparnell at bigpond.com> > Subject: RE: Help with plugin concept > > -----Original Message----- > > From: Igor Kachan [mailto:kinz at peterlink.ru] > > Sent: Friday, 13 February 2004 7:29 PM > > To: EUforum at topica.com > > Subject: Re: Help with plugin concept > > > > > [snip] > > > > > Why not? > > Works for me ... > This and Aku's suggestion only works > for interpreted Euphoria. If you want to compile IDE with *the current set of plugins* it will work compiled. > It will not work for a compiled IDE. Judith doesn't want to compile IDE now, it seems to be, I thinkAnd this way is really good and very good, this way is the Open Source way, MS opens their sources, I heard ... No? Open Windows! > And there is no guarentee that it will work for > future versions as it is an undocumented trick Well, ask Rob to document this trick as sometimes useful, no protests. But it is documented in our list archive, let us read archive, why Rob must document, document and document these tricks? > and new versions of Euphoria might not support it. There is no any reason to abandon the support of the main Euphoria functions. Another thing, if Judith wants to add the plugins feature into her IDE, it may require the detailed specification for the plugins as to the special include files, as you mentioned in your e-mail, Derek, and that work is not trivial, yes. > -- > Derek Regards, Igor Kachan kinz at peterlink.ru
4. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 13, 2004
- 678 views
Hello Matt, ---------- > From: Matt Lewis <matthewwalkerlewis at yahoo.com> > Subject: RE: Help with plugin concept [snipped] > I typically use Open Watcom 1.0, but > it's something like a 50MB download. There is Open Watcom 1.2 on their site now. Many new things and fixes. [snipped] Regards, Igor Kachan kinz at peterlink.ru
5. Re: Help with plugin concept
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 13, 2004
- 699 views
The trick where a Euphoria program modifies an include file just before including it, does not work with the translator or the binder, and in the next release it won't work with the interpreter either. We may eventually need some new language construct in this area, but currently you can easily convert Euphoria code to a .dll, and you can pass Euphoria data (atoms and sequences) to it, and get Euphoria data returned. The only problem is, as with all .dlls, you can't easily share your global variables. You'd have to define a kind of mini-API, that the .dll (plugin) authors would support. You can also, of course, run a separate Euphoria program, via system() etc., and communicate with it via files, or maybe even shared memory. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
6. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 13, 2004
- 679 views
Hello Robert, ---------- > From: Robert Craig <rds at RapidEuphoria.com> > Subject: Re: Help with plugin concept You wrote: > The trick where a Euphoria program modifies an include file > just before including it, does not work with the translator > or the binder, and in the next release it won't work with > the interpreter either. Please, couldn't you explain more detailed what do you mean when you say it does not work and it won't work. What a reason ? It worked and works for me in 2.3 and in 2.4 with ec and bind. Maybe my tests are wrong or incomplete? I run interpreted program to create the resulting include file then run binder or translator with *ready* resulting include file and *it works*. [snipped] Regards, Igor Kachan kinz at peterlink.ru
7. Re: Help with plugin concept
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 14, 2004
- 662 views
Igor Kachan wrote: > Please, couldn't you explain more detailed what do you > mean when you say it does not work and it won't work. > What a reason ? The example code that you posted was... P_S = open ("plugins.ew", "wb") puts(P_S, PluginS) close(P_S) include plugins.ew The above code depends on the open() and puts() taking place before the include is processed. With the current interpreter that's what happens. With the current binder and translator that's not what happens. Rather, the binder and translator process the include file (and all other source code) first. Execution of statements happens later at run-time, when it's too late for the open/puts to have the desired effect. In the next release, with the clearer separation between front-end and back-end, the interpreter will also process the include (and all other source) before it executes any code. It will be simpler this way. I don't think a lot of people are actually using the above "dynamic" include technique, although it has been discussed on this list from time to time. > I run interpreted program to create the resulting include > file then run binder or translator with *ready* resulting > include file and *it works*. That's fine. You are first running a program that creates an include file, then *in a separate step* you are using that include file for translating or binding. However, the users of your program might not have the translator or binder, and even if they did, they might not want to run it. Status: Currently, I have built: - a new front-end (written 100% in Euphoria) - a new back-end for the translator (100% in Euphoria) - a backend for the interpreter (100% in Euphoria) I am working on attaching the current C-written back-end to the new Euphoria-written front-end. I have extensively tested the new translator (100% in Euphoria) and it appears to work flawlessly, as well as being pretty fast. I now have a Euphoria interpreter written 100% in Euphoria. It runs all Euphoria programs perfectly (as far as I know), though it's slower of course. It can even run itself. I tried running itself, running itself, running itself, running a small program, and it worked fine, although it was extremely slow. I'm not sure yet what I'll do with it. It was extremely easy to implement. I can translate the Euphoria-written interpreter to make it faster. I can interpret or translate the new translator. Both can handle the largest programs, such as Judith's IDE. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Help with plugin concept
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 14, 2004
- 686 views
On Fri, 13 Feb 2004 18:58:50 -0500, Robert Craig <rds at RapidEuphoria.com> wrote: >Igor Kachan wrote: > > Please, couldn't you explain more detailed what do you > > mean when you say it does not work and it won't work. > > What a reason ? > >The example code that you posted was... > > P_S = open ("plugins.ew", "wb") > puts(P_S, PluginS) > close(P_S) > > include plugins.ew > >The above code depends on the open() and puts() taking place >before the include is processed. With the current >interpreter that's what happens. With the current >binder and translator that's not what happens. >Rather, the binder and translator process the include file >(and all other source code) first. Execution of statements >happens later at run-time, when it's too late >for the open/puts to have the desired effect. > >In the next release, with the clearer separation between >front-end and back-end, the interpreter will also >process the include (and all other source) >before it executes any code. OK. I have no argument with that. >It will be simpler this way. I don't think a lot of >people are actually using the above "dynamic" include >technique, although it has been discussed on this list >from time to time. True. I cannot however resist suggesting (in pseudo code rather than true or tested Euphoria, you understand): in say misc.e: procedure dynamic_include(sequence filename, sequence contents) integer changed, fn, object d if interpreting or translating then -- see PS changed=0 d=dir(filename) --##I forget the syntax/results## if d!=-1 and d[SIZE]=length(contents) then fn=open(filename,"r") for i=1 to length(contents) do if getc(fn)!=contents[i] then changed=1 exit end if end for close(fn) if changed=0 then return end if end if open(filename,"w") puts(fn,contents) close(fn) puts(1,"dynamic include changed; restarting...") system(command_line()) abort(0) end if end procedure then: dynamic_include(filename,contents) include filename Does that make sense? If so, I don't think it is much work and it will (might) put this issue to bed once and for all. Regards, Pete PS I am undecided whether it would be better for bind/translate to simply not generate any code whatsoever for the dynamic_include() call, or issue a fatal error (/warning) if it detects the program ought to be re-bound/re-translated.
9. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 14, 2004
- 675 views
Robert Craig wrote: [snipped, thanks for the explanation] > In the next release, with the clearer separation > between front-end and back-end, the interpreter > will also process the include (and all other source) > before it executes any code. Complete pass from single pass to two and more passes ... > It will be simpler this way. I don't think a lot of > people are actually using the above "dynamic" include > technique, It seems to be ... > although it has been discussed on this list > from time to time. It is useful ... And with two passes it requires some functional replacement and reorganization of code ... > > I run interpreted program to create the resulting include > > file then run binder or translator with *ready* resulting > > include file and *it works*. > > That's fine. You are first running a program that creates > an include file, then *in a separate step* you are using that > include file for translating or binding. However, the users > of your program might not have the translator or binder, > and even if they did, they might not want to run it. Interpreter, translator, binder will give more equal functional results. Good. Good reason. > Status: > Currently, I have built: > - a new front-end (written 100% in Euphoria) > - a new back-end for the translator (100% in Euphoria) > - a backend for the interpreter (100% in Euphoria) > > I am working on attaching the current C-written back-end > to the new Euphoria-written front-end. > > I have extensively tested the new translator > (100% in Euphoria) and it appears to work flawlessly, > as well as being pretty fast. > > I now have a Euphoria interpreter written 100% in Euphoria. > It runs all Euphoria programs perfectly (as far as I know), > though it's slower of course. It can even run itself. > I tried running itself, running itself, running itself, > running a small program, and it worked fine, although it > was extremely slow. I'm not sure yet what I'll do with it. > It was extremely easy to implement. > > I can translate the Euphoria-written interpreter to make it faster. > I can interpret or translate the new translator. Both can > handle the largest programs, such as Judith's IDE. Thanks Rob. Good Luck. Regards, Igor Kachan kinz at peterlink.ru
10. Re: Help with plugin concept
- Posted by "Juergen Luethje" <j.lue at gmx.de> Feb 14, 2004
- 656 views
Rob wrote: > Igor Kachan wrote: >> Please, couldn't you explain more detailed what do you >> mean when you say it does not work and it won't work. >> What a reason ? > > The example code that you posted was... > > P_S = open ("plugins.ew", "wb") > puts(P_S, PluginS) > close(P_S) > > include plugins.ew > > The above code depends on the open() and puts() taking place > before the include is processed. With the current > interpreter that's what happens. With the current > binder and translator that's not what happens. > Rather, the binder and translator process the include file > (and all other source code) first. Execution of statements > happens later at run-time, when it's too late > for the open/puts to have the desired effect. > > In the next release, with the clearer separation between > front-end and back-end, the interpreter will also > process the include (and all other source) > before it executes any code. > It will be simpler this way. I don't think a lot of > people are actually using the above "dynamic" include > technique, although it has been discussed on this list > from time to time. > >> I run interpreted program to create the resulting include >> file then run binder or translator with *ready* resulting >> include file and *it works*. > > That's fine. You are first running a program that creates > an include file, then *in a separate step* you are using that > include file for translating or binding. However, the users > of your program might not have the translator or binder, > and even if they did, they might not want to run it. <snip> I believe using the next version of the interpreter, programs still can take advantage of a dynamic include technique, when the code is just put into 2 files rather than 1. Then again there are 2 separate steps: ------------------------[ part1.exw ]------------------------ P_S = open ("plugins.ew", "wb") puts(P_S, PluginS) close(P_S) system("exw.exe part2.exw", 2) ------------------------[ part2.exw ]------------------------ include plugins.ew -- Here comes the main program ... ------------------------------------------------------------- This should work with the interpreter 2.5, shouldn't it? Regards, Juergen
11. Re: Help with plugin concept
- Posted by "Igor Kachan" <kinz at peterlink.ru> Feb 14, 2004
- 652 views
Hi Juergen, ---------- > From: Juergen Luethje <j.lue at gmx.de> > Subject: Re: Help with plugin concept [snipped] > <snip> > > I believe using the next version of the interpreter, programs still > can take advantage of a dynamic include technique, when the code is > just put into 2 files rather than 1. Then again there are 2 separate > steps: > > ------------------------[ part1.exw ]------------------------ > P_S = open ("plugins.ew", "wb") > puts(P_S, PluginS) > close(P_S) > system("exw.exe part2.exw", 2) > > ------------------------[ part2.exw ]------------------------ > include plugins.ew > -- Here comes the main program ... > ------------------------------------------------------------- > > This should work with the interpreter 2.5, shouldn't it? Why not? Definitely should with system_exec(). Another way is just .bat file (without system_exec() in the first part) (untested project for 2.5 and better versions :) @ rem -- code of ide.bat @ rem -- part1.exw prepares all plugins as common include file @ exw.exe part1.exw @ rem -- part2.exw executes IDE with plugins @ exw.exe part2.exw @ rem -- end of code This is EU, isn't it ? Rob, your moveRegards, Igor Kachan kinz at peterlink.ru
12. Re: Help with plugin concept
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 14, 2004
- 665 views
Juergen Luethje wrote: > I believe using the next version of the interpreter, programs still > can take advantage of a dynamic include technique, when the code is > just put into 2 files rather than 1. Then again there are 2 separate > steps: > > ------------------------[ part1.exw ]------------------------ > P_S = open ("plugins.ew", "wb") > puts(P_S, PluginS) > close(P_S) > system("exw.exe part2.exw", 2) > > ------------------------[ part2.exw ]------------------------ > include plugins.ew > -- Here comes the main program ... > ------------------------------------------------------------- > > This should work with the interpreter 2.5, shouldn't it? Yes. Igor Kachan wrote: > Another way is just .bat file > (without system_exec() in the first part) > (untested project for 2.5 and better versions > > @ rem -- code of ide.bat > @ rem -- part1.exw prepares all plugins as common include file > @ exw.exe part1.exw > @ rem -- part2.exw executes IDE with plugins > @ exw.exe part2.exw > @ rem -- end of code > > This is EU, isn't it ? Yes, that will work too. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
13. Re: Help with plugin concept
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 14, 2004
- 683 views
Pete Lomax wrote: > I cannot however resist suggesting (in pseudo code rather than true or > tested Euphoria, you understand): > > in say misc.e: > procedure dynamic_include(sequence filename, sequence contents) > integer changed, fn, > object d > if interpreting or translating then -- see PS > changed=0 > d=dir(filename) --##I forget the syntax/results## > if d!=-1 and d[SIZE]=length(contents) then > fn=open(filename,"r") > for i=1 to length(contents) do > if getc(fn)!=contents[i] then > changed=1 > exit > end if > end for > close(fn) > if changed=0 then return end if > end if > open(filename,"w") > puts(fn,contents) > close(fn) > puts(1,"dynamic include changed; restarting...") > system(command_line()) > abort(0) > end if > end procedure > > then: > dynamic_include(filename,contents) > include filename > > Does that make sense? > If so, I don't think it is much work and it will (might) put this > issue to bed once and for all. > > Regards, > Pete > PS I am undecided whether it would be better for bind/translate to > simply not generate any code whatsoever for the dynamic_include() > call, or issue a fatal error (/warning) if it detects the program > ought to be re-bound/re-translated. That's an interesting idea. A bit convoluted though. I think I'll wait and see if anyone starts screaming about this issue when the new interpreter is released. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
14. Re: Help with plugin concept
- Posted by "Kat" <gertie at visionsix.com> Feb 14, 2004
- 751 views
On 14 Feb 2004, at 13:45, Robert Craig wrote: > > > Pete Lomax wrote: > > I cannot however resist suggesting (in pseudo code rather than true or > > tested Euphoria, you understand): > > > > in say misc.e: > > procedure dynamic_include(sequence filename, sequence contents) > > integer changed, fn, > > object d > > if interpreting or translating then -- see PS > > changed=0 > > d=dir(filename) --##I forget the syntax/results## > > if d!=-1 and d[SIZE]=length(contents) then > > fn=open(filename,"r") > > for i=1 to length(contents) do > > if getc(fn)!=contents[i] then > > changed=1 > > exit > > end if > > end for > > close(fn) > > if changed=0 then return end if > > end if > > open(filename,"w") > > puts(fn,contents) > > close(fn) > > puts(1,"dynamic include changed; restarting...") > > system(command_line()) > > abort(0) > > end if > > end procedure > > > > then: > > dynamic_include(filename,contents) > > include filename > > > > Does that make sense? > > If so, I don't think it is much work and it will (might) put this > > issue to bed once and for all. > > > > Regards, > > Pete > > PS I am undecided whether it would be better for bind/translate to > > simply not generate any code whatsoever for the dynamic_include() > > call, or issue a fatal error (/warning) if it detects the program > > ought to be re-bound/re-translated. > > That's an interesting idea. > A bit convoluted though. > I think I'll wait and see if anyone starts > screaming about this issue when the new interpreter > is released. <scream><scream><scream><scream><scream><scream><scream><scre am><scream><scream><scream><scream><scream><scream><scream>< scream><scream> It's things like this, and executing vars and such, that made me drop Eu for a number of things. You could just as easily encorporate dynamic includes as: var = fget("filename.e") function1 = var[50..2000] function2 = var[2010..3000] or execute(var) But heck, i have been screaming for these things for years, i am now using PHP to get around Eu deficiencies, especially on nix boxes. You may be deciding on what the language can do based on the number of people asking for them, but you won't hear from those who just decide you won't add them anyhow, and politely quietly move on to other languages. At least i said something first, repeatedly. People won't use it if they must first ask for features, wait years, and then see if they get the features. Or get Karl to add it to his language in a few days. Kat
15. Re: Help with plugin concept
- Posted by "Patrick Barnes" <mistertrik at hotmail.com> Feb 14, 2004
- 665 views
The only problem with this method of plugins.... The resulting IDE is still monolithic... let me explain: If you load/install a 3rd party plugin for your ide, that is missing an external include, or has bugs... Then prg2.exw, or whatever you call it, will crash. And the user will not necissarily know what has happened, and unless the plugin installer-loader is separate from the main ide, there is not a user-level way to unload it. I know that the trickery that you have described will work, as long as all the plugins are perfectly working. However, for a more robust ide, the idea of dll's and an API is much better, as it allows for some kind of "This plugin could not load" message, and for the IDE to continue functioning. Unless of course, Rob allowed an "include(sequence file)" function, that returned either 0 for success, or an error code showing how the include failed... It's ok Rob, maybe for Eu2.6 ;oP MrTrick >From: Robert Craig <rds at RapidEuphoria.com> >Reply-To: EUforum at topica.com >To: EUforum at topica.com >Subject: Re: Help with plugin concept >Date: Sat, 14 Feb 2004 12:50:59 -0500 > > >Juergen Luethje wrote: >>I believe using the next version of the interpreter, programs still >>can take advantage of a dynamic include technique, when the code is >>just put into 2 files rather than 1. Then again there are 2 separate >>steps: >> >>------------------------[ part1.exw ]------------------------ >> P_S = open ("plugins.ew", "wb") >> puts(P_S, PluginS) >> close(P_S) >> system("exw.exe part2.exw", 2) >> >>------------------------[ part2.exw ]------------------------ >> include plugins.ew >> -- Here comes the main program ... >> >>This should work with the interpreter 2.5, shouldn't it? > >Yes. > >Igor Kachan wrote: >>Another way is just .bat file (without system_exec() in the first part) >>(untested project for 2.5 and better versions >> >>@ rem -- code of ide.bat >>@ rem -- part1.exw prepares all plugins as common include file >>@ exw.exe part1.exw >>@ rem -- part2.exw executes IDE with plugins >>@ exw.exe part2.exw >>@ rem -- end of code >> >>This is EU, isn't it ? > >Yes, that will work too. > >Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > >TOPICA - Start your own email discussion group. FREE! > >
16. Re: Help with plugin concept
- Posted by "Juergen Luethje" <j.lue at gmx.de> Feb 15, 2004
- 671 views
Patrick Barnes wrote [quotations rearranged]: >> From: Robert Craig >> Date: Sat, 14 Feb 2004 12:50:59 -0500 >> >> Juergen Luethje wrote: >>> I believe using the next version of the interpreter, programs still >>> can take advantage of a dynamic include technique, when the code is >>> just put into 2 files rather than 1. Then again there are 2 separate >>> steps: >>> >>> ------------------------[ part1.exw ]------------------------ >>> P_S = open ("plugins.ew", "wb") >>> puts(P_S, PluginS) >>> close(P_S) >>> system("exw.exe part2.exw", 2) >>> >>> ------------------------[ part2.exw ]------------------------ >>> include plugins.ew >>> -- Here comes the main program ... >>> >>> This should work with the interpreter 2.5, shouldn't it? >> >> Yes. >> >> Igor Kachan wrote: >>> Another way is just .bat file (without system_exec() in the first part) >>> (untested project for 2.5 and better versions >>> >>> @ rem -- code of ide.bat >>> @ rem -- part1.exw prepares all plugins as common include file >>> @ exw.exe part1.exw >>> @ rem -- part2.exw executes IDE with plugins >>> @ exw.exe part2.exw >>> @ rem -- end of code >>> >>> This is EU, isn't it ? >> >> Yes, that will work too. > > > The only problem with this method of plugins.... > > The resulting IDE is still monolithic... let me explain: > > If you load/install a 3rd party plugin for your ide, that is missing an > external include, or has bugs... > > Then prg2.exw, or whatever you call it, will crash. And the user will not > necissarily know what has happened, and unless the plugin installer-loader > is separate from the main ide, there is not a user-level way to unload it. > > I know that the trickery that you have described will work, as long as all > the plugins are perfectly working. However, for a more robust ide, the idea > of dll's and an API is much better, as it allows for some kind of "This > plugin could not load" message, and for the IDE to continue functioning. > > Unless of course, Rob allowed an "include(sequence file)" function, that > returned either 0 for success, or an error code showing how the include > failed... It's ok Rob, maybe for Eu2.6 > > ;oP Derek already wrote something about different types of plugins. When a plugin is a DLL, a serious bug also can cause a program crash. As I understand it, "API" is a general expression, i.e. this term does not only refer to DLLs. I think any program, that wants to utilize 3rd party plugins, should provide an API, regardlesss what way the plugins are technically implemented. For example Judith can say, that any plugin should have a function called plugin_id() that returns say Judith's birthday times PI or whatever. If the function returns a different value, the main program can raise a "File 'xyz' is not a proper plugin." message. If the main program calls a routine in the plugin that does not exist, the program will crash, regardless wether the plugin is an interpreted EXW file, or a DLL. In this situation a crash can be prevented by using the routine_id() technique, and this will work with interpreted EXW files as well as with DLLs. Please notice that these are just some general considerations. I don't want to recommend anything concerning plugins, because I've little experience in this field. Regards, Juergen