I am trying to learn about the ScriptProperties object in GAS.
I tried setting a property to a value of null, and I get an error.
I can understand if like JavaScript, setting a value of null undefines
that property.
But why are you disallowing this value?
It seems reasonable (to me) to allow a script to undefine a script (or user) property.
Another question about ScriptProperties (and I assume the same holds for UserProperties),
Why when I display the value of an undefined property it displays as "undefined",
but when I try to test for the value "undefined" (without quotes) it does not match?
It seems, that if you are going to introduce a new special attribute value of "undefined", it should be consistent through out the system. If by "undefined" you mean null, well then
why not display it with the word "null"?
I am just trying to learn about this new environment.
All help is appreciated. Thanks for your support.
There is an open feature request to add support for removing properties, which you can star for updates.
The value "undefined" is not a string but rather a special value built in to JavaScript. You can refer to it like "null":
if (foo == undefined) { ...
More information is available on the w3schools page.
Related
Chrome debug console snapshot
I basically am unsure as to what is causing this error ^^.
I've done a little digginng, and it seemse the previousProperties is passed in as previous.properties by updateDom(). previous, in turn, is passed in by update where it is labeled as just vnode. This VNOde is a valid VNode, but just lacks the properties.
I'm pretty sure I've made everything distinguishable (by setting unique key properties) that would need to be distinguishable, so I don't think that's the problem, although I could be mistaken.
So I had this question, wrote it, did more looking and found my answer before even posting it. I'm still posting this question, and answering it myself in hopes that it might help save someone else some heartache in the future.
In this case, this error is being caused by a projector rendering and receiving an invalid value in return from the renderMaquette function. In my component based framework, I've been using ternary operators to work like if-else statements inside renderMaquetteFunction return blocks. I.E.
function renderMaquette(){
return h('div',
showTitle ?
h('h1', 'My Title')
: []
)
}
Leaving an empty array is perfectly acceptable parameter inside of a hyperscript function, as it will return nothing. However, returning an empty array is not. I.E.
function renderMaquette(){
return showTitle ?
h('h1', 'My Title')
: []
}
This generates an error.
I'm evaluating HTML5 Web Audio API example and trying to get it work. Here is what I'm working with. As far as I got I understood that it's using old API and I need to refactor function refreshFilterType() on line ~590. Link - www.smartjava.org/examples/webaudio-filters/
According to Web Audio BiquadFilterNode I need to rework switch statement and make it
and to use the new string-based values. (I.e. a value of "3" - the default lowshelf filter - needs to be passed into currentFilterType as "lowshelf"). I've tried to implement new BiquadFilterNode, but still it was unsuccessfully.
Thank you in advance.
I just opened a pull request with the necessary fixes. Or look at https://github.com/cwilso/smartjava.
...and actually, I note the real problem with the code you have is not that it's using numeric values - that's wrong, according to the spec, but it's still supported - it's line 663:
filter.type = currentFilterType;
currentFilterType is "3" - that is, the STRING "3" - and type now takes a string, so it's not being coerced. If you changed this line to
filter.type = parseInt(currentFilterType);
it would actually fix the problem (because filter.type accepts ints, and will coerce them to the appropriate string of "lowpass", etc. - but it doesn't accept the string of a number.)
However, this will fail in the long term, when we remove the deprecated types.
I have three dropdown boxes on a Main_Form. I will add the chosen content into three fields on the form, Form_Applications.
These three lines are added :
Form_Applications.Classification = Form_Main_Form.Combo43.Value
Form_Applications.Countryname_Cluster = Form_Main_Form.Combo56.Value
Form_Applications.Application = Form_Main_Form.Combo64.Value
The first two work perfectly but the last one gives error code 438!
I can enter in the immediate window :
Form_Applications.Classification = "what ever"
Form_Applications.Countryname_Cluster = "what ever"
but not for the third line. Then, after enter, the Object doesn't support this property or method error appears.
I didn't expect this error as I do exactly the same as in the first two lines.
Can you please help or do you need more info ?
In VBA Application is a special word and should not be used to address fields.
FormName.Application will return an object that points to the application instance that is running that form as opposed to an object within that form.
From the Application object you can do all sorts of other things such as executing external programs and other application level stuff like saving files/
Rename your Application field to something else, perhaps ApplicationCombo and change your line of code to match the new name. After doing this the code should execute as you expect.
Form_Applications.Application is referring to the application itself. It is not a field, so therefore it is not assignable (at least with a string).
You really haven't provided enough code to draw any real conclusions though. But looking at what you have posted, you definitely need to rethink your approach.
It's to say definitely but you are not doing the same. It looks like you are reading a ComboBox value the same (I will assume Combo64 is the same as 43 and 56) but my guess is that what you are assigning that value to is the problem:
Form_Applications.Application =
Application is not assignable. Is there another field you meant to use there?
I have a data structure returned by a web service. It's a few levels deep, and could have null instead of the expected object. Which results in some ugly code to check.
<td>{{if FulfilledBy}}${FulfilledBy.Name}{{/if}}</td>
I can't change the output of the service, but I'd rather not need to check if FulfilledBy exists prior to access the .Name property.
Is there a better way to write this? I would have preferred something like
<td>${(FulfilledBy || {}).Name}</td>
but it doesn't work either.
According to docs, you can use expressions within ${}. Have you tried ${FulfilledBy? FulfilledBy.Name: 'no name'}?
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation ?
Note: I am not talking about comments within the code
By "value limits", I mean:
does a parameter can support a null value (or an empty String, or...) ?
does a 'return value' can be null or is guaranteed to never be null (or can be "empty", or...) ?
Sample:
What I often see (without having access to source code) is:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* #return array of reader names
*/
String[] getReaderNames(final String aReaderNameRegexp);
What I like to see would be:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* (can be null or empty)
* #return array of reader names
* (null if Report has not yet been published,
* empty array if no reader match criteria,
* reader names array matching regexp, or all readers if regexp is null or empty)
*/
String[] getReaderNames(final String aReaderNameRegexp);
My point is:
When I use a library with a getReaderNames() function in it, I often do not even need to read the API documentation to guess what it does. But I need to be sure how to use it.
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
Edit:
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
I think they can belong together but don't necessarily have to belong together. In your scenario, it seems like it makes sense that the limits are documented in such a way that they appear in the generated API documentation and intellisense (if the language/IDE support it).
I think it does depend on the language as well. For example, Ada has a native data type that is a "restricted integer", where you define an integer variable and explicitly indicate that it will only (and always) be within a certain numeric range. In that case, the datatype itself indicates the restriction. It should still be visible and discoverable through the API documentation and intellisense, but wouldn't be something that a developer has to specify in the comments.
However, languages like Java and C# don't have this type of restricted integer, so the developer would have to specify it in the comments if it were information that should become part of the public documentation.
I think those kinds of boundary conditions most definitely belong in the API. However, I would (and often do) go a step further and indicate WHAT those null values mean. Either I indicate it will throw an exception, or I explain what the expected results are when the boundary value is passed in.
It's hard to remember to always do this, but it's a good thing for users of your class. It's also difficult to maintain it if the contract the method presents changes (like null values are changed to no be allowed)... you have to be diligent also to update the docs when you change the semantics of the method.
Question 1
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation?
Almost never.
Question 2
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
If I used a function not properly I would expect a RuntimeException thrown by the method or a RuntimeException in another (sometimes very far) part of the program.
Comments like #param aReaderNameRegexp filter in order to ... (can be null or empty) seems to me a way to implement Design by Contract in a human-being language inside Javadoc.
Using Javadoc to enforce Design by Contract was used by iContract, now resurrected into JcontractS, that let you specify invariants, preconditions, postconditions, in more formalized way compared to the human-being language.
Question 3
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
Java language doesn't have a Design by Contract feature, so you might be tempted to use Execption but I agree with you about the fact that you have to be aware about When to choose checked and unchecked exceptions. Probably you might use unchecked IllegalArgumentException, IllegalStateException, or you might use unit testing, but the major problem is how to communicate to other programmers that such code is about Design By Contract and should be considered as a contract before changing it too lightly.
I think they do, and have always placed comments in the header files (c++) arcordingly.
In addition to valid input/output/return comments, I also note which exceptions are likly to be thrown by the function (since I often want to use the return value for...well returning a value, I prefer exceptions over error codes)
//File:
// Should be a path to the teexture file to load, if it is not a full path (eg "c:\example.png") it will attempt to find the file usign the paths provided by the DataSearchPath list
//Return: The pointer to a Texture instance is returned, in the event of an error, an exception is thrown. When you are finished with the texture you chould call the Free() method.
//Exceptions:
//except::FileNotFound
//except::InvalidFile
//except::InvalidParams
//except::CreationFailed
Texture *GetTexture(const std::string &File);
#Fire Lancer: Right! I forgot about exception, but I would like to see them mentioned, especially the unchecked 'runtime' exception that this public method could throw
#Mike Stone:
you have to be diligent also to update the docs when you change the semantics of the method.
Mmmm I sure hope that the public API documentation is at the very least updated whenever a change -- that affects the contract of the function -- takes place. If not, those API documentations could be drop altogether.
To add food to yours thoughts (and go with #Scott Dorman), I just stumble upon the future of java7 annotations
What does that means ? That certain 'boundary conditions', rather than being in the documentation, should be better off in the API itself, and automatically used, at compilation time, with appropriate 'assert' generated code.
That way, if a '#CheckForNull' is in the API, the writer of the function might get away with not even documenting it! And if the semantic change, its API will reflect that change (like 'no more #CheckForNull' for instance)
That kind of approach suggests that documentation, for 'boundary conditions', is an extra bonus rather than a mandatory practice.
However, that does not cover the special values of the return object of a function. For that, a complete documentation is still needed.