Jump to content











Photo

Quote, Comma, Space


  • Please log in to reply
35 replies to this topic

#1 pscEx

pscEx

    Platinum Member

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

Posted 06 March 2009 - 11:43 AM

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

#2 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 06 March 2009 - 12:13 PM

A couple of questions, as a Total n00b. :cheers:

Is there a reason to use comma as a separator? :cheers:

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"? :cheers:
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 :cheers:

:cheers:

jaclaz

Attached Files



#3 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 06 March 2009 - 12:29 PM

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.

#4 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 March 2009 - 12:31 PM

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.

:cheers:

#5 pscEx

pscEx

    Platinum Member

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

Posted 06 March 2009 - 12:46 PM

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

#6 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 06 March 2009 - 01:29 PM

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? :cheers:

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? :cheers:

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?


:cheers:

jaclaz

#7 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 March 2009 - 02:42 PM

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

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


:cheers:

#8 pscEx

pscEx

    Platinum Member

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

Posted 06 March 2009 - 02:45 PM

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

#9 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 March 2009 - 03:33 PM

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

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?

:cheers:

#10 pscEx

pscEx

    Platinum Member

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

Posted 06 March 2009 - 03:44 PM

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

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?

:cheers:

Try this:

&#91;process&#93;

Set,%Var%,BlaBlaxBlaBla

Echo,%var%

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

Echo,%var%

Set,%Var%,Text%var%othertext

Echo,%var%

Peter

#11 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 March 2009 - 04:42 PM

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.

:cheers:

#12 pscEx

pscEx

    Platinum Member

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

Posted 06 March 2009 - 04:46 PM

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.

:cheers:

We should try to catch them one after the other!

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

Peter

#13 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 06 March 2009 - 08:32 PM

And by the way what about my small suggestion of making a SciTE "extra"? :cheers:
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.

#14 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 07 March 2009 - 06:33 PM

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


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

Help the poor peter! :cheers:

Be warned :cheers:, 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....:cheers:

:cheers:

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

:cheers:

#15 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 09 March 2009 - 09:30 AM

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

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.

#16 pscEx

pscEx

    Platinum Member

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

Posted 18 April 2009 - 11:34 AM

With WB 077 beta allanf found a new issue.

The code
Set,&#34;%List%&#34;,&#34;a,b,c&#34;

   Run,&#34;%ScriptFile%&#34;,Test,%list%

   

   &#91;Test&#93;

   Echo,&#34;#1&#34;

   Echo,&#34;#2&#34;

   Echo,&#34;#3&#34;
formerly resulted in:

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

Posted Image a
Posted Image b
Posted Image c

With 077 beta 1 you get:

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

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

#17 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 19 April 2009 - 04:38 AM

With WB 077 beta allanf found a new issue.

The code

Set,&#34;%List%&#34;,&#34;a,b,c&#34;

   Run,&#34;%ScriptFile%&#34;,Test,%list%

   

   &#91;Test&#93;

   Echo,&#34;#1&#34;

   Echo,&#34;#2&#34;

   Echo,&#34;#3&#34;
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 :)

#18 pscEx

pscEx

    Platinum Member

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

Posted 19 April 2009 - 08:06 AM

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

#19 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 19 April 2009 - 09:11 AM

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

#20 pscEx

pscEx

    Platinum Member

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

Posted 19 April 2009 - 10:27 AM

Ever tried running a project other than your own?

Yes

Peter

#21 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 19 April 2009 - 10:31 AM

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?

#22 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 19 April 2009 - 11:36 AM

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.

#23 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 19 April 2009 - 11:49 AM

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

#24 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 19 April 2009 - 11:54 AM

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.

#25 allanf

allanf

    Gold Member

  • .script developer
  • 1256 posts

Posted 19 April 2009 - 12:09 PM

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users