Jump to content











Photo
- - - - -

WinBuilder 081 beta 1


  • Please log in to reply
3 replies to this topic

#1 pscEx

pscEx

    Platinum Member

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

Posted 19 April 2010 - 09:30 AM

What's really new in WinBuilder 81 beta 1?

1.The Script Engine is redesigned to limit the use of escapes to a minimum.

A WinBuilder command line is a series of parameters, separated by commas.

'Parameter' is the literally readible part of the command line. If one parameter contains a variable, only the name of the variable is important, independent from it's content.

Rule #1: If a parameter contains a comma, and only if it contains a comma, the parameter must be enclosed by quotes!
In all other cases quotes around parameters are not necessary and internally removed by WinBuilder.

Spaces do not need surrounding commas any more:
This
[variables]

%HalAll%=Hallo World!

%hal1%=Hallo

%hal2%=World!



[process]

Echo,Hallo world!

Set,%hal%,Hallo world!

Echo,%hal%

Echo,%halAll%

Echo,%hal1% %hal2%
in all cases outputs Hello World!

When %variables% are used as parameters, the meaning of a comma is decided 'intelligent' by WinBuilder.

Sample: %var%="00,43,72" in a RegWrite 0x3 is decided to be three binary bytes. In a RegWrite 0x1 it is supposed to be a string.
If the result is not that what the user assumes, especially in RegWrite 0x7 commands, he should use escapes.

Escapes: Sample: If the user wants to output the name of a variable, rather than it's content, he has to use the escape #$p.
Escapes ase passed through all internal processing, e.g. in the parameters of a 'Run' command.
Ony in the last step when transferring to the 'Outer World' e.g. as file system name, as registry key or value, as INI key or value, it it translated to the final value.

Description of possible escapes see in the WinBuilder syntax manual.

This beta brought a new escape, the ##<num>, where <num> is a digit 1 .. 9 or the character c.
Here the final output is #<num>(#1 .. #9 are used as parameters, #c as loop counter.)

Rule #2: If your output does not have the assumed result, try escapes!
I found only one script in LiveXP, which is affected by the new ##<num> logic: RemovableDevicesCombo.script

This script has to be changed to work WB version dependent:
If,%Version%,SMALLER,81.01,Begin

  RegWrite,HKLM,0x1,&#34;WB-Setup\ControlSet .. Database\1394%hash%609E&10483&#34;,&#34;ClassGUID&#34;,&#34;{d48179be-ec20-11d1-b6b8-00c04fa372a7}&#34;

  RegWrite,HKLM,0x1,&#34;WB-Setup\ControlSet001\Control\CriticalDeviceDatabase\1394%hash%609E&10483&#34;,&#34;Service&#34;,&#34;sbp2port&#34;

End

Else,Begin

  RegWrite,HKLM,0x1,&#34;WB-Setup\ControlSet .. Database\1394##609E&10483&#34;,&#34;ClassGUID&#34;,&#34;{d48179be-ec20-11d1-b6b8-00c04fa372a7}&#34;

  RegWrite,HKLM,0x1,&#34;WB-Setup\ControlSet001\Control\CriticalDeviceDatabase\1394##609E&10483&#34;,&#34;Service&#34;,&#34;sbp2port&#34;

End

2. The Interface Editor is redesigned to allow multiple selection of elements,

which can be adjusted, resized, moved, deleted as a group.


3. Incompatibilities:

  • Background of labels is not longer transparent and may overlap other elements.
    I hope to have this fixed next beta. So for beta tests only no changes of the interfaces is necessary.

  • Variables used as %MyMacro% is not longer tolerated, but marked as error.
    A change from %MyMacro% to the syntax conform MyMacro is fully back compatible.

  • Maybe some results of RegRead / RegWrite and IniRead / IniWrite are different from the results in WB 080 and earlier.
    The older versions have a buggy behaviour which is fixed now.

When you

  • Write something
  • Read back
  • Write again,
the result of the first and second write should be identic.

IniRead / IniWrite of

[Section]
Comma=Bla,bla
CommaQ="Bla,bla"
CommaT=#$qBla,bla#$q

Results in the wrong second output

[Compare]
Comma=Bla,bla
CommaQ=Bla,bla
CommaT="Bla,bla"

with WB 080-3

and in the correct second output of

[Section]
Comma=Bla,bla
CommaQ="Bla,bla"
CommaT=#$qBla,bla#$q

with WB 081 beta.

Sorry, script commands which are written empirically to workaround the bugs, have to be rewritten.

Peter

#2 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7,771 posts

Posted 19 April 2010 - 04:23 PM

When %variables% are used as parameters, the meaning of a comma is decided 'intelligent' by WinBuilder.

Never would have thought, to read a sentence like that, from a developer, who hates M$Word intelligent behaviour as much as you. :cheers: :ranting2:

:ranting2:

#3 pscEx

pscEx

    Platinum Member

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

Posted 19 April 2010 - 04:27 PM

Never would have thought, to read a sentence like that, from a developer, who hates M$Word intelligent behaviour as much as you. :ranting2: :cheers:

:ranting2:

But there are several developers teams like e.g. Don Galapo and Lance Pansa demanding it heavily.

And since no developer did contradict that demand, I assumed that it is the demand of the majority.

Peter :ranting2:

#4 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5,013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 19 April 2010 - 06:34 PM

Never would have thought, to read a sentence like that, from a developer, who hates M$Word intelligent behaviour as much as you. :ranting2: :cheers:

:ranting2:

But there are several developers teams like e.g. Don Galapo and Lance Pansa demanding it heavily.

And since no developer did contradict that demand, I assumed that it is the demand of the majority.

Peter :ranting2:


To avoid misunderstanding from above childish post, here is clearification:

WINBULDER BUG HAD BEEN reported by Galapo and Lancelot looong time ago due to above situation.

Neither Galapo nor Lancelot (me) NEVER request a "intelligent behaviour" as a solution of this winbuilder behaviour.

I requested none intelligent solution loong time ago in the past, which ignored, hence today Winbuilder Core DEVELOPMENT (=psc) decide to fix with "intelligent behaviour"

Consequences of this "intelligent behaviour" solution to the very old known bug, either good or bad, all credits to Winbuilder Core DEVELOPMENT (=psc).