29 replies to this topic

[Brito]

Hi,

I have to requests/questions:

About the current location of the temporary files for nativeEx - would it be possible to move the temporary folder where project files are created to %basedir%\Temp\%projectname% ?

The idea is to keep all created files outside the "Projects" folder above all interferences.

This way the project would always be ready to be published online and we wouldn't have to fetch all temporary files that only apply to our work environment.

Not mentioning that overall cleanup would be user friendly - just delete the %basedir%\Temp folder..


Second request:

Had an error while using BootSDI because I wasn't online (but this to be placed on another topic) - but it still gave an error message because buildmodel.exe was missing..

Would it be possible to somehow allow to scripts to run individually again?

Having all scripts enabled to have a complete build takes a long while to get done - so I just wanted to run the problematic script again and complete my project - instead I have to run the project again from scratch and hope that no more error appears..

I know that some commands add text lines and this might be more dificult to avoid double entries or reset the startup list - but since buildmodel itself is a binary this probably could get optimized..

What do you think?

[pscEx]

About the current location of the temporary files for nativeEx - would it be possible to move the temporary folder where project files are created to %basedir%\Temp\%projectname% ?

The idea is to keep all created files outside the "Projects" folder above all interferences.

No problem. When trying the 'could not delete ...\shortcuts' issue I already tried %BaseDir%\Temp and it worked.
I have been to stupid to use %BaseDir%\Temp\%Projectname%
I'll change tomorrow.

I think that my new script.project variable %projectname% in beta 6 will be replaced by an buid-in variable

Better solution:
@Nuno:
Create two new internal variables

• %Temp%
• %ProjectTemp%

Would it be possible to somehow allow to scripts to run individually again?

See here
That allows to rerun a single script and then go into 'produce ISO' again.

• You have a %Target% produced and modified by individual scripts
• The target can be changed whenever necessary
• ISO or whatelse is produced w/o changing %Target%

Peter

[Brito]

No problem. When trying the 'could not delete ...\shortcuts' issue I already tried %BaseDir%\Temp and it worked.
I have been to stupid to use %BaseDir%\Temp\%Projectname%
I'll change tomorrow.

Don't forget to use %BaseDir%\Temp\%Projectname% - since VistaPE is also using this folder as temporary place for storing files.

I think that my new script.project variable %projectname% in beta 6 will be replaced by an buid-in variable

Better solution:
@Nuno:
Create two new internal variables

• %Temp%
• %ProjectTemp%

I think both variables should continue to be defined by the project - it won't slow down processing because they are added at the same time as fixed vars and we would be able to continue controlling them in future times (to avoid unneeded variables like %pedrive%) for projects which wouldn't think about them. (not one project I can remember at this moment, but you can never guess tomorrow..)

This do seem a good addon for a common API - althought %temp% should have another name like %tempfolder% (as an example) to avoid confusions with the already existent windows %temp% variable.

What is the difference between %temp% and %ProjectTemp%?

See here
That allows to rerun a single script and then go into 'produce ISO' again.

• You have a %Target% produced and modified by individual scripts
• The target can be changed whenever necessary
• ISO or whatelse is produced w/o changing %Target%

Peter

Yes, but I meant independence on a global script scale - imagine it is an application script or driver that people wish to add..

[pscEx]

What is the difference between %temp% and %ProjectTemp%? huh.gif

%Temp% = ??? maybe %Basedir%\Temp
%ProjectTemp% = %Temp%\%Projectname%

Yes, but I meant independence on a global script scale - imagine it is an application script or driver that people wish to add.. rolleyes.gif

Add a script

• If necessary, copy into the project and refresh
• Check the script
• Run the script
• Goto 'Produce and Test ISOs' and rebuild ISO, check in emulator, etc.

The only question I currently have:
How to remove a script?
A real well-ingeneered solution demands something like a history stack

Peter

[Brito]

Under this situation I would suggest an Ini like approach to handle text lines and althought I still need to know in detail which files should be included for history - there are some common ways to keep history on several files and get the expected results, below is an example.





Imagine a script which will need to write lines on a specific file - this action has to be done interfacing with buildmodel, right?



So buildmodel will create inside a specific folder (ex. BuildFolder) a new text file (ex. BuildTextFile) with the same name and folder structure as found on the project to avoid any duplicates - also remembering to create the root folder according to the script level (0,1,2,3,4,5..) to later respect the script order on the final step.

We'd get:

[ BuildFolder ]
--[ 1 ]
----[ Basic ]
-------[ Shells ]
----------- myScript.txt

--[ 3 ]
----[ Apps ]
----------- ShellWM.txt
....

This newly created text file will contain all the changes meant to happen on the files for which buildmodel is responsable to create (ex. FinalTextFiles).


All lines which are meant to be added on all different "FinalTextFiles" can be placed inside INI sections using each file name as the title for each respective section.

Example:

myScriptExample.txt



[autoruns.bat]

add my app here

add my app with more parameters



[shortcuts.ini]

CreateMyScriptExample

myAnotherScriptExample.txt



[autoruns.bat]

add my second app here



[shortcuts.ini]

DoNotCreateMyScriptExampleHere



[ProjectInfo.ini]

myAnotherScriptExample.script

If the user wishes to run a script again - buildmodel is called and will simply overwrite the already existent "BuildTextFile" - surely avoiding any duplicate entries this way.


Last step is when CreateISO (or similar) is called and buildmodel will look and create a list of all files (with extension .txt for example) and begins adding(/merge?) each section, respecting the same script order created by the first step and (re)producing line by line a valid text file.


As final result from this method - all files can be merged at any time when createISO is called to run and we need to assemble the "FinalTextFiles" - buildmodel starts and will output the resulting text file from whichever files are available to add from our "buildFolders".



Hope you like this suggestion and that this improvised database can be give some ideas - I can help you coding this behavior if you wish - just be carefull because I often miss FindClose(SearchRec) on some functions...

[pscEx]

Hi,

I have to requests/questions:

About the current location of the temporary files for nativeEx - would it be possible to move the temporary folder where project files are created to %basedir%\Temp\%projectname% ?

The idea is to keep all created files outside the "Projects" folder above all interferences.

This way the project would always be ready to be published online and we wouldn't have to fetch all temporary files that only apply to our work environment.

Not mentioning that overall cleanup would be user friendly - just delete the %basedir%\Temp folder..

Done.

All current nativeEx_barebone xxx\Temp\yyy requests now point to %ProjectTemp%\yyy
with %ProjectTemp%=%BaseDir%\Temp\<projectname>
and <projectname> = script.project:Main.Title

%ProjectTemp% is generated by !Fundamentals.Script.
Therefore:
If you start your own project from a copy of nativeEx_barebone, you only need to rename the title.
The temp of your project will not conflict with the temp of nativeEx_barebone.

Peter

[Brito]

Really fast modification and smart way to organize folders!

Thanks..

[pscEx]

There is a problem in the solution caused by variable substitution failure.
It causes %ProjectTemp% to be inserted multiple.
Just run !Fundamentals and have a look at the log.

I changed the !Fundamentals code, to bypass the issue.

If you download the new !Fundamentals, take care also to download scripts.project.

Peter

[Brito]

Ok - thanks for the details. Will you also add support for running single scripts?

[pscEx]

Ok - thanks for the details. Will you also add support for running single scripts?

You need a little bit more patience!

Peter

[Brito]

I guess you're right - I'm really having so much fun with nativeEx..

[pscEx]

Second request:

Had an error while using BootSDI because I wasn't online (but this to be placed on another topic) - but it still gave an error message because buildmodel.exe was missing..

Would it be possible to somehow allow to scripts to run individually again?

Having all scripts enabled to have a complete build takes a long while to get done - so I just wanted to run the problematic script again and complete my project - instead I have to run the project again from scratch and hope that no more error appears..

Done and upload to nativeEx server > Tools\ReOpen.Script.

This needs buildModel.Script version 030 and script.project version 014.

buildModel version is checked by WBVerify, but script.project version cannot (yet) be verified.

Peter

[Brito]

You mean that I can run a script after the first time I create a project and then just repeat the createISO to see the results - well, that was fast..


Really appreciate this modification, thanks..

[pscEx]

You mean that I can run a script after the first time I create a project and then just repeat the createISO to see the results

No, you are wrong!

To see the result you additionally have to run qEmu or VirtualBox or ...

Peter

[Brito]

[Brito]

Hi,

Still testing and it seems that temporary files handled by buildmodel are not correctly removed - I have to finish wb and manually delete the folder in order to see the shortcuts correctly.

Strange enough that sometimes it will work while some other times will not..

Any ideas on sight?

[Brito]

Will try to use a temp folder outside the Projects folder itself - I think it is related to why these files inside aren't correctly deleted, I keep deleting all temporary work folders to properly test the project.

%projectdir%\Basic\PreBuild
%projectdir%\Obsolete
%projectdir%\Temp
%projectdir%\ProjectInfo.ini
%projectdir%\!wbmanager\WBmanager.exe

Could these files and folders be moved to %basedir%\Temp\%projectname% - maybe this should be a new var as %workdir% to add on wb itself so that it could be used more frequently..

[pscEx]

Will try to use a temp folder outside the Projects folder itself - I think it is related to why these files inside aren't correctly deleted, I keep deleting all temporary work folders to properly test the project.

%projectdir%\Basic\PreBuild
%projectdir%\Obsolete
%projectdir%\Temp
%projectdir%\ProjectInfo.ini
%projectdir%\!wbmanager\WBmanager.exe

Could these files and folders be moved to %basedir%\Temp\%projectname% - maybe this should be a new var as %workdir% to add on wb itself so that it could be used more frequently..

It took a while to fullfill your requirement from the first post.
But now it's finished.

See here.

Our posts crossed.

Peter

[Brito]

Is any work still being done on this feature?

Would be good to be able to run and add a script to the build instead of a full build from scratch (especially on very lengthy projects)..

[pscEx]

Is any work still being done on this feature?

For me it's done and working (besides the fact that in 90% WinBuilder reports an access error).
I use ReOpen.script often.

Would be good to be able to run and add a script to the build instead of a full build from scratch (especially on very lengthy projects)..

To add is no problem. But is is rather impossible to remove scripts.
Registry entries and copied files remain.

Peter

[Brito]

I meant something as suggested here:
http://www.boot-land...?...ost&p=13548

This would make any script using buildmodel capable of running outside the global project run.


Had some trouble explaining the overall concept in the above link, but here's what needed:

- buildmodel accepts input and write a new file using the same project structure (but placed on a temp location)
- each scripts uses buildmodel and unique text file is created for this effect

- When the ISO is about to be created, buildmodel is called to build the complete "build" structure for shortcuts and such.

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

This would mean that people would at any given time be able to just run the script to add a program and click to create an ISO and run in QEMU

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

No need to remove scripts - we just need to add them, to remove it would be simpler to start from scratch.

Each time I create a script - it takes a long time having to rebuild everything from the start just to see if I like the result - but you know how things rarely get right at the first attempt so repeat this several times across a day..

[pscEx]

Each time I create a script - it takes a long time having to rebuild everything from the start just to see if I like the result - but you know how things rarely get right at the first attempt so repeat this several times across a day..

Maybe we misunderstand each other, but try:

• (You have a built ISO)
• In the project tree, click 'Tools' > 'ReOpen'
• In the GUI click 'ReOpen'
• Add your new script into the project
• Click 'Refresh'
• In the project tree, click your new script and run it
• In the project tree, click 'Tools' > 'ReOpen' again
• In the GUI click 'Run Them'

As result, you have the ISO like before plus your new script

Peter

[Brito]

Yes, I guess we're not talking about the same thing..


I just meant to be able to run single scripts inside nativeEx - at this moment this isn't possible.

[pscEx]

Yes, I guess we're not talking about the same thing..

I just meant to be able to run single scripts inside nativeEx - at this moment this isn't possible.

What do you think about this?


Peter

[TheHive]

That looks very good.