Page 1 of 1
Feature is not a member of PRIM_LIBI.IVarCharIntrinsics
Posted: Tue Dec 20, 2016 3:55 am
by jyoung
I've defined a data object as such
Code: Select all
begin_com role(*EXTENDS #PRIM_OBJT *LISTFIELDS #ListFields) defaultpty(Caption)
group_by name(#ListFields) fields(#OFOFID #OFOFIN #OFELVL #OFOTY #OFDFC)
define_pty name(Id) get(*AUTO #OFOFID) set(*AUTO #OFOFID)
define_pty name(Caption) get(*AUTO #OFOFIN) set(*AUTO #OFOFIN)
end_com
I have that object defined in my "Application" object
Code: Select all
define_pty name(CurrentOffice) get(*AUTO #CurrentOffice)
define_com class(#MOBOFCData) name(#CurrentOffice)
mthroutine name(SetCurrentOffice)
define_map for(*INPUT) class(#OFOFID) name(#officeId)
define_map for(*INPUT) class(#OFOFIN) name(#officeName)
#CurrentOffice.Id := #officeId
#CurrentOffice.Caption := #officeName
endroutine
In the application object I can set the id and caption just fine.
However every time I "get" the id or caption from the the object, I get the "Feature is not a member of PRIM_LIBI.IVarCharIntrinsics" error.
Code: Select all
#COM_OWNER.LoadDetails( #Application.CurrentOffice.Id )
How do I get the values out of the object?
Re: Feature is not a member of PRIM_LIBI.IVarCharIntrinsics
Posted: Tue Dec 20, 2016 4:44 am
by jyoung
Apparently I was defining the property wrong in my application object.
Instead of using *AUTO, I should have been using *REFERENCE.
Code: Select all
define_pty name(CurrentOffice) get(*REFERENCE #CurrentOffice)
Re: Feature is not a member of PRIM_LIBI.IVarCharIntrinsics
Posted: Tue Dec 20, 2016 8:07 am
by dannyoorburg
I guess it got confusing because your data object has a default property of Caption defined. Because of the default property it can now do value AND reference semantics, i.e. both *AUTO and *REFERENCE are valid (although very different in meaning).
I'm personally a bit wary of default properties because of this, it's often quite easy to confuse reference and value assignments and the compiler won't help you as they're both valid.
Having said that, a default property makes perfect sense for an object that clearly represents a value, like a credit-card number.
Thanks for sharing
Danny
Re: Feature is not a member of PRIM_LIBI.IVarCharIntrinsics
Posted: Tue Dec 20, 2016 8:15 am
by jyoung
I did not realize that default properties can be BOTH *AUTO and *REFERENCE, but you are absolutely right.
Before I changed the property to be *REFERENCE it worked when I used the default property, but not with any other properties.
It took some more investigation in the docs to realize the error.
I would rather use a "Name" property, but cannot do that because of the ancestor so I stuck with Caption as it seems that is the "label" for everything else.
I am not a big fan of the default property myself. I get that it saves some typing, but I find it confusing and I have always pushed that clarity is greater then brevity.
Re: Feature is not a member of PRIM_LIBI.IVarCharIntrinsics
Posted: Wed Dec 21, 2016 4:20 pm
by Stewart Marshall
I'm with you here Joe. I'm not a fan of default properties for the most part.
Default properties work very well when the default is something BLINDINGLY OBVIOUS, but for data objects I find they tend to hide the meaning.
We use them for some controls e.g. Label and Spin Edit, because 99% of property setting for a label is the Caption and for a Spin Edit the Value. These make semantic sense
Code: Select all
#Label := "Some text"
#Spinedit := 99
is just as clear in meaning as
Code: Select all
#Label.caption := "Some text"
#Spinedit.value := 99
References for default properties though should be avoided. We tried giving the Image control a default property of Image so that the RDMLX read well but very quickly discovered that the syntax is ambiguous when using *Null because it applies equally to the object itself and its property. Most confusing.
As you say, clarity does indeed trump brevity.