Clarion11.1 PE - Build 13729 Pre-Release!

Release notes in the email point to the last release - Sept. 11, 2020
Anyone know what is supposed to be in this pre-release?

No email here yet. One guess is an updated Anyscreen preview and some not-so-major acknowledged bug fixes.

You’ll only be receiving the pre-releases if you’ve emailed [email protected] with a Subject of ‘AnyScreen 1.2 pre-release testing’.

The latest version is another update for AnyScreen but doesn’t come with a list of fixes for either Clarion 11.1 (yes it’s officially 11.1 now) or AnyScreen.
Also the wrong BUITLINS.CLW file has been shipped !

I guess this build is different, because I got an email this time too. I wasn’t registered as a tester. Maybe I received because of 3rd party.

1 Like

I see nothing new when I compare Builtins.clw from my 13505 to 13729 posted by Marko in SV.Discuss.

It’s hard to compare due to the OMIT / COMPILE(’***’,AnyScreenPresent) that replace normal RTL functions. I sorted the file and deleted the comments then compared just code lines, that worked well.

There are some new AS replacements (like ALERT) and some no longer replaced (like DESTROY), nothing new. Old functions named Xxxx_Old() are now Xxxx_RTLCode() and there are less (15 vs 23), e.g. MOUSEX_OLD() is MOUSEX_RTLCore() . I don’t know what those are about.

  !--- No AnyScreen ---
    ALERT(SIGNED firstKeycode=0, SIGNED lastKeycode=0),NAME('Cla$ALERT')  

  !--- With AnyScreen ---
    ALERT(SIGNED firstKeycode=0, SIGNED lastKeycode=0),NAME('RisNet:Alert')
    ALERT_RTLCore(SIGNED firstKeycode=0, SIGNED lastKeycode=0),NAME('Cla$ALERT')

If someone has the install I would like to compare Equates and Property.

Hi Jeff,

I think you’re right - we’ve now had 2 sets of pre-release emails.
The second one from [email protected] says

You are being sent this information as a member of the Clarion Core Subscription Program

So it looks like everyone with a CSP will get Build 13729

1 Like

Hi Carl,

Equates.clw for Builds 13505 and 13729 are identical
Property.clw for 13729 is different…

There is one new PROP:

! Oracle Driver Properties
PROP:NullsInKeys        EQUATE (7263H)

I think for the first time some equates have changed value (number). I can see it for the 2 font properties so the {Font,array} works, but I wonder why for others. Maybe it makes ranges that are easier to check for AS. I’ll have some changes to make in my Wnd Preview Class.

Equate Old New Notes
PROP:FontCharSet 7A3Ah 7C14h Now Font,5 - Reuses Prop:RangeLow Prop:Range,#
PROP:CPI 7C5Bh 7C15h Now Font,6 - Reuses Prop:RangeHigh
PROP:StatusFont 0014h 0016H
Prop:Range 7C14h 7CE0h Moved just above Sheet Props at 7CE2h
Prop:RangeLow 7C14h 7CE0h Old 7C14h now PROP:FontCharSet
Prop:RangeHigh 7C15h 7CE1h Old 7C15h now PROP:CPI
PROPLIST:MouseDownRow 7C20h 7ED0h Other PROPLIST are 7E00h - 7E33h
PROPLIST:MouseMoveRow 7C21h 7ED1h so new range makes sense
PROPLIST:MouseUpRow 7C22h 7ED2h
PROPLIST:MouseDownField 7C23h 7ED3h
PROPLIST:MouseMoveField 7C24h 7ED4h
PROPLIST:MouseUpField 7C25h 7ED5h
PROPLIST:MouseDownZone 7C26h 7ED6h
PROPLIST:MouseMoveZone 7C27h 7ED7h
PROPLIST:MouseUpZone 7C28h 7ED8h
PROPLIST:Grid 7C29h 7ED9h
PROPLIST:BarColor 7C29h 7ED9h Same a Grid for compatibility with 1.5
PROPLIST:DefHdrTextColor 7C2Ah 7EDAh Text color in header
PROPLIST:DefHdrBackColor 7C2Bh 7EDBh Background color in header
PROPLIST:HdrSortTextColor 7C2Ch 7EDCh Text color in header of sort column
PROPLIST:HdrSortBackColor 7C2Dh 7EDDh Background color in header of sort column
PROPLIST:SortTextColor 7C2Eh 7EDEh Text color of sort column
PROPLIST:SortBackColor 7C2Fh 7EDFh Background color of sort column
PROPLIST:HasSortColumn 7C30h 7EE0h TRUE if sort column is supported - new v9
PROPLIST:SortColumn 7C31h 7EE1h Current sort column - new v9

Someone with 13729 could test the _C111_ symbol works with the new equate PROP:NullsInKeys

  COMPILE('**END 11.1**', _C111_)
      Message('New PROP:NullsInKeys = ' & PROP:NullsInKeys )
  !end of COMPILE('**END 11.1**', _C111_)

Hi Carl,

Yep that works and the message displays in Build 13729

The build doesn’t correctly set the Registry values at the moment (been reported to RZ) still shown as Clarion11

1 Like

MouseLeft now shuts off the power and EscKey opens



I also pay for the CSP (the auto update program, isn’t it?)
But I didn’t get an email yet.



Have you tested that the Calling Function as Procedure bug has been fixed? Where it does not make the call unless PROC is added.

That fails in Build 13630 but passes and displays the

Test13630IgnoreReturn() all done

message in Build 13729 - so AFAICS it’s fixed :slight_smile:

Very disappointed after quick testing with the Pre-Release.
Basic AnyScreen problems long ago reported in PTSS with simple code examples still exist.
My understanding was this pre-release would include latest AnyScreen bug fixes.

Marko seems to be trying to fix everything that has been reported and he can reproduce.

Post at least some details of what problems you found. Best to post in sv.clarion.anyscreen but if you can’t then post them here and ask they be reposted. Attach any project and code zipped up so it is easy to reproduce.

Below is my test code. AnyScreen displays an incorrect option value when I test.


SampleWindow WINDOW(‘Sample Window’),AT(,252,150),CENTER,GRAY,FONT(‘Tahoma’,10)
OPTION(‘Op&tions’),AT(10,26,100,52),USE(lRadio,?OPTION), |
RADIO(‘Selection O&ne’),AT(20,38),USE(?RADIO:1)
RADIO(‘Selection &Two’),AT(20,50),USE(?RADIO:2)
RADIO(‘Selection T&hree’),AT(20,62),USE(?RADIO:3)
lRadio = 3
OF EVENT:Accepted


The USE() looks invalid to me. Have you tried without the ?Option or with 2 commas. It won’t compile.

Also define " displays an incorrect option value"? Do you mean when the window opens its not selected to radio 3?

I think the ?Option was included in error.
If you take it out and resize the window using the designer then it all runs.
As a desktop app radio 3 is correctly selected at startup…
As an AnyScreen app radio 1 is selected in error.

The USE is fine in my test. The double comma was lost in the copy of code here.
Just test with the variable only as the option use.
As a windows app, radio 3 is selected, As an AnyScreen app radio 1 is selected.
Nothing fancy. This is basic stuff.

I will refrain from going into the unfixed combo problems for the time being.

I actually reported the problem with the Option control on the AnyScreen newsgroup back in November last year and Marko responded that it was fixed in the upcoming build.
Obviously it’s broken again :frowning:

The workaround is to assign VALUE(s) to each option eg

                                    RADIO('Selection O&ne'),AT(20,38),USE(?RADIO:1),value('1')
                                    RADIO('Selection &Two'),AT(20,50),USE(?RADIO:2),value('2')
                                    RADIO('Selection T&hree'),AT(20,62),USE(?RADIO:3),value('3')

With the VALUE(s) assigned it will select radio 3 in AnyScreen mode.

I’ll repost the issue on the newsgroup.

1 Like