Script Engine Issues

The following snippet

IniRead,"%SourceDir%\I386\%driverIndex%","Version","CabFiles","%myTemp%"

Echo,"%myTemp%"

If,ExistFile,"tmp.tmp",FileDelete,"tmp.tmp"

Set,"%cmd%","/c for %a in (%myTemp%) do echo %a > tmp.tmp"

Echo,"%cmd%"

ShellExecute,Open,"cmd.exe", "%cmd%"

Exit,"Ende"

brings

Sucessfully read specified Inifile from: [V:\BCD\cds\XPP_DE_SP2\I386\DRVINDEX.INF] Section: [Version] Key: [CabFiles] into variable: [%myTemp%] with value: [SP2,driver]
SP2,driver
Sucessfully tested if file existed: [tmp.tmp] executing command: [FileDelete,tmp.tmp]
FileDelete - Sucessfully deleted file: [tmp.tmp]
Sucessfully changed the value of [%cmd%] to: [/c for %a in (%myTemp%) do echo %a > tmp.tmp]
/c for %a in (%myTemp%) do echo %a > tmp.tmp
Successfully executed command: [Open] using: [cmd.exe] with parameters: [ "/c for %a in (%myTemp%) do echo %a > tmp.tmp"]
Ende

The variable %myTemp% is not substituted correctly.

Peter

Thanks for reporting the snippet - It's clear to see what's going wrong in it..

I'll see if it gets fixed on 047..

Good luck with your scripting!

Another, maybe a different replacement problem:

If,%ForOS%,NotEqual,%OS%,Message,"This script is created for %ForOS%.#$xYou are working with %OS%.#$xThat may create problems.",Warning

works, while

If,%ForOS%,NotEqual,"All",If,%ForOS%,NotEqual,%OS%,Message,"This script is created for %ForOS%.#$xYou are working with %OS%.#$xThat may create problems.",Warning

does not replace inside the message.

Peter

Another, maybe a different replacement problem:

If,%ForOS%,NotEqual,%OS%,

Message,"This script is created for %ForOS%.#$xYou are working with %OS%.#$xThat may create problems.",Warning

If,%ForOS%,NotEqual,"All",

If,%ForOS%,NotEqual,%OS%,

Message,"This script is created for %ForOS%.#$xYou are working with %OS%.#$xThat may create problems.",Warning

does not replace inside the message.

Peter

I was not predicting the behavior on nested IF clauses..

Does #$x gets converted to line break correctly?


A possible workaround migth be adding a separate section to handle this issue:

[OSnotEqual]

If,%ForOS%,NotEqual,%OS%,Message,"This script is created for %ForOS%.#$xYou are working with %OS%.#$xThat may create problems.",Warning



[Process]

If,%ForOS%,NotEqual,"All",Run,%scriptFile%,OSnotEqual

Just an idea, I haven't tested it..

btw: I've added OSinfo script to the standard project, but now another problem arises: As multiple shells begin to be used like xoblite vs explorer, wouldn't it be wise to define a standard file where shortcuts could be added, edited, sorted and then exported to the selected shell menus?

From the project interface it would be possible to add a box to select wich shell the user wants to use - I will ensure that projects can have a word in the building process to ensure that all options selected on the interface can be used on other scripts..

Something like a menu.txt where each entry could be stored, then a dedicated exe or autoIt script could properly make all needed shortcuts depending on the shell requirements.


What do you think?



In a last note:

I've added this morning the .link feature - in wich a plain text file with extension .link can be used as a shortcut to a .script file in a central folder where it's archived along with other scripts.

All edited values reflect directly on the linked .script file, except the enable/disable switch to allow multiple profiles across diferent projects..

A possible workaround migth be adding a separate section to handle this issue:

I already had solved it with the separate process.

But nested IF would be nice .....

btw: I've added OSinfo script to the standard project, but now another problem arises: As multiple shells begin to be used like xoblite vs explorer, wouldn't it be wise to define a standard file where shortcuts could be added, edited, sorted and then exported to the selected shell menus?

From the project interface it would be possible to add a box to select wich shell the user wants to use - I will ensure that projects can have a word in the building process to ensure that all options selected on the interface can be used on other scripts..

Something like a menu.txt where each entry could be stored, then a dedicated exe or autoIt script could properly make all needed shortcuts depending on the shell requirements.


What do you think?

Currently no opinion; I have to think more in detail.

I changed the script to ProjectInfo. It now contains the Cab logic I showed in the Mouclass Issue Topic.
[attachment=14:attachment]

I've added this morning the .link feature - in wich a plain text file with extension .link can be used as a shortcut to a .script file in a central folder where it's archived along with other scripts.

Great!
I'm waiting for the test.


Peter

nested IF would be nice .....

I'm still wondering on why it isn't being correctly handled.. in theory this should work fine on all sort of loops..

Maybe it's a detail I've overlooked, I'll check in more detail soon enough..


I've just tested your new version and it worked fine, it is indeed quite accurate regarding the used source - very good work!

[OS]
Type=W2003
SubType=Enterprise
ServicePack=SP1

[Cabs]
SP_CAB=
DR_CAB=

Only one detail - would you mind if the output files were placed on %targetdir% rather than %projectdir%?

Perhaps like dirkgently42 has proposed some time ago to place a small file that can be used to describe the source used for the build on the root of the %targetdir%, also leaving the %projectdir% less cluttered with files, not to mention it would also help to publish the project on the net without leaving traces from previous build attempts..


quoting dirkgently from here:

Just a little tidbit from xp install CD:
QUOTE (lawson23)
You could check the file version of the setup.exe or a different file contained on the cd.
setup.exe:
IE XP PRO 5.1.2600.0
IE XP PRO 5.1.2600.2180 - SP1 slipstreamed with SP2
IE 2k3 Standard 5.2.3790.0


bartpe checks setupldr.bin

Honorable mention:
C:\I386\DRVINDEX.INF
, or E:\I386\DRVINDEX.INF


Note: I think it would be real handy to generate a "openbuilder.log" that could be included with the finalized CD (add to root of ISO) ... just as a reminder of what you built. This log should include a summary of the build process, including build platform, build source, custom scripts, etc. Just a way to slap a digital label on it and maybe a memory jogger.

Maybe this would be a good chance to explore this option as well..

Only one detail - would you mind if the output files were placed on %targetdir% rather than %projectdir%?

Good idea!
But then the ProjectInfo script should be the second one behind MakeDirs (This deletes %Target%)
I make a change in my NanoXP Experimental script I'm planning to post.

[OS]
Type=W2003
SubType=Enterprise
ServicePack=SP1

[Cabs]
SP_CAB=
DR_CAB=

This surprises me. Why are the Cabs keys empty?
How is the DRVINDEX.INF[Version]CabFiles entry of your source?

Peter

What do you think about combining the MakeDirs and ProjectInfo scripts into one ProjectInit script.

This could be the first shared script with a .link

Peter

[Version]
signature="$Windows NT$"
CabFiles=sp1,driver

[driver]
2gmgsmt.sf2
3145pcl.gpd

........

[Cabs]
driver=driver.cab
sp1=sp1.cab

What is wrong here?

What do you think about combining the MakeDirs and ProjectInfo scripts into one ProjectInit script.
This could be the first shared script with a .link

It would unclutter the window of the standard project, I'm just unsure of the impact of the explorer script on middle of it, since it would force the creation on a WinSxS folder on regular builds wich are not needed by nanoxp like builds.

It would be great that an initial script gave a small diagnostic on the type of windows source used, this would be extremely valuable on feedback that could be assured by others when knowing more about each type of build source used..


Keep it coming!

What is wrong here?

You get:

[OS]
Type=W2003
SubType=Enterprise
ServicePack=SP1

[Cabs]
SP_CAB=
DR_CAB=

And I get

[OS]
Type=W2003
SubType=Enterprise
ServicePack=SP1

[Cabs]
SP_CAB=sp1.cab
DR_CAB=driver.cab

Maybe I did not attach the valid script.
I'm going to check.

It would unclutter the window of the standard project, I'm just unsure of the impact of the explorer script on middle of it, since it would force the creation on a WinSxS folder on regular builds wich are not needed by nanoxp like builds.

So doing the System Info script as the very first one would be the best.

Peter

New issue:

The line

IniDeleteSection,"%iniFile%","Actual"

brings the error message

IniDeleteSection - Failed to delete INI section in file: [C:\Dokumente und Einstellungen\Peter\Desktop\OpenBuilder_Test\Projects\NanoXP\ProjectInfo.ini] Section: [Actual]

but it really deletes the existing section!

Peter

Yes, I think you've caught a bug!

Will get right on top of it..


Thanks!!

Is it possible to "build" a webpage into a Delphi app? I am working on something new that might benefit from being linked from within OpenBuilder.

Is it possible to "build" a webpage into a Delphi app? I am working on something new that might benefit from being linked from within OpenBuilder.

I've been thinking about that..

Updating a script is rather easy, just provide an update host, download an updated files list, compare versions and download to overwrite the previous script.

But a few problems arise from this situation:

- what would happen if the script changed name? no more updates?
- what type of version system would be correct? To quickly solve this problem, I've adopted builds instead of versions - managing 1.1.1 is not so easy when it comes to bug fixes.. it would be easy if open builder had static boxes that forced people to had major, minor and revision changes onto every script - but then I asked myself why? Things should be simple to use and look.. not to mention that it would make it hard to remember in wich version a script is updated..

In openbuilder.exe I found this to be a bit pushed for the end goal, so I use build numbers to keep things easy to memorize..


Seems a very good idea, especially to allow updates to work as dynamic as possible - the answer is yes - it is possible to give built in html web browsing capabilites (either on/off line).. keep your ideas growing and somewhere in future they might get implemented..

I think, I found a new bug.

The line

IniWrite,"%ProjectInfo%","CustomLogs","KeyboardLayout",%LAYOUTTEXT%

results in:

[CgrtomLogs]

KeyboardLayout=Deutsch

As to be seen, 'us' is substituted by 'gr'

This is in the keyboard script where the default

%DOSKEYBVALUE%=us

gets the new value gr (because my choice is German)

The log shows:

Sucessfully changed the value of [%DOSKEYBVALUE%] to: [gr]

Does that mean:

Sucessfully changed the value of [us] to: [gr]

Peter

hmm... it looks like a bug to me..

The only workaround I can remember at the moment is using a set,%DOSKEYBVALUE%,"" to clear the value, perhaps this should do as a quick-fix for now.


I've added it on my To-Do list..

hmm... it looks like a bug to me..

The only workaround I can remember at the moment is using a set,%DOSKEYBVALUE%,"" to clear the value, perhaps this should do as a quick-fix for now.
I've added it on my To-Do list..

%DOSKEYBVALUE%=""

The result was terrible!

I changed to:

%DOSKEYBVALUE%=xx

because the value is always set anywhere, so the init value does not matter.

Peter

That's good!

Still haven't fixed the %var%, will take a closer look again..

Currently in my projects I have some global variables wich are defined for every project separately in the script.project file:

[Variables]

%ProjectInfo%=%ProjectDir%\ProjectInfo.ini

%ScriptLog%=%BaseDir%\Archive\Build\ScriptLog.script

%EmptyHive%=%BaseDir%\Archive\Build\EmptyHive.script

%ProcessUPX%=%ProjectDir%\autoUPX\processUPX.script

Because these variables are identical for the Standard and PicoXP projects, it would be nice to define them in Openbuilder.ini

Peter

I'll work on it!

I've been thinking about that..

Updating a script is rather easy, just provide an update host, download an updated files list, compare versions and download to overwrite the previous script.

But a few problems arise from this situation:

- what would happen if the script changed name? no more updates?
- what type of version system would be correct? To quickly solve this problem, I've adopted builds instead of versions - managing 1.1.1 is not so easy when it comes to bug fixes.. it would be easy if open builder had static boxes that forced people to had major, minor and revision changes onto every script - but then I asked myself why? Things should be simple to use and look.. not to mention that it would make it hard to remember in wich version a script is updated..

In openbuilder.exe I found this to be a bit pushed for the end goal, so I use build numbers to keep things easy to memorize..
Seems a very good idea, especially to allow updates to work as dynamic as possible - the answer is yes - it is possible to give built in html web browsing capabilites (either on/off line).. keep your ideas growing and somewhere in future they might get implemented..

I do NOT se why build numbers would be hard to implement.
(PHPish) pseudocode:

version = array

(

	'major' => $value_from_first_input_box,

	'minor' => $value_from_second_input_box,

	'patch' => $value_from_third_input_box

)

of course, one would have to add input validation. checking for integers for example

//martin (who can be very stubborn and insistent at times)

Well.. why not follow the suggestion from the python language developer like you mentioned on the other day over msn?

It could be added as a single number as well..

Take your work as the first release 1.0.0 - you could also use 100, where you'd still use Major, minor and patch..


Build numbers are easier to handle because they don't use commas and all it's needed to do is convert them from string to number values, this is mostly the reason why I adopt them..

..um. and what happems when we get to major version 2, minor version 13, patch 32 (2.13.32)?

then, 3 mere digits won't cut it.

what happems when we get to major version 2, minor version 13, patch 32 (2.13.32)?

.....

Use 21332?

I still think that GNU versioning of this sort would be quite useful on very active scripts/programs wich would get edit/modified/published very often, but you can always use more than 3 digits - there is no digit limit..

Why this long discussion about versioning?
I think Martin is right.

Would it be so difficult to implement the '1.23.201' ?

Peter