11 replies to this topic

[edborg]

I realize that the Standard project is dead and its successor is LiveXP.
However, I have a full set of personalised scripts (apps, drivers, network, etc.) working fine within the Standard project in WB053, with features that I would loose if I simply switched to LiveXP in WB068.

As the two projects are quite different in their basics and I wasn't able to directly modify all my scripts to add them to LiveXP, what I did first was to adapt them to work (still in the Standard Project) with WB068, keeping the two projects live and leaving the migration to LiveXP to a second stage.

In doing so, I encountered difficulties when trying to maintain compatibility between WB053 and WB068.
I did all necessary changes (layout, archive, links, variables, winbuilder.ini, script.project, etc) to make my Standard project work with WB068 and WB053, and almost got it working, unless for the %Tools% variable.
As I couldn't find any place where such a variable is defined, I assume that it's hardcoded in WB (differently in different versions) and what I tried to do is not possible.
Wouldn't it be better in future to have this variable user defined as all others are?
edborg

[Nuno Brito]

Hi Edborg!

You can overwrite the %tools% variable if you wish - just place a %tools%=%BaseDir%\YourFolder and should be working as you expect.

This can be added on WinBuilder.ini, script.project or even inside the script itself - this folder was moved to the projects folder to keep all files needed to update inside a single place.

Good luck with your migration!

[edborg]

Hi Edborg!

You can overwrite the %tools% variable if you wish - just place a %tools%=%BaseDir%\YourFolder and should be working as you expect.

This can be added on WinBuilder.ini, script.project or even inside the script itself - this folder was moved to the projects folder to keep all files needed to update inside a single place.

Good luck with your migration!

Thanks Nuno!
You're always ready to help, and you do it immediately
It's not a major problem, my Standard project works well now with WB068 and I can loose backward compatibility with WB053.
However, I had already tried overwriting %Tools% in Winbuilder.ini but didn't work as expected.
Working with nested variables is not that easy or reliable, as I already mentioned in the past.
Look at the enclosed test script, that documented a problem in WB052, still present in WB068.
edborg

Attached Files

•  TestVariables.script   1.59KB   166 downloads

[pscEx]

However, I had already tried overwriting %Tools% in Winbuilder.ini but didn't work as expected.
Working with nested variables is not that easy or reliable, as I already mentioned in the past.
Look at the enclosed test script, that documented a problem in WB052, still present in WB068.
edborg

To avoid your problem you should try
System,RefreshVars

Peter

[Nuno Brito]

Hmm.. You're right hadn't remembered the nested vars issue!

System,RefreshVars

Should solve this matter, but unfortunatelly this would also mean adding this command on each script you wish to upgrade.

Maybe soon it will be possible to have variables that don't suffer from this nasty flaw - it was fixed some time ago, but the fix made regular project builds pass from 7 minutes to 22 minutes, so this command was added to solve this sort of things whenever needed and the fix was removed.

Good luck!

[pscEx]

Maybe soon it will be possible to have variables that don't suffer from this nasty flaw - it was fixed some time ago, but the fix made regular project builds pass from 7 minutes to 22 minutes, so this command was added to solve this sort of things whenever needed and the fix was removed.

What about:
[Main]
NestedVars=True

Peter

[Nuno Brito]

Sounds good, only think it should be added on the variables section to allow it to also be added on winbuilder.ini and script.project if needed, what do you think?

[edborg]

Hmm.. You're right hadn't remembered the nested vars issue!

System,RefreshVars

Should solve this matter, but unfortunatelly this would also mean adding this command on each script you wish to upgrade.

Maybe soon it will be possible to have variables that don't suffer from this nasty flaw - it was fixed some time ago, but the fix made regular project builds pass from 7 minutes to 22 minutes, so this command was added to solve this sort of things whenever needed and the fix was removed.

Good luck!

I see. This is a very good reason for not solving that issue . System,RefreshVars is an acceptable workaround, of which I didn't know the existence, though.

I now miss another command

When installing a build to USB it's much easier to simply copy eveything to the stick and then rename the i386 folder to minint, but I couldn't find a command to do that.
DirMove is not an option (by the way, what's the difference from DirCopy? ), as it's much slower and needs more space that I have on the stick.
Moreover, copying each folder separately also creates difficulties with localised names of Programs/Program files.
Could a DirRename command be added to Winbuilder?
Thanks
edborg

[Nuno Brito]

...
Could a DirRename command be added to Winbuilder?
...

Yes, it will be added - please test the next beta!

[MedEvil]

When installing a build to USB it's much easier to simply copy eveything to the stick and then rename the i386 folder to minint

How can that ever work for anyone? I found yesterday quit a few hardcoded i386 in the scripts.

[was_jaclaz]

When installing a build to USB it's much easier to simply copy eveything to the stick and then rename the i386 folder to minint, but I couldn't find a command to do that.

How can that ever work for anyone? I found yesterday quit a few hardcoded i386 in the scripts.

FYI, a nice trick has been developed by gray on the 911cd board, here:
http://www.911cd.net...o...3784&st=249

quite simply, leave the /I386 name on USB sticks also!

And, for USB write protection, do have a look at this too:
http://www.911cd.net...showtopic=19422

jaclaz

[MedEvil]

Thanks jaclaz. Both very helpful links.