I was looking for a method through MSDN (more precisely in here: http://msdn.microsoft.com/en-us/library/vstudio/bb983759.aspx) which would indicate if a Subitem's value in a PropertyGrid was changed or not, but I couldn't find anything. Does this method actually exists or I should implement it by myself?
You can use CMFCPropertyGridProperty::IsValueChangedIsModified():
Indicates whether the value of the current property has changed
Related
since in proto3 all parameters are optional when parameter is not set and message is deserialized then unset parameter holds default value. I can not find a way to check if the parameter has been set or not. Is there any way to find if parameter has been set similary as in proto2? I see that there is a method has_<param_name>() but it is private.
I don't think the distinction exists anymore in proto3. You are encouraged to have meaningful defaults.
But if you must, you can use a singular embedded message containing the value.
It seems after Protobuf 3.15.0 you could use hasField in C++ again:
According to the CHANGELOG:
Now Proto3 Oneof fields have "has" methods for checking their presence in
C++.
Building upon ramsay's answers, one thing that you can do if you have a real need for Null kind of value, is this:
import "google/protobuf/struct.proto";
message Test {
oneof value_or_null {
string value = 1;
google.protobuf.NullValue null = 2;
};
}
with the one of you will get the has_<param_name>() function back and you will be able to check if you have null or a value. Also this is a safer approach because you cannot set the two fields, the oneof implementation will make sure that potential previous field value get cleared and set the new one.
Do note however, that evolving oneof fields is trickier than evolving normal fields (you can see the potential problems here)
My recommendations
I would first make sure that there is a real need for Null and thus a real need for oneof.
I would try to make the default value of each field an invalid value in my business logic (eg: uint32 id with 0 value is invalid and I return an error)
I've been wondering for a while: how do autocompletions work?
Example:
In PhpStorm whenever I use a class and type -> it shows me all properties and methods of that class. It also auto completes namespaces and even functions inside libraries such as jQuery.
Does it run some sort of regex on the files, or does it parse them somehow?
PhpStorm developer here. I'd like to go through some basics in case it may be helpful for those who want to implement their own plugin.
First of all, a code has to be broken into tokens using a lexer. Then AST (an abstract syntax tree) and PSI (a program structure interface) are built using a parser. PhpStorm has its own implementations of the lexer and the parser. This is how a PSI tree looks like for a simple class.
When you type in an editor or explicitly invoke a completion action (Ctrl+Space) a number of completion contributors are invoked. They're intended to return a list of suggestions based on a cursor's position.
Let's consider a case when completion is invoked inside a field reference.
PhpStorm knows that at the current position all class members can be suggested. It starts obtaining a class reference (the $class variable in our case) and determining its type. If a variable resolves to a class its type is a class' FQN (fully qualified name).
To obtain methods and fields of a class its PSI element is needed. A special index is used to map an FQN to an appropriate PhpClass tree element. Indices are initially built when a project is opened for the first time and updated for each modified file.
PhpStorm collects all members from the PSI element (including parent's ones), then from its traits. They're filtered depending on a current context (e.g. access scope) and an already typed name's part (f).
Suggestions are shown in a list which is sorted by how good element's name matches, its type, position and so on. The list rearranges when you type.
When you press Enter to insert an element PhpStorm invokes one more handler. It knows how to properly insert the element into a code. For instance, it can add parentheses for a method or import a class reference. In our case, it's enough to put brackets and place a cursor just after them because the method has no parameters.
That's basically it. It worth mention that the IntelliJ IDEA platform allows a plugin to provide an implementation for each step described above. Thus completion can be improved or extended for some particular framework or language.
I am trying to use synthesised accessors on a component on Lucee (although this issue seems to be the same on ColdFusion too).
Repro code:
// Person.cfc
component accessors=true {
property firstName;
property lastName;
function init(firstName, lastName){
variables.firstName = arguments.firstName;
variables.lastName = arguments.lastName;
}
}
And the calling code:
// person.cfm
person = new Person("Abigail", "Bowen");
writeDump(person);
Notice how I am not using the synthesised accessors here, I am purely setting the argument values into same-named variables-scoped variables.
However when I run this code, I see this:
Note how the properties have been populated. There's no problem with this, but I'm clearly not understanding how the accessors flag is supposed to work. I thought it was merely intended to synthesise some accessor methods for me (which it has), but that's all.
Also note that if I modify the CFC definition to not set accessors to true, then the dump shows this:
So no synthesised accessors (as expected), but also now the properties aren't even being displayed (with the variables-scoped values or not).
I don't really understand this conflation of "properties" and the accessors setting? Surely the accessors setting should only impact whether those accessor methods get created?
If I was only seeing this on one of the platforms, I'd probably put it down to a vagary of how writeDump() interprets the property definitions. But the behaviour is the same on ColdFusion 11, so it really does seem like there's some difference in behaviour I'm not quite getting.
Can anyone explain this? Are there any docs which explain it? If not... um... why not?
My underlying concern here is that the property values are not being stored "properly" and might cause me problems once I implement more of the code.
UPDATE:
At least on ColdFusion, it seems to be just a change in writeDump()'s behaviour, because if there are getters for the properties (whether or not the accessors flag is set) then the property values start showing up in the dump. This is not the case on Lucee though, so there's still a question mark there.
For the sake of full disclosure, this question is a summary of a question I also asked on my blog ("CFML: trying to understand accessors"). The duplication is intentional as my blog gets a different audience from that of this site.
Without accessors=true, the property declarations are just metadata.
With accessors=true, the property declarations trigger the generation of getters / setters and thus a property is both a variables scope item and a pair of methods.
In your constructor, you assign to the variables scope items -- which would be the same as using the generated setters -- and when CFML dumps the component, it sees the property metadata and the generated getters and so it displays the values those properties have (since it can easily and safely call the generated getters).
This came up with ACF9. Until then the definition in the property docs was right: cfproperty declarations are just metadata. (see dump(getMetaData()).
In ACF9 this was not fully correct anymore for 3 reasons:
With accessors=true a getter and setter is generated for each property and those accessors read from and write to the variables scope. Cfproperty is not just metadata anymore, but has a direct effect on the behaviour of the instance. I like to think about it as the CF version of real OO properties (introduced by accident).
The cfdump implementation changes its behaviour based on the property declarations. If property name; is defined and method getName() exists (generated or implemented) it is added to the property section of the dump.
The property attributes control the ORM.
Since I got to know those features, I design all my (public) CFCs to look right when dumped, eg. I only use the property declaration (+ getters) when I want to have it visible. In addition, you can implement methods that are only called by the dumps and cost nothing on instantiation:
struct function getDebug(){
var x = doSomethingExpensive();
return { "Foo":f, "Bar":b, "Baz":x };
}
//or for a user iterator
string function getName(){
return qUsers.name[index];
}
Some caveats I know:
ACF always calls the getters from the dumps, while in Railo/Lucee the value from the variables scope is shown. Thus, the above examples (getDebug()and getName()) don't work on Railo/Lucee.
If the getter is not public or results in an error, the dump shows an empty string for the property (not sure here, maybe the property is missing instead).
Property declarations in extended CFCs are ignored. This gave me some headache in ORM entities that use inheritance, because you are not allowed to declare a property twice. Thus, you have no possibility to show a property that is defined in a base CFCs.
Railo/Lucee seems to ignore the property types. All accessor accept and return only strings (see getMetaData()).
Minor: In ACF when you activate the accessors, but deactivate getter and setter for a property: property name="user" getter="false" setter="false"; it is still visible in the dump - it should be hidden.
I've noticed that all the cases in ember.js the function.property() is found in a function with a return statement. Is that always true? If not, can you give me a case where a function that doesn't have a return statement but has a .property()?
You need to see a property as a attribute. Ember doesn't make a distinction between functions and attributes. If you have a property it must return a value, since it acts like an attribute.
If you're looking not to return a value, but you want something to change based on another property, you'd use the observable pattern. Have a look in the guide for more information.
I'm very bad with recursion, never used it before. I know the theory of it .. not that that helps :)) For my problem i have a structure of TCollection that contains TCollection and TCollectionItem etc .. I have to write a recursion function that will read all my TCollectionItems.
Here is graphical view:
TCollection->TCollectionItem(s)->TCollection->TCollectionItem(s)
TCollection can have 1 or even 2,3 TCollection's under him OR none.
Here are few more examples:
TCollection->TCollectionItem
TCollection->TCollectionItem->TCollection->TCollectionItem->TCollection->TCollectionItem
etc ..
Please tell me if i described the problem badly, i probably did .. please ask if something is unclear :)
Thanks for the support!
You haven't indicated the prototypes of the TCollection methods so as to enumerate and to read your TCollectionItems, and other needed details.
However, this is definitely solved by: The Composite Design Pattern.
The aim of this pattern is to traverse a recursive form, and to forward a call on a composite onto its composants and so on, until that reaches the leaves ( TCollectionItems with an empty TCollection in your case)
The only way to recursively access child TCollection objects, without knowing the class types of the owning TCollectionItem objects so you can type-cast them, is to use the VCL's RTTI information.
In C++Builder versions prior to XE, VCL-based RTTI is only available for __published properties. Given a TCollectionItem (or any general TObject) object pointer, you can use the GetPropList() function declared in TypInfo.hpp to retreive a list of that object's published property information. You can then loop through that list, checking for any properties that report a TypeKind value of tkClass. When you find one, use the GetObjectProp() function to retreive that property's TObject pointer value, and then use dynamic_cast to make sure it is really a TCollection object before you access its child TCollectionItem objects.
In C++Builder 2010, a new Enhanced RTTI system was introduced, declared in Rtti.hpp, that provides information for all members of a class, including non-published properties and fields. With this enhanded RTTI, a child TCollection does not need to be declared as a __published property anymore. Under this system, you would use the TRttiContext class to access a TRttiType object for your recursion's starting TCollectionItem object, then use the TRttiType::GetFields() and TRttiType::GetProperties() methods to look for child TRttiField and TRttiProperty items that report a TypeKind of tkClass, then use the TRttiField::GetValue() and TRttiProperty::GetValue() methods to get the TObject object pointer that can be type-casted to a TCollection pointer with dynamic_cast.