659 replies to this topic

[Galapo]

For giving parameters : "#$q#$s#$q-SP:%StartParameters%"

OK, great, thanks for that. I'll change the api back and test. Maybe this should be documented in the api.script?

Thanks,
Galapo.

[pedrole15]

The parameter #4 is not good like this because it is specific to BuildModel and can't be tranlate for other Project like VistaPE
So I propose a new Function Add_Options we call it before Add_Shortcut
In Add_Shortcut we replace the #4 by a variable %OptionShortcut%

//------------Variables--------In Script.Projet-------For Function Add_Options----------%OptionShortcut%=Add_Options=Run,%API%,Shortcut_Options//------------Function Add_Options-----In Api.Script------------------------------------[Shortcut_Options]Set,"%shortcut_Parameters%",""Set,"%shortcut_IconFile%",""If,#1,NotEqual,,Set,"%shortcut_Parameters%","#$q#$s#$q-SP:#1"If,#2,NotEqual,,Set,"%shortcut_IconFile%","#$q#$s#$q-SF:#$pProgramFiles#$p\%programFolder%\#2#$q#$s#$q-SI:0"System,RefreshVarsSet,"%OptionShortcut%","%shortcut_Parameters%%shortcut_IconFile%"System,RefreshVars//--------------------------------------------------------------------------------------// Or like this with start mode but a little more long ://--------------------------------------------------------------------------------------[Shortcut_Options]Set,"%shortcut_Parameters%",""Set,"%shortcut_IconFile%",""Set,"%shortcut_Show%",""If,#1,NotEqual,,Set,"%shortcut_Parameters%","#$q#$s#$q-SP:#1"If,#2,NotEqual,,Set,"%shortcut_IconFile%","#$q#$s#$q-SF:#$pProgramFiles#$p\%programFolder%\#2#$q#$s#$q-SI:0"System,RefreshVarsRun,%API%,ShowOptions_#3Set,"%OptionShortcut%","%shortcut_Parameters%%shortcut_IconFile%%shortcut_Show%"System,RefreshVars[ShowOptions_][ShowOptions_1]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWNORMAL"System,RefreshVars[ShowOptions_2]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWMINIMIZED"System,RefreshVars[ShowOptions_3]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWMAXIMIZED"System,RefreshVars[ShowOptions_4]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_HIDE"System,RefreshVars

What do you think ?

[pscEx]

The parameter #4 is not good like this because it is specific to BuildModel and can't be tranlate for other Project like VistaPE
So I propose a new Function Add_Options we call it before Add_Shortcut
In Add_Shortcut we replace the #4 by a variable %OptionShortcut%

//------------Variables--------In Script.Projet-------For Function Add_Options----------%OptionShortcut%=Add_Options=Run,%API%,Shortcut_Options//------------Function Add_Options-----In Api.Script------------------------------------[Shortcut_Options]Set,"%shortcut_Parameters%",""Set,"%shortcut_IconFile%",""If,#1,NotEqual,,Set,"%shortcut_Parameters%","#$q#$s#$q-SP:#1"If,#2,NotEqual,,Set,"%shortcut_IconFile%","#$q#$s#$q-SF:#$pProgramFiles#$p\%programFolder%\#2#$q#$s#$q-SI:0"System,RefreshVarsSet,"%OptionShortcut%","%shortcut_Parameters%%shortcut_IconFile%"System,RefreshVars//--------------------------------------------------------------------------------------// Or like this with start mode but a little more long ://--------------------------------------------------------------------------------------[Shortcut_Options]Set,"%shortcut_Parameters%",""Set,"%shortcut_IconFile%",""Set,"%shortcut_Show%",""If,#1,NotEqual,,Set,"%shortcut_Parameters%","#$q#$s#$q-SP:#1"If,#2,NotEqual,,Set,"%shortcut_IconFile%","#$q#$s#$q-SF:#$pProgramFiles#$p\%programFolder%\#2#$q#$s#$q-SI:0"System,RefreshVarsRun,%API%,ShowOptions_#3Set,"%OptionShortcut%","%shortcut_Parameters%%shortcut_IconFile%%shortcut_Show%"System,RefreshVars[ShowOptions_][ShowOptions_1]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWNORMAL"System,RefreshVars[ShowOptions_2]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWMINIMIZED"System,RefreshVars[ShowOptions_3]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_SHOWMAXIMIZED"System,RefreshVars[ShowOptions_4]Set,"%shortcut_Show%","#$q#$s#$q-SS:SW_HIDE"System,RefreshVars

What do you think ?

Before giving my reply, a small complain:I hate these oversized post: They are difficult to read and more difficult to answer.
When posting, people should look at the preview and use a code box if necessary!

Now the answer:
I created the fourth combined argument baecause at that time WB accepted only 4 arguments. Now we have 9 and I suggest
to change buildModel to use the enlarged number by splitting the current 4th arg.

Peter

[pedrole15]

I hate these oversized post: They are difficult to read and more difficult to answer.
When posting, people should look at the preview and use a code box if necessary!

So it's better to attach the file

Now we have 9 and I suggest to change buildModel to use
the enlarged number by splitting the current 4th arg.

Thank for the remark

[allanf]

I have a couple of issues with the creation of start menu shortcuts with the api in its current form. The example:

1. With the current api, a shortcut cannot be placed in the root of the programs folder in the start menu.
Add_Shortcut,StartMenu would place the shortcut in the folder from which the script is run, eg 'Productivity'. Hence I suggest
the adding of a fixed arguement if such a shortcut is desired. Something like: Add_Shortcut,StartMenu,StartMenu or
Add_Shortcut,StartMenu,StartMenuRoot.

2. A second related issue is that if a folder name is specified -- eg Add_Shortcut,StartMenu,%ProgramFolder% -- this folder cannot
be placed in the 'Productivity' folder unless this is explicitly specified as such: Add_Shortcut,StartMenu,Productivity\%ProgramFolder%.
But what if someone wants to place the script in a folder with a different name? They're stuck with the naming unless they edit the script.
Add_Shortcut,StartMenu,%Scriptdir%\%ProgramFolder% does not work (obviously), but possibly something of the sort should be allowed?

Regards,
Galapo.

@pedrole15
IMHO, when no "Category" (i. e. Sub-StartMenu Folder) is mentioned as parameter #2 in "Add_Shortcuts,#1,#2", it is better to place the
Shortcut in the "root of the Programs Folder"... similar to Galapo's comment. I am not sure about the following in your New API.
VistaPE:

[AddShortcut_StartMenu]

If,#1,Equal,"",StrFormat,filename,%Scriptdir%,#1

For me with VistaPE, the Sub-StartMenu becomes "VistaPE-Beta...".
I would prefer, as default when "Category" is blank:

If,"#1",Equal,"",Set,["Category/Sub-Menu Folder Variable"],"%ProgramTitle%.lnk"

... seems more intuitive to me.

Here is a small Script for Editor2 v.2.5.0.5. Note: The Script is designed as "stand-alone" because it re-creates "shortcut.inf", thus removing other
shortcuts... recommend run with "Build" and "Finalize" Scripts plus Shell(s).



It calls "ExtractAllFiles" - to extract and copy the encoded program. I have tested the Script only with
VistaPE-Beta; "script.project" v.009; 22.06.2007. Tested in VirtualBox for "RunFromRam", "RunFromCD_Standard" (CD-Drive:\Programs folder),
and "RunFromCD_Custom" (CD-Drive:\Editor2 folder). It creates four Shortcuts: one Desktop, and three StartMenu.

Attached is Build Log for Editor2 Script only.

All shortcuts are working as expected - with icon and little pop-up of description (tooltips?).


I just noticed the recent posts...

Remember that VistaPE's "shortcut.inf" accepts only seven arguments. Seven is enough for shortcuts!

BTW, can we access the primary root of the StartMenu. "shortcut.inf" seems only for the "Programs" menu.

Also note: in the forum, the scrolling Code Box does not contain line-breaks for copying and pasting... pastes as a single long line.

However, Wrap in Code Tags does contain the required Line-breaks when pasting into .txt or .script.

[pedrole15]

1. With the current api, a shortcut cannot be placed in the root of the programs folder in the start menu. Add_Shortcut,StartMenu would place the shortcut in the folder from which the script is run, eg 'Productivity'. Hence I suggest the adding of a fixed arguement if such a shortcut is desired. Something like: Add_Shortcut,StartMenu,StartMenu or Add_Shortcut,StartMenu,StartMenuRoot.

Add_Shortcut,StartMenu,.
Just a point for #2 will place the shortcut in the root of the programs folder in the start menu

2. A second related issue is that if a folder name is specified -- eg Add_Shortcut,StartMenu,%ProgramFolder% -- this folder cannot be placed in the 'Productivity' folder unless this is explicitly specified as such: Add_Shortcut,StartMenu,Productivity\%ProgramFolder%. But what if someone wants to place the script in a folder with a different name? They're stuck with the naming unless they edit the script. Add_Shortcut,StartMenu,%Scriptdir%\%ProgramFolder% does not work (obviously), but possibly something of the sort should be allowed?

The api must be simple and fast
We can't make all with the api , do it by the standard scripting
If we add too much things to the api it will be too slow and become inusable

[pedrole15]

@Nuno
I have trouble in Add_Shortcut with this:
If,#3,NotEqual,,Set,"%My_Shortcut_EXE%","#3"
If,#3,NotEqual,,StrFormat,path,#3,%My_Shortcut_FOLDER%
We are forced to specify a full path or it didn't work with VistaPE
Or must do like this ,but give choice to only select a program
from same or sub folder as the main program
If,#3,NotEqual,,Set,"%My_Shortcut_EXE%","#$pProgramFiles#$p\%programFolder%\#3"

[pedrole15]

Hi, all
I have converted the last api from LiveXP to VistaPE Beta
Look at my sigature, you will find the script.project modified and my last log file
I have marked in the file the 3 modified zone
Tested with Overdisk and some other App Script
Get 10 error but just for Hearts.script and mitec_msi.script with the function Require_files

[Brito]

Hi, all
I have converted the last api from LiveXP to VistaPE Beta
Look at my sigature, you will find the script.project modified and my last log file
I have marked in the file the 3 modified zone
Tested with Overdisk and some other App Script
Get 10 error but just for Hearts.script and mitec_msi.script with the function Require_files

Congratulations!

I'm really happy to hear these news!!

[Galapo]

Add_Shortcut,StartMenu,.
Just a point for #2 will place the shortcut in the root of the programs folder in the start menu

I'd missed that -- thanks!
Galapo.

[Galapo]

2. A second related issue is that if a folder name is specified -- eg Add_Shortcut,StartMenu,%ProgramFolder% -- this folder cannot be placed in the 'Productivity' folder unless this is explicitly specified as such: Add_Shortcut,StartMenu,Productivity\%ProgramFolder%. But what if someone wants to place the script in a folder with a different name? They're stuck with the naming unless they edit the script. Add_Shortcut,StartMenu,%Scriptdir%\%ProgramFolder% does not work (obviously), but possibly something of the sort should be allowed.

I've gotten around my issue, eg:

[Interface]pCheckBox1="Add start menu shortcuts",1,3,43,72,168,18,TruepTextBox1="Start menu folder (blank for none):",1,0,43,112,168,21,Productivity\AutoItpBevel1=pBevel1,1,12,26,58,198,92[process]...If,%pCheckBox1%,Equal,True,Add_Shortcut,StartMenu,%pTextBox1%

Works fine -- no script modification by user necessary and best of all the api left alone.

Regards,
Galapo.

[MedEvil]

One question is nagging me about this API thing for a few days now.
Why are we developing it?

The way it is structured, it will make scripting things easier for people who hand script masterpieces.
But for those the available functions are too limited and besides that, the api is mostly used in simple generator produced scripts.
But for generator produced scripts there is no reason for an api. Just a switch is needed that would enable different sections in a script dependent on the main project.
This way scripts could be as complicated as we like without sacrificing speed.

[Brito]

Your thoughts are correct - but I think you're missing a very important point - app scripts mean project independent scripts.

API implies that future app scripts are not dependent on liveXP, VistaPE, Longhorn or whatever project that supports this API - and this way we have a very simple set of rules that make your script valid and flexible to be used within the next years without any changes.

We can always make wb faster, optimize the codings as needed - but it's preferable to change a single api.script file rather than rewriting/modifying hundreds of scripts to suit a single project.

Do you remember the standard project which was later replaced with buildmodel method and all the doubts posted from users who just want to create a shortcut on a specific project?

Or having the same scripts written specifically for nativeEx and another one for VistaPE or even VistaCE?


These are some of the reasons why I personally avoid writing any app script that expects to be use a specific project even if static project scripts are faster to be processed.

[pscEx]

Or having the same scripts written specifically for nativeEx and another one for VistaPE or even VistaCE?

That's wrong.
Some time ago (before this API discussion started) I already explained it here. But nobody seems to recognize / realize it.

Let's repeat: I needed 15 minutes to implement the buildModel shortcut mechanism into VistaPE.
After that -due to shortcut- every nativeEx based script, without any change, could be included in VistaPE.

Concerning VistaCE:
If somebody starts a new project, and takes buildModel into care from the very beginning, there is no 'install time'.

But I have different questions:

How is the VistaPE special 'Start from RAM' handled by the API for non-Vista projects?
What about the API for Reactos, WBXPE, and others?

What is with Thunn's 'NativePE' project?
The project is very sophisticated, has best orgnized GUI and some other features which nativeEx_barebone and LiveXP do not have.
The design is
And he uses the buildModel method.
If NativePE scripts should be used for VistaPE:

• Should Thunn spend several hours to change a large amount of scripts to use the API
• Or should somebody spend 15 minutes to do some VistaPE changes?

As to be seen, I fully agree to MedEvil's post

Peter

[pedrole15]

Let's repeat: I needed 15 minutes to implement the buildModel shortcut mechanism into VistaPE.
After that -due to shortcut- every nativeEx based script, without any change, could be included in VistaPE.

That is right , I have tested and work very well

Your question give the response : use BuildModel in VistaPE
That will make much esay to make an universal API, but for shortcut only
So I think we must have a common Api for making script compatible with different project

[pedrole15]

@psc
Is it possible that BuilModel write the %Workdir% variable in Script.project
How many time we use [ IniRead,"%ProjectInfo%","TargetPaths","Program_Files",%workDir% ] ?
For Api it is important because for each function we need it
for one script we can use it 10 time and i think that slow the process

[Brito]

I'm not against using buildmodel but this is something that shouldn't be fixed to a single way of being done, liveXP is also using buildmodel underneath api.script - but are you really going to adapt buildmodel to every possible project in future years?

Imagine other projects where we wish to run the scripts on the host windows itself or even think about any other platform like mac/linux or even more sofisticated way of creating shortcuts that might appear along the way by any other developer.

There is also no need to change any of the existing app scripts that use static methods - both methods can work good enough.

If the option to boot from RAM from vistaPE, nativePE, bartPEcore, wbXP and any other project is so urgent I volunter to bring API support to all of them over september - all routines are already present, it's only a matter of adapting the already existent functions inside each project.


This is also meant to provide a simple to understand set of common functions that do very basic and important tasks - create a folder where to place the files inside a script, add a shortcut and unpack all files inside this folder, so far little more than this is needed for most apps already available on the download section.


You know it's not meant to work on every possible case nor it gives so many headaches to port api.script to other projects - it's just a method that everyone can tweak and improve in the future long after we even remember when these scripts were first written..


Simple and flexible - take a look on the already available scripts..

[pscEx]

If the option to boot from RAM from vistaPE, nativePE, bartPEcore, wbXP and any other project is so urgent I volunter to bring API support to all of them over september - all routines are already present, it's only a matter of adapting the already existent functions inside each project.

@Nuno,
Please understand my question as a little bit kidding.
What I wanted: (same like MedEvil meant)
We should not invent the wheel for the second time.

• For shortcuts, buildModel covers every project. If in a new project, buildModel is missing something, it can be added.
• For other issues, we carefully have to decide to every issue, how to work
• but we should not try to force to have an API, just to have it

The reason, that I do not agree to the current API functionality:
A script has to define its own special values like %ProgramTitle%, %ProgramEXE%, %ProgramFolder%
I do not know any well accepted program, which asks the parent task for some hardcoded values.

If WinBuilder wants to be accepted as 'first class', we should not use such unprofessional constructions.

Peter

[pscEx]

@psc
Is it possible that BuilModel write the %Workdir% variable in Script.project
How many time we use [ IniRead,"%ProjectInfo%","TargetPaths","Program_Files",%workDir% ] ?
For Api it is important because for each function we need it
for one script we can use it 10 time and i think that slow the process

No problem, but that would increase the (already big) number of variables > again some time more when loading the project.

@Nuno: Your opinion?

Peter

[MedEvil]

Simple and flexible - take a look on the already available scripts..

Nuno, sorry, but if you wanna convince someone of the advantages of the api idea don't mention the api.scripts.
I personly consider them sub standart, to put it nicely.

[pedrole15]

No problem, but that would increase the (already big) number of variables > again some time more when loading the project.

Hi,Peter
For decrease the (already big) number of variables and not disturb proffessional people like you
We can just add in script.project this

%API%=%projectdir%\Basic\Build\api.script

Api_Start=Run,%API%,Func_Init_Api

and in the api.script this

[Variables]

%HIVE_BASE%=HKLM

... and all variables

[Func_Init_Api]

AddVariables,%API%,"Variables"

IniRead,"%ProjectInfo%","TargetPaths","Program_Files",%workDir%

System,RefreshVars

Each script need the api must initialise the api by the command Api_Start
I have tested and it is not more slow

[Brito]

Well..

How would I run medEvil's Opera script on VistaPE without any changes?

Writing a new script is fine, but how would I repeat the same action to all the other scripts on my archive? Would I try to port them also?

What if I don't really want to create a PE boot disc and prefer to create an unattended boot disc and use the available app scripts in a post install stage?

What if I just want to run a script on my own machine and see how the program inside works?

And if for some crazy reason I start using xoblite, bblean, nu2menu, XPE shortcuts or anything else that appears along the road?

I really prefer to have an app script that can run without changes on any project than having to write specific sections for each project type or having to learn everything from scratch and create new scripts everytime a project changes.

Does anyone truly needs to re-learn how to write app scripts that only work with a single type of project?




Why complicate these scripts when they should be simple?


-------------------------------------------------

Peter and MedEvil, I really don't understand the reasons for these complaints.

Most arguments you've both raised are simply strange to read since I'm sure you probably know several possible solutions and optimizations to each one of these things that annoy you so much.

It is very important to have project agnostic app scripts - the sort of scripting that can really allow these apps to be recycled and reused by anyone else in any other project in the future.

If you don't like these works then please suggest a better way to add missing file dependencies, add registry keys, create shortcuts, run self-extractable files or auto-setup routines and please keep them in a language simple yet flexible enough to work on all current projects and even the next ones to cross your mind, properly publish them and expand as necessary so that other people can also enjoy them.


Please continue using builmodel or any other specific method you prefer to create shortcuts on your scripts especially if you don't like the results - nobody is forcing you to use this set of functions, they are simply made available to help everyone on the scripting part whenever possible.

MedEvil - wb072a has little changes from 072, only edited the default web servers list and this binary is available from the download page on http://boot-land.net/winbuilder - please try it and download all scripts inside the liveXP server. Most app scripts you find inside are already written using API, I really recomend you to try them and take a look to see how things were done and can surely be improved in the future following the latest talks here (the api.script for liveXP already has some code sections that were very optimized by Pedrole15 but weren't yet added as default)


-------------------------------


Peter, the number of variables inside a script.project is quite considerable - there is also a need for cleaning a lot of variables that are only used by some scripts on the initial build steps and this impacts on the overall app scripts which don't really need them.

[Variables]
%ScriptLog%=%ProjectDir%\Basic\Build\ScriptLog.Script
%AutoRunScript%=%ProjectDir%\Basic\Build\autoruns.Script
%ProcessUPX%=%ProjectDir%\Tools\processUPX.Script
%AutoRunFile%=%TargetDir%\I386\system32\autorun.cmd
%BuildModelScript%=%ProjectDir%\Basic\Build\4 - buildModel.Script
%ProjectInfo%=%ProjectDir%\ProjectInfo.ini
%EmptyHive%=%ProjectDir%\Basic\Build\EmptyHive.Script
%PreISOScript%=%ProjectDir%\Temp\Data\ISO-PreProcess.Script.txt
%PostISOScript%=%ProjectDir%\Temp\ISO-PostProcess.Script.txt
%shcTemp%=%ProjectDir%\Temp\shcTemp.ini
%HoJoPEexe%=HoJoPE.exe
%HoJoPEdir%=%ProjectDir%\Basic\Prebuild
%Debug%=0
%HoJoPELevel%=2
%RAMDriveLetter%=B:
%SettingsDrive%=B:
%ClearTarget%=1
%justCopy%=0
%RegTyp%=0x1
%bootfix%=True
%ActiveShell%=D:\WinBuilder\wb4\Projects\LiveXP\Basic\Shells\Explorer.Script
%ExplorerShortcut%=shc-model
%XobDir%=C:\WinBuilder\wb2\Target\LiveXP\Programas\Xoblite
%api%=%projectdir%\Basic\Build\api.script
Add_Shortcut=Run,%api%,AddShortcut
Require_File=run,%api%,expand_file
Unpack=Run,%api%,depack
%source_win%=%SourceDir%\I386
%target_win%=%targetDir%\I386
%source_sys%=%SourceDir%\I386
%target_sys%=%TargetDir%\I386\System32
%HIVE_HKLM%=%targetDir%\I386\System32\setupreg.hiv
%HIVE_HKCU%=%TargetDir%\i386\System32\Config\default
%HIVE_HKU%=%targetDir%\I386\System32\Config\software
%HIVE_BASE%=HKLM
%reg_temp%=wb-hive
%reg%\=%reg_temp%\
hive_load=run,%api%,reg_hiveload
hive_unload=run,%api%,reg_hiveunload
reg_add=RegWrite,"%HIVE_BASE%"
associate_file=run,%api%,do_associate

If the initial build scripts could write these build variables inside a specific section inside a build file and leave script.project clear from these variables then it would surely optimize script processing for all app scripts.

The variables defined for api scripts already define most common actions possible to do inside windows platforms - just missing the add service or register OCX/DLL file, other than that they can already be used to perform most needed functions to add a program to a project and they don't slow down my project processing considerably.

I also don't think that static paths for dynamic locations should be written inside script.project - what happens when we move a project to another directory or a source with another language?

This was the reason why iniread was used instead of predefined location - but with some luck this can also be modified inside nativeEx - it's all a matter of imagination to find a flexible solution isn't it?

[pscEx]

How would I run medEvil's Opera script on VistaPE without any changes?

How would you run (using API) medEvil's Opera script on VistaPE without any changes?
How to get the value of %Workdir% using API
If, for a test, you hardcode %WorkDir% in the opera script and do the VistaPE changes i suggested, it runs.

And if for some crazy reason I start using xoblite, bblean, nu2menu, XPE shortcuts or anything else that appears along the road?

As I explained, every of those shell scripts only has to

• Define itself as %ActiveShell%
• have a section [Add-Shortcut] which has as #1 a file name with an intermediate shortcut description.

Sample file content

[Created]

   Program=shortcutParse

   Version=1.1.0

   Copyright=(C) 2007 Peter Schlang

   Date=2007-Aug-13 094641015

   [Shortcut]

   targetDir=C:\Dokumente und Einstellungen\Peter\Desktop\WB Archiv\Beta8\Target\LiveXP

   shortCutName=CD-Opera

   shortCutType=DE

   shortCutLocation=

   shortCutExe=%ProgramFiles%\CD-Opera\Opera.exe

   shortCutToolTip=

   shortCutParameters=

   shortCutShow=

   shortCutDir=%ProgramFiles%\CD-Opera

   shortCutHotKey=

   shortCutIconFile=

   shortCutIcon=0

As you remember, nativeEx_barebone contains as a sample the xoblite script.
Here all nativeEx_barebone apps show shortcut menus when the Xoblite shell is used.
I would like to see the same result when using the API. I think it will take hours, maybe days to make the API Xoblite ready.

Peter, the number of variables inside a script.project is quite considerable - there is also a need for cleaning a lot of variables that are only used by some scripts on the initial build steps and this impacts on the overall app scripts which don't really need them.

If the initial build scripts could write these build variables inside a specific section inside a build file and leave script.project clear from these variables then it would surely optimize script processing for all app scripts.

The variables defined for api scripts already define most common actions possible to do inside windows platforms - just missing the add service or register OCX/DLL file, other than that they can already be used to perform most needed functions to add a program to a project and they don't slow down my project processing considerably.

I also don't think that static paths for dynamic locations should be written inside script.project - what happens when we move a project to another directory or a source with another language? huh.gif

This was the reason why iniread was used instead of predefined location - but with some luck this can also be modified inside nativeEx - it's all a matter of imagination to find a flexible solution isn't it?

I'll work on that.

Peter

[MedEvil]

@Nuno
You've seem to forgotten that we (Peter) already invented a way to use different shells without problems with our scripts in march or april. So no need to reinvent the wheel here, imo.

Thanks for the link to WB072a, but Peter already supplied it to me.

Last i would like to ask something off topic, cause i can't reach you by PM.
Where have all the scripts gone that used to be in Downloads, when it was still sorted by categories like browser and stuff?

[Brito]

@Nuno
You've seem to forgotten that we (Peter) already invented a way to use different shells without problems with our scripts in march or april. So no need to reinvent the wheel here, imo.

Yes, this is the reason why api.script from nativeEx is using buildmodel - but keep in mind that this api is also used for registry operations, copy/expand needed dependencies and unpack files to the target programs folder - therefore it's also shell/registry/folder location agnostic since buildmodel (on liveXP) will know best how the shortcut needs to be created as it will also adapt on other projects.

Last i would like to ask something off topic, cause i can't reach you by PM.
Where have all the scripts gone that used to be in Downloads, when it was still sorted by categories like browser and stuff?

Please send any questions you have to mail@nunobrito.eu - but it might take a while to answer back sometimes.

The old download section is still active, was only removed from visible sight, I don't remember the link and my laptop batery won't last more than 2 minutes, please find a link pointing to a file inside this old section and you'll get inside the navigation tree again to see all older files.