Clarion11.1 PE - Build 13729 Pre-Release!

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

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

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

I posted a PTSS on it in Sept with a followup in Oct. Of course, never got an SV response as to status.

I appreciate the efforts of Marko in the AnyScreen newsgroup. However, SV sets themselves up to fail when they ignores and/or try to informally substitute for their own bug reporting system. As I have said in the past, SV long ago banned me from their newsgroups so I am unable to contribute other than through a PTSS.

Thanks for your help. Just tested with VALUE and it is indeed a work around I hopefully can use.
On to testing my other issues that were identified last fall.

PTSS 43103 (and 43102) - actually there was a response from Daniel Pavlic 2020/10/12 as follows…

If you assign values for all radio entries it will work. We will fix non-valued radio entries for the next build.

One of the glaring omissions from the PTSS system is the lack of notification by email of responses that are made or questions that are asked.
Crazy really developers can’t be expected to check back again and again on the off chance.

Recently I posted a OPTION to Drop List convertor here. In 13505 there was no PROP to tell the Option was using the Radio Child Index number. When no VALUE() is specified in code the PROP:Value always returns PROP:Text without the Ampersand. So SV will need to either change PROP:Value or have a new PROP.

I can agree about the lack of email, but the true glaring omission looks to be having the report status remain as Submitted even when SV has read or responded. My habit has always been to quickly look at what the PTSS list shows. Silly me for not checking each one further.

Posted in sv.anyscreen …

The possible issue I see is when there is no VALUE() the PROP:Value returns the Radio PROP:Text without the &Amp. So in my example below Radio 2 PROP:Value returns ‘2’ but Radio 3 returns ‘Three’ for PROP:Value.

That’s the PROP … Complicating further is if the OPTION USE() is a Number (LONG) then it gets the Child Index 1,2,3 but if the USE is a STRING then it gets ‘One’,‘2’,‘Three’.

I guess Marko could have it work two different ways by checking if the PROP:Use IsString(). IMO this must be fixed as it is quite common to have OPTION using the Radio child index so could break a lot of code. Maybe the compiler could help by spotting the USE() is a numeric and adding the VALUE(Index) to the Radio.

lRadio LONG       !number gets Radio Index number
lRadio STRING(9)  !Alternate gets String Value()

    OPTION('Op&tions'),AT(10,26,100,52),USE(lRadio),BOXED
        RADIO('O&ne'),AT(20,38),USE(?RADIO:1)
        RADIO('&Two'),AT(20,50),USE(?RADIO:2),VALUE('2')
        RADIO('T&hree'),AT(20,62),USE(?RADIO:3)
    END

For option values that are local to the procedure, I usually just use ChoiceFEQ and do not assign employ a variable in USE (ie USE(?MyOption).

VALUE has always required a string. If I include it on RADIOs, my habit has been to create equates in order to have a meaningful label (ie FirstValue EQUATE(‘1’)). I will never have a RADIO with VALUE(‘1’) or even VALUE(‘A’).

As for AnyScreen, I don’t care what is done as long as I know how to have the same code work both as a desktop app and with AnyScreen.