Jump to content











Photo
- - - - -

Script Engine Issues


  • Please log in to reply
25 replies to this topic

#1 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 08:15 AM

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

#2 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 18 July 2006 - 01:53 PM

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!
:P

#3 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 02:38 PM

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

#4 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 18 July 2006 - 03:07 PM

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..

:P

#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 04:22 PM

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

#6 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 18 July 2006 - 04:57 PM

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..
:P

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 05:34 PM

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

#8 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 05:51 PM

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

#9 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 18 July 2006 - 06:30 PM

[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! :P

#10 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 July 2006 - 06:50 PM

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

#11 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 20 July 2006 - 01:30 PM

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

#12 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 20 July 2006 - 06:30 PM

Yes, I think you've caught a bug! :P

Will get right on top of it.. :P


Thanks!!
:P

#13 Yorn

Yorn

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:United States

Posted 21 July 2006 - 02:08 PM

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.

#14 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 21 July 2006 - 03:02 PM

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.. :P


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.. :P

#15 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 26 July 2006 - 10:14 AM

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 :P

#16 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 26 July 2006 - 10:46 AM

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

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.. :P

#17 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 26 July 2006 - 04:42 PM

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

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.. :P


%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

#18 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 26 July 2006 - 04:47 PM

That's good! :P

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

#19 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 August 2006 - 04:06 PM

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 :P

#20 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 17 August 2006 - 04:33 PM

I'll work on it! :P

#21 Draugen

Draugen

    Frequent Member

  • .script developer
  • 147 posts
  • Location:South of Heaven

Posted 17 August 2006 - 10:06 PM

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.. :P
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.. :P


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 :P

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

#22 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 17 August 2006 - 11:43 PM

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..

:P

#23 Draugen

Draugen

    Frequent Member

  • .script developer
  • 147 posts
  • Location:South of Heaven

Posted 18 August 2006 - 03:16 AM

..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.

#24 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 18 August 2006 - 09:44 AM

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

..... :P

Use 21332? :P

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.. :P

#25 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12704 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 18 August 2006 - 10:06 AM

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

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

Peter




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users