Excel UDF returns a huge number - user-defined-functions

Excel AddIn using Excel DNA, VS2008, C#,
MyUDF(param1, parm2)
when I type in "=MyUDF" and hit enter, Excel displays a huge number like 970063926
and my c# code for MyUDF is not run
Anyone know what is this huge number?
thanks

This is just a bit of weird behaviour of Excel. The number being returned is an internal identifier for the UDF function, and by entering the function name without any brackets, you're causing it to be treated like a named range not a function. If you want to call the function with no arguments, use:
=MyUDF()
...if you type =MyUDF then you're asking Excel to dereference the function name, in the same way that it would dereference =A1 to the value in cell A1 or =MyNamedRange to whatever that named range referred to.
I don't think there's any practical use for the behaviour you've observed, but it certainly isn't going anywhere near your code to get this value that is being returned, so don't worry you haven't done anything wrong!

Is there any way to avoid this behavior?
If no parameter is specified, I would like the =MyUDF to return error instead a number.

Related

DialogFlow CX inline system functions not working in text fulfillment

I would like to generate dynamic text without the need to create webhooks whenever possible. I understand that the only way to create dynamic text is by either creating different routes depending on parameters or by using inline system functions like $sys.func.ADD(1, 2) within text fulfillments.
But inline system functions like $sys.func.ADD(1, 2) do not work for me if used in text fulfillments. System functions just don't get executed for me. I.e. instead of uttering "3" my bot just utters "$sys.func.ADD(1, 2)" as a result of a test fulfillemnt. What am I doing wrong here? Does anybody have an example for using inline system functions in text fulfillment?
Thanks!
To resolve this issue, you need to check the result of system functions in order to identify the error that occurred.
For the system function $sys.func.ADD, when using it as a text response in your fulfillment, you need to convert it to type STRING to be embedded in text since the output of this system function returns a type DOUBLE.
You can convert the output of the $sys.func.ADD function to STRING by creating a nested function in your text response and utilizing the $sys.func.TO_TEXT which converts a value of other types to string.
Here’s an example for reference:

SQL Server Reporting Studio (SSRS) sorting error

I am attempting to allow a dynamic sort on a text box on an SSRS report. The field upon which I am trying to sort will either have an "A" or a decimal number. I am wanting to sort the decimal numbers in descending order. The expression I am using is:
=iif(isnumeric(Fields!CommScore.Value), (cdbl(Fields!CommScore.Value)*-1),6)
For the decimal number will never be larger than 5. The error I get is:
The sortexpression for the text box 'textbox74' contains an error. Input string was not in a correct format. (rsRuntimeErrorInExpression)
I imagine this is something simple. What am I doing wrong?
The error relates to the CDbl function throwing an exception when trying to convert A to a number. Yes, I know you're checking if it is numeric first but IIF is not a language construct, it is a function and as a function it evaluates all its parameters before passing them to the function. This means that both the true and false parameters get calculated even though one will be discarded.
Try the Val function. It has the benefit of not erroring when it gets passed non-numeric data - it just does the best it can to convert it.
=IIF(IsNumeric(Fields!CommScore.Value), (Val(Fields!CommScore.Value)*-1), 6)

The "getnodevalue" of HTMLUNIT not working on domattr

every time i want to get the Value of my DomAttr i get an TypeError:
My Code:
Wanted = page.getByXPath("//span[contains(.,'Some')]/parent::a/#href");
return this
[DomAttr[name=href value=URLSTRING]]
Now i want to geht the value (=URLSTRING) with Wanted.getNodeName();
but every Time i get the Error
Cannot find function getNodeValue in object [DomAttr[name=href value=
same when i use getValue
please help me
There are some things that make no sense in the code (particularly, because it is not complete). However, I think I can guess what the issue is.
getByXPath is actually returning a List (funny thing you missed the part of the code in which you specify it as a list and replaced it with a Wanted).
Note you should probably also have type warnings in the code too.
Now, you can see that the returned value is in square brackets. That means it is a List (confirming first assumption).
Finally, although you happened to miss that part of the code too, I guess you are directly applying the getValue to the list instead of the DomAttr elements in the list.
How to solve it: If you need more than 1 result iterate over the elements of the list (that Wanted word over there). If you need 1 result then user the getFirstByXPath method.
Were my guesses right?

Type mismatch error while reading lotus notes document in vb6

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))

Cannot access animate-properties in Clutter

I am trying to animate an actor in Clutter, but when I enter a property that exists, something goes wrong.
actor.animate( AnimationMode.LINEAR, 400, scale_x:2);
gives me this error
Clutter-WARNING **: Cannot bind property '\x83\xec\u0014\x89\xc6e\xa1\u000c': objects of type 'ClutterTexture' do not have this property
Looks like Unicode-characters to me.
However, when I enter a property that does NOT exist
actor.animate( AnimationMode.LINEAR, 400, thisdoesntwork:2);
I get an error that makes much more sense
Clutter-WARNING **: Cannot bind property 'thisdoesntwork': objects of type 'ClutterTexture' do not have this property
I get the exact same problem when I try this alternative approach:
actor.animate( AnimationMode.LINEAR, 400, "scale-x", 2);
How come all properties that actually exist get converted to some mess, and what can I do to get this to work?
You should be using 2.0 for the value, not 2. 2 is an integer, 2.0 is a double. Vala can't provide type safety for variadic methods, so you have to be careful.
As for why you're seeing the behavior you are for properties which exist, my guess is it has to do with the fact that 2 is a (32-bit) integer and 2.0 is a (64-bit) double. This is simplifying things a bit, and I don't know how much experience you have with C (probably not a lot, since this is the sort of mistake someone coming from a dynamically typed language would make), however... Clutter (well, va_arg) expects a double so it parses 64 bits of data, but you only provided 32 bits, so the first 32-bits of the next argument (NULL) are included. Now, when it starts trying to parse the next argument it starts from the wrong location (32-bits into the argument), so you get the the remainder of NULL and part of whatever garbage happened to be on the stack... Unsuprisingly, that doesn't just so happen to be 32-bits of 0s so when Clutter tests to see if the value it just read == NULL it isn't and Clutter thinks it's been given a pointer to an null-terminated array of characters (which is how strings are represented in C). It reads the data at that location, which just so happens to be \x83\xec\u0014\x89\xc6e\xa1\u000c, and checks to see if there is a property with that name. There isn't, so it emits the error message you saw.
Now, if you switch to using a property which doesn't exist, Clutter will parse the argument (the name of the property), notice that it doesn't exist (just like it did with the second property above), and emit an error.

Resources