35 replies to this topic

[pscEx]

In the last days with rather complicated variables the question came up that WinBuilder's variables handling sometimes fails.

Here a short explanation what can be done and what cannot be done.

First some rules:

• WinBuilder Script Line Parameters are separated by a comma.
  If a comma is inside an argument, it must be 'escaped' by #$c
• Besides some special cases (e.g. parameters in ShellExecute) generally enclosing quotes are not needed.
• Enclosing quotes MUST be used if the WinBuilder Script Line Parameters contain spaces
  If the spaces are replaced by the escape #$s, the enclosing quotes should be ommitted.

In most cases user violation of that rules are accepted by WinBuilder and processed as assumed.
E.g. unnecessary enclosing quotes or a comma inside an item enclosed by quotes.

But sometimes that can bring unexpected results.

Let me give an Example:

Item1,item2 is understood as two items, separated by the comma.
Item1#$citem2 is correctly written to have one item with the comma inside.
"Item1,item2" is wrong written, but by WinBuilder also understood as one item.

Now the problem-version:

Set,%Var%,"Item1","item2" cannot be understood uniquelly by WinBuilder.

Let's exchange the English understandable words by the chracter 'x'

"xxxxx","xxxxx"

Are there two quote-enclosed xxxxx, separated by a comma? > Set,%Var%,xxxxx
Or is there on long string of 10 xes, interrupted by a nested quote pair containing a comma? > Set,%var%,xxxxx#$q#$c#$qxxxxx
Or is there on long string of 10 xes, interrupted by a nested quote pair 'escaping' a comma? > Set,%var%,xxxxx#$cxxxxx

You see how important it is to follow the rules, even if WinBuilder understands most violations correctly.

Peter

[was_jaclaz]

A couple of questions, as a Total n00b.

Is there a reason to use comma as a separator?

I ask because it seems to me as a less than "optimal" separator, as it can be confused with fullstop.

As a personal (maybe wrong, mind you) opinion, it is wrong to have an "intelligent" parser that "understands" possible syntax errors and allows them, as it is possible that such a feature favours the use of uncorrect syntax that may later become alltogether WRONG in a later version of Winbuilder.

Can we say that theoretically we could import a .script in a csv table and export it back without "losing" anything?

For example, could we use something like Record Editor:
http://record-editor.sourceforge.net/

to view a .script?

And by the way what about my small suggestion of making a SciTE "extra"?
http://www.scintilla.org/SciTE.html
http://groups.google...eb/extras?pli=1

I am attaching a screenshot of the same batch file opened in SciTE and in Notepad, as an example



jaclaz

Attached Files

•  scitebatch.jpg   125.58KB   179 downloads

[paraglider]

Scripts would have been much easier to understand if " was used to delimit problem parameters instead of having to replace many common characters. Then only one escape character would be required for most cases - one for embedded ". If you come from the c world then the \" would be used as the escape character or vb then "" is more natural.

[MedEvil]

To cite another topic, fault tolerance is not a good idea.
Interactions of the user with a program should be fault tolerant, but not a code parser. That one should complain about everything and anything even just remotely wrong!

Ideal would be of course, when Wb could show syntax errors not only after a run, but actually while writing.

[pscEx]

Ideal would be of course, when Wb could show syntax errors not only after a run, but actually while writing.

Jaclaz's pointing to syntax highlighters let the idea allready come up for me.

But that's a looong way.

I already also thought about a 'parse run' which is a mini build just reading the lines, check the number of argument, etc.

@Jaclaz:
the comma as separator is historic, and in my opinion choosen by Nono, because of the Deplhi object 'TStringList'

Here can you set the CommaText property with your script line, and you'll get an array of the single parameter strings.
That's propably much faster than a user made split function. And if you imagine that this split is processed very often ...

About 'Fault tolerance' I have the same opinion like you. Look here
About Recour Editor: Give some time. Currently I'm decreasing the number of 'Unfixed' in the Bug Tracker.

@Paraglider:
You are right wit the "quote" idea. But to realize would be difficult because of many incompatibilities occurring then.

Peter

[was_jaclaz]

I already also thought about a 'parse run' which is a mini build just reading the lines, check the number of argument, etc.

I.e. the pre-processor I was ranting about?

First thing:
I am impressed by the usefulness of the WBverify approach by psc, my suggestion is to extend it's functionality as to make it become a pre-processing engine for Winbuilder.

Example:
I intentionally damaged (removing a number of files) a source directory and started the processing after several minutes, Winbuilder came up with a log full of errors of the type "Failed to copy or expand....".

Wouldn't it be easier (and faster) to pre-check the Source, or simply stop the execution of the build when such an error about a missing file is generated?

At least for the "core" components, and wouldn't be more informative having a "Source file xxxx does not exist, check given path and files within it" report?

jaclaz

[MedEvil]

Since we touched on the topic of variables.
WB has special reuirements for variables because of the many path variables we use.
Imo, the idea to use "" only when needed is a bit problematic. Cause every variabled that could contain a space, which are all variables used to store paths, needs to be enclosed in "", just in case. But that would on my machine be wrong, since i have no space in any paths.

Hence can the scriptwriter never know, if "" are needed or not. Only at buildtime is this decision possible, so WB has to make it.
Which brings us to the question, how WB should switch without screwinging up the values.

The only other solution would be to force people to eighter have never spaces in their path or always.

[pscEx]

I think you see it wrong.

The space is due to 'what is written in script'.

As far as I know, a space inside e.g. a path variable will not harm.

Intentionally the %BaseDir% for all three WinBuilder programmers is <somewhere>\WB Debug.

And we never have had any troubles using %BaseDir% w/o quotes.

Peter

[MedEvil]

I remember, when i came here, there were lots and lots of problems connected to people simply having spaces in their path. So that everyone and their dog started adding "" whereever possible.

But just to be very clear, if i give a variable a content that has a space in it, but is not enclosed in "" and use this variable in a command without enclosing it in "", then still the whole content of the variable is used and not just the part before the space?

[pscEx]

I remember, when i came here, there were lots and lots of problems connected to people simply having spaces in their path. So that everyone and their dog started adding "" whereever possible.

But just to be very clear, if i give a variable a content that has a space in it, but is not enclosed in "" and use this variable in a command without enclosing it in "", then still the whole content of the variable is used and not just the part before the space?

Try this:

[process]

Set,%Var%,BlaBlaxBlaBla

Echo,%var%

StrFormat,REPLACE,%var%,x,#$s,%Var%

Echo,%var%

Set,%Var%,Text%var%othertext

Echo,%var%

Peter

[MedEvil]

Your example works flawless with or without "" in WB076, what makes me even more curious, why they heck WB076 screws up so many registry entries of my project.

[pscEx]

Your example works flawless with or without "" in WB076, what makes me even more curious, why they heck WB076 screws up so many registry entries of my project.

We should try to catch them one after the other!

But for that I should know at least some of them!

Peter

[Galapo]

And by the way what about my small suggestion of making a SciTE "extra"?
http://www.scintilla.org/SciTE.html
http://groups.google...eb/extras?pli=1

Actually, I use both the WB Editor as well as SciTE for script editing and development.

Regards,
Galapo.

[was_jaclaz]

Actually, I use both the WB Editor as well as SciTE for script editing and development.

Then, write a §@ç#ing extra for it!

Help the poor peter!

Be warned , I am already through most of the pages of this book:
http://www.boot-land...?...c=5107&st=4

I could go and buy fake another one with the word "Galapo" in the title....



New thread where psc will need your (or anyone else's) help:
http://www.boot-land...?...ic=7344&hl=

jaclaz

P.S.:
@psc
Very good work, and all done in no more than a couple Latin hours! :

[Galapo]

Then, write a §@ç#ing extra for it!

Ha, because it takes time! Simple as that. I've toyed with the idea off and on, but haven't got around to it.

Sorry,
Galapo.

[pscEx]

With WB 077 beta allanf found a new issue.

The code

Set,"%List%","a,b,c"

   Run,"%ScriptFile%",Test,%list%

   

   [Test]

   Echo,"#1"

   Echo,"#2"

   Echo,"#3"

formerly resulted in:

Processing section: [Test] From file: [%BaseDir%\Projects\nativeEx_barebone\CodeBox.txt]

a
b
c

With 077 beta 1 you get:

Run - Processing section: [Test] From file: [%BaseDir%\Projects\nativeEx_barebone\CodeBox.txt]
with parameters: [a,b,c]
a,b,c

Simple fact: A bug is fixed. It cannot be allowed that a comma in a 'Run' parameter splits the parameter.
Otherwise it would be impossible to pass a parameter string containing a comma.

Sorry, allanf:
Here it is not possible to preserve a 'back compatibility'.
A script which (assuming and believing that everything is ok, I beg your pardon) uses the 'features of a bug' must be revised after the bug has been fixed.


Peter

[allanf]

With WB 077 beta allanf found a new issue.

The code

Set,"%List%","a,b,c"

   Run,"%ScriptFile%",Test,%list%

   

   [Test]

   Echo,"#1"

   Echo,"#2"

   Echo,"#3"

formerly resulted in:


With 077 beta 1 you get:


Simple fact: A bug is fixed. It cannot be allowed that a comma in a 'Run' parameter splits the parameter.
Otherwise it would be impossible to pass a parameter string containing a comma.

Sorry, allanf:
Here it is not possible to preserve a 'back compatibility'.
A script which (assuming and believing that everything is ok, I beg your pardon) uses the 'features of a bug' must be revised after the bug has been fixed.


Peter

We understand your desire to break all projects other than those based on your nativex. You certainly trashed VistaPE.

BTW. Your logic is flawed. It is not and never was a bug.

If you wish to shape winbuilder to your own projects, please post the script that you have, in this particular case, designed winbuilder to run.

Regards

[pscEx]

We understand your desire to break all projects other than those based on your nativex. You certainly trashed VistaPE.

BTW. Your logic is flawed. It is not and never was a bug.

If you wish to shape winbuilder to your own projects, please post the script that you have, in this particular case, designed winbuilder to run.

Regards

Allanf, please be objective.

You know that syntax is not project depending.

And in VistaPE (complete download) there are 250 'Run' command lines.
None of them uses the 'combine parameters' method.

Peter

[allanf]

You know that syntax is not project depending.

And in VistaPE (complete download) there are 250 'Run' command lines.
None of them uses the 'combine parameters' method.

WHAT?

Ever tried running a project other than your own?

Where is the script that lead you to break this feature of winbuilder? Or did you just do it for the fun of it?

Regards

[pscEx]

Ever tried running a project other than your own?

Yes

Peter

[allanf]

Yes

Peter

You find that amusing?

Where's the script that lead you to break an important feature of winbuilder. Or do I now confirm that you did it out of malice?

[paraglider]

Seems like a sensible change to me. However as it does introduce compatibility problems maybe you should make it optional at the script level i.e. require a new option in the [main] section of a script to enable the new syntax.

Would not like winbuilder to be like MS products which never seem to care about compatibility with earlier versions of the product.

[allanf]

Seems like a sensible change to me. However as it does introduce compatibility problems maybe you should make it optional at the script level i.e. require a new option in the [main] section of a script to enable the new syntax.

Would not like winbuilder to be like MS products which never seem to care about compatibility with earlier versions of the product.

Then perhaps you can put forward a script that uses the new feature that lead to psc to break the old feature. Seems ridiculous to me.

Regards

[paraglider]

Anything that eliminates the need for the myriad of escape sequences that make scripts difficult to write and even worse difficult to understand once they are written is a great goal.

[allanf]

Anything that eliminates the need for the myriad of escape sequences that make scripts difficult to write and even worse difficult to understand once they are written is a great goal.

I don't think that's the reason why the feature was broken. Certainly hasn't been mentioned before.

We are talking about assigning an array of comma-separated parameters to a variable. Now that is a great feature, which psc knew I used in my project and decided to break. Nice one.

Regards