I've got a few ideas which I think could help improve upon WinBuilder.

1) Use of the SciTE engine for text editing inside WinBuilder ( http://delphisci.sourceforge.net )
* Everybody loves it.
* Its has Text Find, Custom Function Popups, and Custom Text Coloring, built-in

2) When an error occurs
* Let the user know an error occured, and on what line of what file
* Optionally: Bring the user to the line of the file where the error occured

3) A new way to handle scripts
Container File (ZIP file)
|- Script file (Similar to the current script format)
|- "root" directory (Contains files destined to be copied into the root of the app drive)

That "root" directory can be a mirror of what the script writer wants on the final build's app drive.
Everything within "root\WINDOWS" directory will need to be redirected to %TargetDir%\I386.
Everything within "root\Documents and Settings" will need to be copied to the RAMDrive.
The rest ought to be able to just be directly copied to %TargetDir%.

I've attached a file which is an example of this structure (HelloWorld.wb.zip).
That ".wb.zip" part could be what lets people know its a WinBuilder script inside a zip file.
I think keeping it obvious that its a zip file is a good idea in order to make it easier to work with.

With this structure: You could put multiple scripts inside 1 container, very easily.
Say, somebody makes an Nmap script. Somebody else makes a TCPView script. Another person makes a Wireshark script. Somebody else could come put them together, easily, and call it "X's Network Security Package", host it wherever, and, suddenly, the WinBuilder users have a very cool new option and you have a lower bandwidth bill. (IMG:../forums/style_emoticons/default/thumbsup.gif)

4) Multi-use comments
Comments can double as status messages during the build process

5) Self-contained APIs
APIs should always use:
* Variables explicitly passed to them
* Variables they make themselves

Unless you're previously aware of the necessary variable settings: APIs with variables not explicitly passed are a pain in the arse.

6) Let the coder see
* Let the coder easily see what arguments a function will accept (SciTE does this with Popup Tooltips)
* Let the coder easily see the values of variables (A hideable bar which lets the coder see the values of vars would be great)

7) Make sure the base APIs are solid, and easily accessible
On the whole, you've done a pretty damn good job of this. The only improvements I can mention are to make it obvious what the arguments to the functions mean.

Hi rt10k!

Nice pack of ideas! (IMG:../forums/style_emoticons/default/thumbsup.gif)


I completely support your suggestions #1 and #2 and we might start working on them over the next beta discussions.

About the other topics, here are my comments:

#3

The option to use .wb.zip extension to group several scripts seems interesting - only one detail - scripts should always avoid using rigid folder names to allow projects being used in other purposes.

Imagine the I386 example - it wouldn't be used on the vistaPE project for example.

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

#4

Can't we already use something like




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

#5

At the moment we're moving from self contained api's to common api's placed on a external file (a bit like the css html styles)

3 advantages:
- Change the api.script file and it will apply on all scripts that use it instead of manually editing each file
- easier to port the same functions to other projects as needed.
- if they become standard it's easier to remember and explain to others how they can be used

----------

#6

Will work on this feature - when I'm working with delphi it's really great to see all available options to avoid mistakes and save some time.. (IMG:../forums/style_emoticons/default/thumbsup.gif)

----------

#7

Also agree strongly with your opinion, we're currently discussing it here: http://www.boot-land.net/forums/index.php?showtopic=2707


You're welcome to join our talks! (IMG:../forums/style_emoticons/default/cheers.gif)

Cross-compatibility between projects
For that, I'd cut loose the idea of a mirror image of the file structure, and just put the files for a script into a directory of the same name as the script, and make sure to use the appropriate environment variables instead of absolute paths when relating to the target dirs.

If you really want cross-compatibility between projects, I think you're going to have to make it clear that the API has variables to handle the proper locations of files. Otherwise, you'll surely have folk like me explicitly defining a full path to the file, worrying only about my project.

Environment Variables
It seems like there should be a clear distinction between Local and Build Environment variables.
I think following a structure like this makes sense for doing that:
%Local*%=%*%
%Build*%=#$p*#$p

Just replace * with whatever environment variable is applicable to the architecture.
SystemDrive, SystemRoot, ProgramFiles, ALLUSERSPROFILE, etc.

Intuitive Function Syntax

I think it would be a good idea to use the usual function syntax: Func(Arg1, Arg2, Arg3)
That would make it more readable, and more intuitive for those of us familiar with just about any programming language. It would also make it easy to get the SciTE engine to let us know what arguments the functions take.

Similarly, I think it would be a good idea to change the way the custom GUI (Nice work, by the way (IMG:../forums/style_emoticons/default/smile.gif) ) keeps track of its objects to something more like: ItemName(Index, Caption, Value, X, Y, Width, Height)

"The API Reference Wiki Page"
I think there should be a page which is very apparent in this community, which shows all of the available API functions and variables, and how to make use of them.

It could start off as a single page, which mentions all of the API functions and variables, then it could grow from there. To help it grow, making it prominent everywhere would likely help.

Eventually, for every API item, there ought to be a(n):
* Example function declaration: FuncName(Arg1, Arg2, Arg3)
* Definition of Argument Values: Arg1 = A string which specifies the output directory, Arg2 = ...
* List of external variables the API is dependent upon: %x% = Used all over the damn place, ...
* Placemark to report bugs

"The Feature Request Wiki Page"
People can search through the list of topics which have already come up, and if its been brought up before: There could be a "Working on it!" or a "Screw this! Too much work!" to let it be known where things stand.

And, pretty much everything on the Forums right now seems like it would make more sense to be on a wiki.
The social part ought to be delegated to the chat room. Meebo Rooms is better for that, in that it works on mozilla and opera, as well as IE.

By the way
Why am I seeing not only AddShortcut, but also Add-Shortcut, Add_Shortcut, and Add_Shortcut-old?

We're right in the middle of discussions for api scripting and that's the reason why you still see very little information available.

Some info has been made here:
http://boot-land.net/winbuilder/help/scrip...pplication.html
(which also showcases a sample script that adds a shortcut)

You can create several shortcuts if you use the SET command to change the needed values on the respective [variables] section and call add_shortcut again.

http://boot-land.net/winbuilder/help/scrip...syntax.html#SET

---

There are several methods to add shortcuts - the one I'm refering here is an api based one that is defined inside the api.script file (and listed as a variable inside the respective script.project file)

---

And projects become cross-compatible because of the variables that are defined on each script.project file, look here on the [variables] section:



http://livexp.boot-land.net/LiveXP/script.project

On vistaPE some of these values are modified (I386 renamed to Windows for example) and app scripts can even be used to install apps directly on the host windows in a automated way without changes on the app script file.

---------

The modification of the script language to use () would be quite dificult to implement at this moment, sorry.. (IMG:../forums/style_emoticons/default/mellow.gif)

We also have a wiki - specially modified to allow copying text from our forums and support the same text formating - but it's not used very often - need more people to maintain it updated.

Hopefully during the next months more documentation and tools can be improved to make things easier to understand for everybody, the good news is that app scripts are getting into a very satisfory level where we can easily exchange them between different projects.

(IMG:../forums/style_emoticons/default/smile.gif)