Can anyone explain the following behaviour to me?
When a field type in an AX Table is set to an Enum, you can select any of the Enum values as a value for the field.
But if you make the field Mandatory, you can no longer select the first Enum value in the list through the user interface.
Obviously this can be worked around by not making the field Mandatory. I am looking for an explanation of this bizarre behaviour.
AX does not have a null value concept. Instead the following values are considered "not entered" by defintion:
string: blank
int and int64: 0 (zero)
enum: 0 (typically the first value)
date: 01\01\1900 (displays as blank)
For new base enums make a blank zero enum value (by convention name it None). This will make the use of mandatory fields possible for this enum type.
Also have a look on this: Mark mandatory fields on form, if not filled with valid value
You're saying "if you make the field Mandatory, you can no longer select the first Enum value in the list through the user interface" - this is exactly what the Mandatory property does for enums: prevents you from using a zero value. E.g. if you make NoYesId mandatory you'll be able to enter only Yes because No would no longer be allowed - why would you need it on the form then?
Please also note that from a user perspective it isn't necessarily clear what enum value is zero, so if it didn't work the way it works, understanding what value is not allowed when the enum is mandatory could be tricky.
Related
g.V(123).property('myProperty', myproperty? myProperty: null)
Here myProperty is of integer type and I wish to save an empty value for 'myProperty'.
I know null is not supported. Is there another alternative to achieve the same? (I can't save the value as 0 either)
As there is no notion of null in TinkerPop (for now) I'm afraid that you either have to remove the property or define some sort of constant to represent it. You say that you can't use "zero" but perhaps you could use something like Integer.MIN_VALUE or something? Or, if you are using a graph that doesn't have an explicit schema you could set it to a non-integer value like a "null" string? I can't reall think of any other workarounds.
Im pretty new to prolog, and got stuck.
I need to store a variable with some string during calculations, I decided to do this by adding a "single fact" to the class I'm working with. Everything works well, the string is being stored, but when I try to add the code to access it later on, compiler returns an error "The expression has type 'dataBL::dataBL#objectDB', which is incompatible with the type '::symbol'".
I dont think it is the valid way to store a variable, so, can anyone help me with that? I tried searching online for the answers, and found nothing.
I'm trying to access the fact like this:
getString(U) :-
U = stringStorage(_).
If I get you right you need to store a value associated with some variable ID (key) as a fact. The (abstract) solution for your task canas the storing your values as a facts:
bind( Key, Value ).
Example of implementation (SWI Prolog)
Storing
recordz('var1', "String value1"),
recordz('var2', "String value2")
Querying value of var2
current_key(-Key),
Key = 'var2'
recorded(Key, Value)
Am trying to read the lotus notes document using VB6.I can able to read the values of the but suddenly type mismatch error is throwed.When i reintialise the vb6 variable it works but stops after certain point.
ex; address field in lotus notes
lsaddress=ImsField(doc.address)
private function ImsField(pValue)
ImsField=pValue(0)
end function
Like this I am reading the remaining fields but at certain point the runtime error "13" type mismatch error throwed.
I have to manually reintialize by
set doc=view.getdocumentbykey(doclist)
The type mismatch error occurs for a certain field. The issue should be a data type incompatibility. Try to figure out which field causes the error.
Use GetItemValue() instead of short notation for accessing fields and don't use ImsField():
lsaddress=doc.GetItemValue("address")(0)
The type mismatch is occurring because you are encountering a case where pValue is not an array. That will occur when you attempt to reference a NotesItem that does not exist. I.e., doc.MissingItem.
You should not use the shorthand notation doc.itemName. It is convenient, but it leads to sloppy coding. You should use getItemValue as everyone else is suggesting, and also you should check to see if the NotesItem exists. I.e.,
if doc.hasItem("myItem") then
lsaddress=doc.getItemValue("myItem")(0)
end if
Notes and Domino are schema-less. There are no data integrity checks other than what you write yourself. You may think that the item always has to be there, but the truth is that there is nothing that will ever guarantee that, so it is always up to you to write your code so that it doesn't assume anything.
BTW: There are other checks that you might want to perform besides just whether or not the field exists. You might want to check the field's type as well, but to do that requires going one more level up the object chain and using getFirstItem instead of getItemValue, which I'm not going to get into here. And the reason, once again, is that Notes and Domino are schema-less. You might think that a given item must always be a text list, but all it takes is someone writing sloppy code in an one-time fix-it agent and you could end up having a document in which that item is numeric!
Checking your fields is actually a good reason (sometimes) to encapsulate your field access in a function, much like the way you have attempted to do. The reason I added "sometimes" above is that your code's behavior for a missing field isn't necessarily always going to be the same, but for cases where you just want to return a default value when the field doesn't exist you can use something like this:
lsaddress ImsField("address","")
private function ImsField(fieldName,defaultValue)
if doc.hasItem(fieldName) then
lsaddress=doc.getItemValue(fieldName)(0)
else
lsaddress=defaultValue
end if
end function
Type mismatch comes,
When you try to set values from one kind of datatype variable to different datatype of another variable.
Eg:-
dim x as String
Dim z as variant
z= Split("Test:XXX",":")
x=z
The above will through the error what you mentioned.
So check the below code...
lsaddress = ImsField(doc.address)
What is the datatype of lsaddress?
What is the return type of ImsField(doc.address)?
If the above function parameter is a string, then you should pass the parameter like (doc.address(0))
I'm trying to determine the relationship between default values and the has_foo() methods that are declared in various programmatic interfaces. In particular, I'm trying to determine under what circumstances (if any) you can "tell the difference" between a field explicitly set to the default value, and an unset value.
If I explicitly set a field (e.g. "Bar.foo") to its default value (e.g., zero), then is Bar::has_foo() guaranteed return true for that data structure? (This appears to be true for the C++ generated code, from a quick inspection, but that doesn't mean it's guaranteed.) If this is true, then it's possible to distinguish between an explicitly set default value and an unset prior to serialization.
If I explicitly set a field to its default value (e.g., zero), and then serialize that object and send it over the wire, will the value be sent or not? If it is not, then clearly any code that receives this object can't distinguish between an explicitly set default value and an unset value. I.e., it won't be possible to distinguish these two cases after serialization -- Bar::has_foo() will return false in both cases.
If it's not possible to tell the difference, what is the recommended technique for encoding a protobuf field if I want to encode a "nullable" optional value? A couple options come to mind, but neither seem great: (a) add an extra boolean field that records whether the field is set or not, or (b) use a "repeated" field even though I semantically want an optional field -- this way I can tell the difference between no value (length-zero list) or a set value (length-one list).
The following applies for 'proto2' syntax, not 'proto3' :
The notion of a field being set or not is a core feature of Protobuf. If you set a field to a value (any value), then the corresponding has_xxx method must return true, otherwise you have a bug in the API.
If you do not set a field and then serialize the message, no value is sent for that field. The receiving side will parse the message, discover which values where included, and set the corresponding "has_xxx" values.
Exactly how this is implemented in the wire-format is documented here: http://code.google.com/apis/protocolbuffers/docs/encoding.html. The short version is that message are encoded as a sequence of key-value pairs, and only fields which are explicitly set are included in the encoded message.
Default values only come into play when you attempt to read an unset field.
My English may not be very good, so please excuse me if I don't make sense.
I am tasked with verifying an Enum contains a incrementing value.
The code looks like this:
Public Enum AccountMessageDescriptor
AccountInvalid = 1001
AccountReviewPending=1002
...
InvalidOperationOnAccount=1382
End Enum
Each Enum value has a description (Custom) attribute also. The file and description attribute is used elsewhere... It looks like the programmers update the enums and use the custom attribute for help messages instead of resource files etc with a new integer value...
For example, another error may be added as:
NewEnumItem=1383
I need to make sure (during build time we have a custom MSBuild task that does lots of other processing) if the enum is incrementing sequentially and that its not already in use.
Someone suggested using a collection, check if the enum value already exists and if not insert it.
I was thinking of just iterating through and checking if the current value is +1 the previous value (so its sequential and it can't be already in use because it has to always be +1). Does this seem flawed or am I not understanding something about .NET enums?
Emmi
If you set the first value and then exclude all following values they will be incremental. eg...
Public Enum testenum
first = 1001
second
third
End Enum
So second will be 1002 third will be 1003 etc etc...
If for some reason you do need to skip certain values then you can force the increment to start at a higher value eg..
Public Enum testenum
first = 1001
second
third
fourth = 2000
fifth
End Enum
So in this example fourth will be 2000 and fifth will be 2001
To iterate through an enum, you could try the following:
For Each amd As AccountMessageDescriptor In [Enum].GetValues(GetType(AccountMessageDescriptor))
'Do your thing here
Next
I'm not enterily sure if this way the values are sequential, but a quick test could sort this out for you.
Or you can store all the values in an array and check if the values are sequential:
Dim allAMD As AccountMessageDescriptor() = DirectCast([Enum].GetValues(GetType(AccountMessageDescriptor)), AccountMessageDescriptor())
'Loop through array and check with previous