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 Clarion-edelivery@SoftVelocity 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 myspace.com.
3 Likes
Hi,
I also pay for the CSP (the auto update program, isn’t it?)
But I didn’t get an email yet.
René
Thanks
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 
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.
AnySampleProc PROCEDURE
END
INCLUDE(‘AnyScreen.inc’)
INCLUDE(‘KeyCodes.clw’)
CODE
AnySampleProc
AnySampleProc PROCEDURE
lRadio LONG,AUTO
SampleWindow WINDOW(‘Sample Window’),AT(,252,150),CENTER,GRAY,FONT(‘Tahoma’,10)
BOX,AT(1,1,250,108),USE(?BOX),COLOR(COLOR:Black),LINEWIDTH(1)
SHEET,AT(1,110,250,12),USE(?SHEET),SPREAD,NOSHEET,BELOW,IMM
TAB(‘Option’),USE(?TAB:Option)
OPTION(‘Op&tions’),AT(10,26,100,52),USE(lRadio,?OPTION), |
BOXED
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)
END
END
END
BUTTON(’&OK’),AT(130,127,60,20),USE(?BTN:Ok),LEFT
BUTTON(’&Cancel’),AT(191,127,60,20),USE(?BTN:Cancel),LEFT
END
CODE
AnyScreen:Init()
OPEN(SampleWindow)
lRadio = 3
ACCEPT
CASE EVENT()
OF EVENT:Accepted
CASE ACCEPTED()
OF ?BTN:Ok OROF ?BTN:Cancel
BREAK
END
END
END
CLOSE(SampleWindow)
AnyScreen:Kill()
RETURN
OPTION(‘Op&tions’),AT(10,26,100,52),USE(lRadio,?OPTION),BOXED
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 
The workaround is to assign VALUE(s) to each option eg
OPTION('Op&tions'),AT(10,26,100,52),USE(lRadio),BOXED
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')
END
With the VALUE(s) assigned it will select radio 3 in AnyScreen mode.
I’ll repost the issue on the newsgroup.
1 Like