|
I have some problem with the iconic map at the creation of entities of
my AM.
The iconic map displays a window for creation including attributes to be
filled,where are displayed the default values of the MSL definition.
But when a user wants to keep thoses values as they are displayed, he
only validates the creation by clicking OK,and an error raised :
ILV mode inconsistent with arguments .
here is the p_dsc_in_p structure coming from the iconic_map :
[ 0 ] (
[ 3 ] (
[ 5 ]
)
[ 5 ] (
[ 5 ]
)
)
When filling with attribute values directly, the p_dsc_in_p include :
[ 0 ] (
[ 3 ] 00
[ 5 ] 00
)
How can I suppress this error, this is not user friendly ?
>
>This is a development-time programming error--it needs to be fixed
>by you, or by me (if its an ILV problem), or the IMPM, whichever is in
>error, not supressed!
>
>Both of the above encodings are NATIVE mode. For CREATE, they should be.
>
>I think that the first encoding is a an ilv-dump display of the special ILV
>case for Implementation Default. (A 0 length value)
>
>I think that either:
>the AM code is not looking for the implementation default CVR & flag on decode,
>or the AM MSL is improperly specifying defaults.
>
>I'm sure the IMPM people will correct me if I'm wrong here. I think what is
>happening is that the IMPM is picking default values for display from the
>dictionary. When those are selected, it is encoding "implementation default"
>in the request argument. In this case, the AM (the implementation) is expected
>to know the default values--after all, it supplied them to the dictionary.
>
>The second dump is an encoded integer- zero (0).
>
>ILV mode for encode and decode should be NATIVE unless you are encoding
>or decoding an attrib_list. Attrib_lists are required as the datatype
>of a the request argument on SET, ADD, REMOVE, and the response argument
>of SHOW, SET, ADD, REMOVE. See Chapter 15.4 of the SRM for details, and
>cross-check the details with the Toolkit release notes and MM programming
>manual(s).
>
>I hope this gives you some way to fix the problem or to determine where
>a fix is needed.
>
>Ruth
|
|
I will give you more details about how I process the ILV received from
the request :
first reading with a get_param_begin
look for an id with ilv_find_id
step again with ilv_get ....and the status coming back from this
one is "ilv mode inconsistent with argument",
How could I know that at this level of the ILV I have a descriptor
which fields are not in the normal form but "implementation default" ?!
From where is coming this ID of 5 ? How could I control that ?
My default values are right in the SRM, the null values of the
second ILV, I gave above, are enumerated values.
I can manage on what PM I am currently running to control the incoming
request values .
Some ideas ?
cheers, Pascale.
|
| The Iconic Map never sends down the default values that are defined
in the dictionary. They are simply displayed. When the user chooses
the default values, the Iconic Map ILV encodes a "implementation
specific" flag instead of the default values.
How to encode and decode an implementation specific default is
described in the section on MCC_ILV_PUT and MCC_ILV_GET respectively.
From the AM/FM's view, you should be getting a CVR of
MCC_S_ILVIMPLDEFAULT when you do a mcc_ilv_get. Make sure you are
using Native mode, since your ilv dumps indicate you are dealing with
arguments.
The ID of 5 is simply how the Implementation Specific flag encoding
looks.
Christine
|
|
I will give you more details about how I process the ILV received from
the request :
first reading with a get_param_begin
>
>This intialized the read context, with Native Mode
>
look for an id with ilv_find_id
>
>I presume the status is MCC_S_NORMAL, not MCC_S_ILVTNF or MCC_S_ILVNOTINCONS.
>
step again with ilv_get ....and the status coming back from this
one is "ilv mode inconsistent with argument",
How could I know that at this level of the ILV I have a descriptor
which fields are not in the normal form but "implementation default" ?!
>
>If you have not done any mcc_ilv_get_cons_begin to open a construction
>in LIST mode, you are still in Native mode.
>At this point you should get the MCC_S_ILVIMPLDEFAULT CVR, combined with
>the mcc_b_flags field of the returned value descriptor set to
> MCC_M_FLAGS_DEFAULT. mcc_w_curlen is 0, for all types except those
>which resolve to integer, and the length of the base type for integer types.
>
From where is coming this ID of 5 ? How could I control that ?
> the 5 is NOT an ID in this case. You have no control--you have to
>be able to recogize the special Implementation Default case.
>
>As Christine said, the string "(
[5]
)" in this specific case is how
> mcc_ilv_dump is interpreting the underlying encoding, which is
> an ASN.1 tag of datatype ASN NULL, 0 length and no value, plus some
> more bits of ASN.1 protocol. To ILV, it means Implementation Default (no
> value supplied--the recipient is expected to know what is meant.) The
> ilv_dump is at too low a level to properly intrepret this as a NULL and
> print nothing.
My default values are right in the SRM, the null values of the
second ILV, I gave above, are enumerated values.
>
>Enumerated values at the moment are ultimately encoded as ASN.1 integers, so
>the curlen mentioned above would not be 0, most likely it would be 4.
>
I can manage on what PM I am currently running to control the incoming
request values .
Some ideas ?
>
> Not really...could you get me some more information?
>
> 1) If the status of the mcc_ilv_fnd_id is normal, could you tell me the
> exact DECmcc kit you are working with, and the dates on the
> sys$message:mccmsg.exe file and the
> sys$share:mcc_kernel_shr.exe file ?
> (just in case, how about the sys$message:mcctbdmsg.exe date, too)
> For whatever reason, there may possibly be a mismatch between
> the messages and the kernel.
>
> 2) Make sure that there isn't a bunch of old mcc files in a sys$specific
> directory somewhere getting used instead of the ones you thought
> you were using.
>
> 3) Could you replace the find with a get_id? (If THAT works, with no
> other changes, I REALLY want to hear about it!)
>
> Anyone else have any ideas?
>
> Ruth
|