Hi Carl,
Equates.clw for Builds 13505 and 13729 are identical
Property.clw for 13729 is different…
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
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.
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.