To Amend the previous statement regarding UFOs…
The current UFO Interface is used to create all current data types and we can confirm runs with Clarion 11.
One data type is not supported at present for Runtime creation and that is the Unicode type.
All other types are supported in the published interface and data type structures.
New UFO implementation does not affect building compound objects at run time.
This wasn’t implemented when I left SV. Proposed implementation would be more flexible in importing of the type information from existing objects and building it from the scratch. But programs using corresponding interfaces would have to us them and not assume how they are implemented in the RTL.
TQueueHeader GROUP,TYPE !
BufferPtr LONG ! +0h
FieldsDefPtr LONG ! +4h
QueRBlock LONG ! +8h
BufferSize SIGNED ! +0Ch
END
I assume this structure from DLIB and its code that gets or set a queue pointer structure is no longer valid?
A ; are you saying a recompiling of the client side code be required. IE a recompile of XLIB or DLIB code base..
“But programs using corresponding interfaces would have to us them and not assume how they are implemented in the RTL”
A ; are you saying there will be INTERFACES for creating runtime structures and the code bases from DLIB would have to be modified to use the new interfaces?
I wrote about the type descriptor - the 2nd field of the QUEUE control block. It was proposed to have such descriptor in another form. The QUEUECB itself remains unchanged. Though, if to think, it would be good to move last field (buffer size) to the second place. In this case, first 2 fields would be a correct &STRING value.
All old products working with type descriptors would become outdated. Program would require use a new interface.
I don’t know current plans of SV in this direction.
Well Alexi , may we assume it is MR XLIB himself…
Ok if this new architecture is implemented; we would have to contract an expert to update the code base or instruct and advise.
We have simply been spoilt with XLIB and DLIB…
To live without these products is simply not acceptable.
BufferPtr LONG ! +0h
FieldsDefPtr LONG ! +4h
QueRBlock LONG ! +8h
BufferSize SIGNED ! +0Ch
END
Alexi are you saying that the authors of DLIB have field 4 in the wrong order and it should be moved back to position 2.
havnt compiled and tested it yet…This queue control block currently works and creates a queue control block that works.
I believe, you’ll find one. Not me. Do not ask why.
No. Just it would be logical to have buffer address and buffer size fields one immediately after another. It would be make life a bit more easy.
We have access via a business partnership to C++ engineering who are busy on creating a SQLITE binding to a scripting engine.
Would there be from SV an interface or multiple interfaces to set up the control blocks at runtime?
Setting up a Bindable external in the engine looks like this…
The engine is a factory where the OPS run like a production line factory not a traditional execution cycle.
bindNativeObject(“SQLLITE”, new SQLObject(this), PRI_STARTBLOCK, VARATTR_IMMEDIATE | VARATTR_ISOP);
“All old products working with type descriptors would become outdated. Program would require use a new interface.”
A: would this interface be published from SV ?
I don’t know SV plans to implement it. The draft of the new type descriptor was described back in 2004. New types encoding was implemented in new UFO. It is now not just a byte with a type code.
Whether SV will implement and publish any interfaces, this is not a question for me.
something like this ?
iUFO INTERFACE,TYPE
AssignLong PROCEDURE !+00h
AssignReal PROCEDURE !+04h
AssignUFO PROCEDURE !+08h
DistinctsUFO PROCEDURE !+0Ch
DistinctsLong PROCEDURE !+10h
_Type PROCEDURE(LONG _UfoAddr),LONG !+14h
ToMem PROCEDURE !+18h
FromMem PROCEDURE !+1Ch
OldFromMem PROCEDURE !+20h
Pop PROCEDURE(LONG _UfoAddr) !+24h
Push PROCEDURE(LONG _UfoAddr) !+28h
DPop PROCEDURE(LONG _UfoAddr) !+2Ch
DPush PROCEDURE(LONG _UfoAddr) !+30h
_Real PROCEDURE(LONG _UfoAddr),REAL !+34h
_Long PROCEDURE(LONG _UfoAddr),LONG !+38h
_Free PROCEDURE(LONG _UfoAddr) !+3Ch
_Clear PROCEDURE !+40h
_Address PROCEDURE(LONG _UfoAddr),LONG !+44h
AClone PROCEDURE(LONG _UfoAddr),LONG !+48h
Select PROCEDURE !+4Ch _Var[Ptr]
Slice PROCEDURE !+50h ÷ _Var[Ptr1:Ptr2]
Designate PROCEDURE !+54h
_Max PROCEDURE(LONG _UfoAddr),LONG !+58h
_Size PROCEDURE(LONG _UfoAddr),LONG !+5Ch
BaseType PROCEDURE(LONG _UfoAddr),LONG !+60h
DistinctUpper PROCEDURE !+64h
Cleared PROCEDURE(LONG _UfoAddr) !+68h Óíè÷òîæåí?
IsNull PROCEDURE(LONG _UfoAddr),LONG !+6Ch
OEM2ANSI PROCEDURE(LONG _UfoAddr) !+70h
ANSI2OEM PROCEDURE(LONG _UfoAddr) !+74h
_Bind PROCEDURE(LONG _UfoAddr) !+78h
_Add PROCEDURE !+7Ch
Divide PROCEDURE !+80h
Hash PROCEDURE(LONG _UfoAddr),LONG !+84h Calc CRC
SetAddress PROCEDURE !+88h
Match PROCEDURE !+8Ch ClassDesc-ñòðóêòóðû
Identical PROCEDURE !+90h
Store PROCEDURE !+94h
END
is this the old ?
TValueUFOHeader GROUP,TYPE !Size = 0Dh(13)
VMTPtr LONG !+00h VMT address
DataInfo REAL !+04h
LongValue LONG,OVER(DataInfo) !+04h
RealValue REAL,OVER(DataInfo) !+04h
GROUP,OVER(DataInfo) !+04h
StrValue &STRING !+04h
END
StrRef GROUP,OVER(DataInfo) !+04h
Addr LONG !+04h
Size UNSIGNED !+08h
END
Type BYTE !+0Ch
END
! NEW ONE without the TYPE as above.
TUFOHeader GROUP,TYPE !Max = 15h(21)
VMTPtr LONG !+00h VMT address
DataPtr LONG !+04h
Flags BYTE !+08h
DataInfo GROUP !+09h
Size UNSIGNED !+09h
REAL !+0Dh
END !
Decimal GROUP,OVER(DataInfo) !+09h DECIMAL è PDECIMAL
Size BYTE !+09h
Float BYTE !+0Ah
END !
Array GROUP,OVER(DataInfo) !+09h
BaseUFO LONG !+09h UFO
Dim LONG !+0Dh
END !
GrpInfo GROUP,OVER(DataInfo) !+09h
Size UNSIGNED !+09h
ClassDesc LONG !+0Dh
RecUFOs LONG !+11h
END !
END
On the last clarionLive on clarion 12 some statement was made about UFO specs being published a request made by Bruce i think.
Once again. Some changes to RTL internal structures have been made for the future. While these changes are not released in some CW version, nothing of current is old. But I don’t know SV plans for the future.
Alexi can you clarify your statement please.
“nothing of current is old.”
The data structure i have listed above is what we are using to access UFO in clarion 11 and we are using the above interface to create the UFO’s
I think you mean to say that the data structures in the current RTL “MAY” be New and conform to the Interface approach.
For example : we are using .
UFO &= (UfoAddr)
UFO. methods()
to get the standard UFO interface in Clarion 11.
it looks like we are in fact using an INTERFACE.
many Thanks Stev New Zealand
While some RTL internal code/data is not changed in the next CW version, all old hacks to work with that code/data remain working - if you consider them as working.
I See all current data types should continue therefore to work but not work any new types such as unicode.
“all old hacks to work with that code/data remain working”
ok we will test when the new versions arrive.
And if SV release the interface specification as asked by Bruce we can check to see if this current INTERFACE is up to date.
The following Group seems to be the latest extended version.
TUFOHeader GROUP,TYPE !Max = 15h(21)
VMTPtr LONG !+00h VMT address
DataPtr LONG !+04h
Flags BYTE !+08h
DataInfo GROUP !+09h
Size UNSIGNED !+09h
REAL !+0Dh
END !
Decimal GROUP,OVER(DataInfo) !+09h DECIMAL è PDECIMAL
Size BYTE !+09h
Float BYTE !+0Ah
END !
Array GROUP,OVER(DataInfo) !+09h
BaseUFO LONG !+09h UFO
Dim LONG !+0Dh
END !
GrpInfo GROUP,OVER(DataInfo) !+09h
Size UNSIGNED !+09h
ClassDesc LONG !+0Dh
RecUFOs LONG !+11h
END !
END
Many thanks Alexi