20 replies to this topic

[Darijo]

Peter

I have seen a SetEsc, command, what is it for? I think this wasn't in earlier versions.

@Paraglider your help is the holy tool for the builder.

EDIT by pscEx: Moved to the support sub forum

[pscEx]

I have seen a SetEsc, command, what is it for? I think this wasn't in earlier versions.

@Paraglider your help is the holy tool for the builder.

EDIT by pscEx: Moved to the support sub forum

Imagine you want to have a line

%MyVariable%=%YourVariable%

in [Variables] of script.project.
(Assumed, %YourVariable% is defined)

Neither with

Set,%MyVariable%,%YourVariable%,PERMANENT

nor with

Set,%MyVariable%,#$pYourVariable#$p,PERMANENT

you will have sucess. Try it for yourself! But do not forget to

Set,%YourVariable%,BlaBla

The wanted result is reached with the SetEsc command:

SetEsc,%MyVariable%,#$pYourVariable#$p,PERMANENT

Peter

[paraglider]

So SetEsc suppresses variable expansion?

[paraglider]

Maybe not:

Set,%YourVariable%,BlaBla
Set,%MyVariable%,%YourVariable%,PERMANENT
Set,%MyVariable1%,#$pYourVariable#$p,PERMANENT
SetEsc,%MyVariable2%,#$pYourVariable#$p,PERMANENT
Set,%MyVariable3%,%MyVariable2%,PERMANENT
SetEsc,%MyVariable4%,%MyVariable2%,PERMANENT

as both MyVariable3 and MyVariable4 contain BlaBla

[Nuno Brito]

SetEsc

Why is it needed in the first place?

Set,%MyVariable%,%YourVariable%,PERMANENT

If the switch does not work as intended, what is the purpose of a PERMANENT switch in that case?

[pscEx]

Why is it needed in the first place?

Set,%MyVariable%,%YourVariable%,PERMANENT

If the switch does not work as intended, what is the purpose of a PERMANENT switch in that case?

It works as intended, but perhaps the user expects a different result.
PERMANENT writes the value into [Variables] of script.project.

Try in CodeBox:

[variables]

%YourVariable%=BlaBla



[Process]

Set,%MyVariable1%,%YourVariable%,PERMANENT

Set,%MyVariable2%,#$pYourVariable#$p,PERMANENT

SetEsc,%MyVariable3%,#$pYourVariable#$p,PERMANENT

It results in script.project:

%MyVariable1%=BlaBla
%MyVariable2%=#$pYourVariable#$p
%MyVariable3%=%YourVariable%

About background, see Release notes, item 3

Peter

[Wonko the Sane]

It's nice to see how syntax and features go through a process of preventive interactive discussion and examination among the developers of the actual engine.

In batch this is more or less :

SET YourVariable=BlaBla



SET MyVariable1=%YourVariable%

SET MyVariable2=a suffusion of yellow

SET MyVariable3=YourVariable



::making PERMANENT using external program

SETX MyVariable1=%YourVariable%

SETX MyVariable2=a suffusion of yellow

SETX MyVariable3=YourVariable

Right?

I simply love the the idea of PERMANENT variables , something which I used to call CONSTANTS.

Maybe it's all about Global and Local variables instead?


Wonko

[Nuno Brito]

It works as intended, but perhaps the user expects a different result.
PERMANENT writes the value into [Variables] of script.project.

To be honest, I see no added value from having either PERMANENT or SetEsc.

If a developer wants to change a global variable, let them edit directly script.project using ini write.

Project developers shouldn't use script.project for global variables that are continuously changing. This need would be better satisfied at an external file where only the scripts that require these settings will actually read and write them.

Too many variables hog the processing performance.

[pscEx]

Project developers shouldn't use script.project for global variables that are continuously changing. This need would be better satisfied at an external file where only the scripts that require these settings will actually read and write them.

Too many variables hog the processing performance.

My view is very different.
To have project wide variables defined in script.project, is much more better than the way you favorite. That way is currently already used by some projects, which store them e.g in projectinfo.ini or similar.
Then at the beginning of every app script the ( C )API's "ReadENV" is executed, which IniRead-s from projectinfo.ini.
Faster? NEVER!

With binary search, as now introduced in 081, there is no time difference in resolving one of 32 or one of 63 defined variables: 6 trials.
In 080 the time to search one of 10 defined variables brought the same average time.

Edit: Just an example: win7pe_se has 91 variables in script.project. So the average "find" of 080 will use 45 tests to find the replacement.
Using the binary search of 081, there could be 2^44 variables to get the same search time.
In numbers, that is around 35184372100000 Variables


Peter

[sbaeder]

Bringing this back around to the global/local question for a minute - I think that it is OK to have global variables...We should also make sure to try to document and have a good name space for really "global" (i.e. shared) variables, and no matter what they are called, have them documented.

Now, back tot he original issue of escapes inside a variable or not. I can maybe see why it is an OK thing to provide - NOT that it couldn't have been implemented a different way, but that if we have escapes that are used internally, and changed from the original string, there needs to be a way to prevent that. Some of this is just the baggage we need to carry since we use this sort of process in the first place to define variables, etc...

SO, if it exists, we should be sure to at least document it - not just what it does syntactically, but also WHY you might need to use and why you might NOT want to use it...

Scott

[Nuno Brito]

The growing number of variables (91!) listed in a script.project is an example of messy structuring inside our current projects.

Forcing all app scripts to read a file is also another example where better structuring is needed.

These variables could be read once at runtime from an external file and stay in memory globally. This way you keep script.project readable and we can wipe out the external file with specific windows source details when needed.

This should be our goal for future times, adding a setEsc command is not something that we really need, is it?

[pscEx]

The growing number of variables (91!) listed in a script.project is an example of messy structuring inside our current projects.

Forcing all app scripts to read a file is also another example where better structuring is needed.

These variables could be read once at runtime from an external file and stay in memory globally. This way you keep script.project readable and we can wipe out the external file with specific windows source details when needed.

This should be our goal for future times, adding a setEsc command is not something that we really need, is it?

The LiveXP project of WB 072 times had 65 variables / macros. From my archive:

[Variables]

%target_win%=%TargetDir%\I386

%target_sys%=%TargetDir%\I386\System32

%source_win%=%SourceDir%\I386

%source_sys%=%SourceDir%\I386

%ProjectName%=livexp

%GlobalTemp%=%BaseDir%\Temp

%GlobalSupport%=%BaseDir%\Workbench

%ProjectTemp%=%GlobalTemp%\%ProjectName%

%GlobalTemplates%=%GlobalSupport%\Common

%ProjectTemplates%=%GlobalSupport%\%ProjectName%\UserData

%ProjectCache%=%GlobalSupport%\%ProjectName%\Cache

%PPISODir%=%ProjectTemplates%\Data

%PreISOName%=ISO-PreProcess.Script.txt

%PostISOName%=ISO-PostProcess.Script.txt

%PreISOScript%=%PPISODir%\%PreISOName%

%PostISOScript%=%PPISODir%\%PostISOName%

%shcTemp%=%ProjectTemp%\shcTemp.ini

%HoJoPEdir%=%ProjectCache%\Prebuild

%ProjectInfo%=%ProjectTemplates%\ProjectInfo.ini

%ReOpenRoot%=%ProjectDir%\Tools\ReOpen

%ProcessUPX%=%ProjectDir%\Tools\processUPX.Script

%AutoRunFile%=%target_sys%\autorun.cmd

%HoJoPEexe%=HoJoPE.exe

%Core%=%ProjectDir%

%ScriptLog%=%Core%\Basic\Build\ScriptLog.Script

%EmptyHive%=%Core%\Basic\Build\EmptyHive.Script

%AutoRunScript%=%Core%\Basic\Build\autoruns.Script

%BuildModelScript%=%Core%\Basic\Build\4 - buildModel.Script

%WBMScript%=%Core%\Basic\!WBManager\!WBManager.Script

%OptionsScript%=%Core%\Basic\!WBManager\!myOptions.Script

%ReOpenScript%=%Core%\Tools\ReOpen.Script

%OLESupportScript%=%Core%\Basic\Build\7 - OLESupport.Script

%API%=%ProjectDir%\Basic\Build\api.script

Add_Shortcut=Run,%API%,AddShortcut

Require_File=run,%API%,Expand_file

Unpack=Run,%API%,Depack

%reg_temp%=wb-hive

%reg%\=%reg_temp%\

hive_load=run,%API%,reg_hiveload

hive_unload=run,%API%,reg_hiveunload

reg_add=RegWrite,"HKLM"

associate_file=run,%API%,do_associate

Not_Compatible=Run,%API%,NotCompatible

Process_log=Run,%ScriptLog%,Process-log

//Api_Cmd=run,%API%,ExecuteApiSection

CopyProgram=run,%API%,Copy_Program

Add_Asso=Run,%API%,Association

%Target_prog%=%TargetDir%\Programme

%PE_Programs%=%SystemDrive%\Programme

reg_del=RegDelete,"HKLM"

_FileCopy=run,%API%,Copy_Files

_Calculate=run,%API%,Calculate

%Debug%=0

%HoJoPELevel%=2

%RAMDriveLetter%=R:

%SettingsDrive%=R:

%ClearTarget%=1

%justCopy%=0

%RegTyp%=0x1

%bootfix%=True

%OS%=XP

%Open%=0

%ActiveShell%=C:\Dokumente und Einstellungen\Peter\Desktop\WB Archiv\Beta8\Projects\LiveXP\Basic\Shells\Explorer.Script

%ExplorerShortcut%=shc-model

Remarkably less than 91 ?????? NO!
With binary search no difference in the range of 64 ... 127

Peter

[Nuno Brito]

Peter, more variables being supported in less time do not justify the need for this command. In fact, I loathe the amount of redundant variables inside a file such as script.project whose existence will continue perpetuated in next decades.


We do not need a setEsc command. Can we please stop adding new commands or at least discuss them before being added?

This tendency to add more and more commands has already left a big mess to recover from the past two years.

Thank you.

[Wonko the Sane]

Sorry Nuno, but I don't get it:

We do not need a setEsc command.

To be honest, I see no added value from having either PERMANENT or SetEsc.

If a developer wants to change a global variable, let them edit directly script.project using ini write.

Project developers shouldn't use script.project for global variables that are continuously changing. This need would be better satisfied at an external file where only the scripts that require these settings will actually read and write them.

Are local and global variables needed? That's a yes/no answer. (IMHO it is yes)
If yes, WHY not having a command to make them instead of using a workaround (writing/reading .ini or external files)?

Is setting a variable value to a variable name needed? That's again a yes/no. (IMHO it is yes)
If yes, why not having the SetEsc? (in any case it won't do any harm if it's not used by anyone)



Wonko

[Wonko the Sane]

UPDATE: In a quick (and swift ) move:
http://reboot.pro/14299/page__st__6
http://reboot.pro/14478/page__st__8
the problem was solved just like a Gordian knot.

I wish to thank for the contribution our leader and Emperor , thanks to him and peter, we now have one less available (and harmless) command and introduced a brand new .script/project version incompatibility.

Sometimes I wonder what the heck is crossing the minds of both.... NO, I don't want to know...


Wonko

[sbaeder]

ARGGGG....

[pscEx]

Sometimes I wonder what the heck is crossing the minds of both.... NO, I don't want to know...

Sorry that I do not respect your privacy. I give you to know.

My intentinon, when I joined this forum, has been:

• Have fun (like you long time ago described in ??? rules)
• Try to help other members with my experience.
• Later: Improve WinBuilder.exe with my experience

When I get messages meaning "You are a complete idiot, you are doing everything wrong", it is funny for me to react with "Undo" and wait how many users miss my function.
If none, ok. If several are missing: Maybe my idiotic functionality was somewhere needed.
For all cases: I am a serious developer, who always commits everything to the SVN. So, whatever I did to have my fun, can be Undo-ed by the Boss.
You have fun in commenting (and finding something ???), I have fun in doing what people want ...

Peter

[paraglider]

I don't think Nuno asked you to remove the command. All he said was he did not understand why it was needed and to ask in future before any new commands were added.

[Wonko the Sane]

@peter
IMHO you are over-reacting.

I guess that the idea was to discuss pro's and con's of an approach vs. the other.

I can see (very faintly, since you did not explain AFAICU the way this particular SetEsc command is actually used) that it can be useful to have local and global variables and to have actual Escaped values available, and personally find completely pointless the idea of using external files or .ini's, which in my perverted mind represents a workaround, a nice one, but still a workaround.

I would like to point the accent on freedom, any .script developer is perfectly free to use this feature, to avoid using it, or using it through the workaround suggested by Nuno or through any other possible workaround.

Since having an additional command, even if never used, won't probably change anything actually relevant in:

• usability
  
• processing speed
  
• binary size

of the application, I don't see any reason to remove it.

On the other hand, everyone has his own "writing style" and it is quite evident that one of the "fun" things in writing .scripts is to find your own ways to do things in any given programming or scripting language, attempts to "force" script developers to use one approach instead of another though undoubtedly carried on in perfect good faith, have been historically proved to provoke, before or later, senseless discussions, reciprocal accuses of not doing the right thing for the development, etc. etc..

So - as often happens and due mainly to mis-communication - a perfectly harmless thing (an added command that everyone is perfectly free to use or not use in any .script) becomes the reason to start a (IMHO completely pointless) fight.

Where is the fun in this?

I know how serious and accurate you are in your programming , but you should relax a bit when it comes to exchanging ideas on the board, what Nuno wrote - though maybe (and IMHO ) in a bit too snappy a manner - should be read as:

I am sorry, but right now I cannot see the utility of that command.
I have the feeling that we could have solved the issue that made you add this command in anohther, IMHO better way.
A good idea would be, in the future, to discuss this kind of issues and their resolutions together before adding new commands, as I fear that adding too many commands may result in an unneeded complexity.
You must understand how adding commands in the actual Winbuilder executable have long lasting consequences and increases the chances of problems in portability of .scripts (or updating them) and/or "versioning nightmare" should the command be later removed or replaced by another one, we must be very careful when changing syntax, even if we only add a harmless command, it is important that we discuss it between us and publicly with the developers.

As opposed to the:

What the heck have you done!

Remove that §@ç#ing command, NOW!
From now on NEVER add a command before consulting me!

Yes, Nuno's posts can be read in BOTH the above ways, but you know him since years, do you really think he meant the second version?


Wonko

[Darijo]

Hey people come down, i only asked for what it is in^^

My project is loading the Global Variables from a seperate File where all global variables are set, as nuno said it, this idea is i also think the best. Global Variables should be set at StartUp and not during runtime (everytime like the readenv) you must think about it that a user who downloads a project doesn't have 100 sources of a windows install dvd, maybe only one, why we need in every script such commands as permanet or readenv. It can be splittet in two modes or something else.

First i Get the Host OS infos like architecture and so on, second i am defining all global variables, the script.project file is more than only readable and clean. Liek the %Cmdexefolder% thing must it be checked in every script? Defenitely not, also the other Tools, a simple if x64 than copy would be the best result, but only in one script.

AddVariables,%ScriptFile%,Section,Global can do this %OneVariable%=%MyVariable% it is working for me i add a section of the global variables file in one line. No need to set permanent or someting else. Everything is done before the project starts to build something, and than the other scripts only need to do its work, if someone don't likes my variable names they can be changed, with the cool functionality replace all of a normal editor, this is also one of the easyest thigns.

%VariablefromOtherProject%=%MyVariable% i also use to raise the compability between my project and others. ReadEnv and anything else aren't needet, it works with this way anyway. these are readen at startup also from a other file, where only such things are defined.

I hope i could write what i am thinking, the best way is to read all global things during startup, flexible variables and so on can be also set during buil. if a variable is needet in a other script than we can use also glabal empty variables, like %Value=""
then the set command successfully changes in my way the "" to the new value which is everywhere available.





And the last thing is, as psc said it, the new method of winbuilder is so fast, that setting hundrets of variables are not important, i see on the one site nunos idea good and pscs idea good.

Why you to don't combine them togheter? New Features that deosn't infect old scripts aren't bad, and old features that fixes workaroounds from old projects are neccessary, if users like i don't wont to use a capi, which is developed by others, to make the builder slower.


I think it makes no sense to post here bugs, everybody is going his own way, it is only a ... of time.

[Wonko the Sane]

Just for the record, everything is seemingly cool again.

http://reboot.pro/14299/page__st__7

Once again a solution has been found, a wrong one , but a solution nonetheless .

Wonko approves of this.


Wonko