For text fields FieldName.setText(null); can reset the field. How can I do the same for JMonthChooser and JYearChooser fields to reset them to default values?
I don't think there is a way to "reset" a JYearChooser field because its setValue() method takes a primitive int as argument. Therefore:
JYearChooser field = new JYearChooser();
field.setValue(null); // compile error
field.setValue(""); // compile error
Setting the year to a negative value doesn't work either. Your best bet (which is what I have done) is to include a check box that will enable or disable this component. That way, you can do something like this:
if (field.isEnabled())
{
// Do something
}
I needed to do this for a feature that I created to override values. Since I could not set these fields to blank, I needed something to ignore the field if an override wasn't required. This was the best I could come up with to work around that issue.
I assume that JMonthChooser has the same problem. However, this is not the case for JDateChooser. For those field types, you can do the following to check if it is blank:
if (!(JTextField) prodStartDate.getDateEditor().getUiComponent()).getText().equals(""))
{
// Do something
}
Related
Lets have these two getters in Kotlin:
data class Foo(var id: String){
val reference get() = Reference("Patient/$id")
}
data class Foo(var id: String){
fun getReference(){ return Reference("Patient/$id") }
}
Does the first one have some performance cons? I like it more, but I am not sure if they are built into same bytecode, or the first one adds more things, because I am basically delaring new variable and not just method.
In your example, they are equivalent behind the scenes (but obviously, you need different syntax for using the property vs. the method). Specifically, Kotlin will generate a backing field if any of the accessors use the field identifier, and the autogenerated get and set accessors do use field. So in order to avoid a backing field, you need to supply your own get accessor and (in the case of a var property) a set accessor, and none of them must use field.
Whether a property has a backing field or not, reading the property turns into a method call to get() behind the scenes, and if it's a var, assigning to the property turns into a method call to set().
Note that it's possible to get into weird situations with var if your accessors are inconsistent: var foo: Int = 3; get() = 42 will always return 42 when you read it, irrespective of the initial value and whatever you might assign to it, because you will get an autogenerated backing field since you omitted the setter, and that's what the autogenerated setter will set.
Using properties instead of Java-style getter/setter methods is strongly preferred in Kotlin.
(Thanks to #AlexeyRomanov for pointing out the specific rules.)
I don't want to disable the warning altogether and I already know why you supposedly shouldn't use Optional as a parameter. However, I don't think it's relevant to my case.
For illustrative purposes, I have code that looks like this:
//IntelliJ reports: 'Optional<ForeignDataTransferObject>' used as type for parameter 'data'
private LocalSystemPerson extractPerson(Optional<ForeignDataTransferObject> data) {
return data
.map(data -> data.getPeopleListWrapper())
.map(peopleListWrapper -> peopleListWrapper.getList())
.map(listOfForeignPeople -> listOfForeignPeople.stream())
.orElseGet(Stream::empty)
.findFirst()
.map(foreignPerson -> convertToLocalSystemPerson(foreignPerson))
.orElse(someFallbackValue);
}
It's getting the list of people then the the first item then converting it. Since I'm calling an external API and getting a data transfer object with a bunch of fields any of which can be null, any collections are wrapped in an extra class, and even then getting an empty list is a valid case. So, I end up with a verbose code like that to convert a single value. I squirrelled it into a separate helper method to avoid having all that verbosity in one place.
However IntelliJ is complaining that I'm passing an Optional parameter. That is something I'd normally agree with but I don't see it as a problem if it's a private method that I am using to save another method from getting too long - I might need to grab more than one value off the data transfer object.
I still want to avoid creating public methods that accept Optional or fields that hold Optional but I want to disable the inspection for private methods.
I'd prefer to not have to annotate each method with #SuppressWarnings("OptionalUsedAsFieldOrParameterType") as it quickly gets annoying. I can have multiple of these methods in various classes that accept some foreign DTO.
Similarly, I also don't want to pass in a non-Optional parameter only to wrap it inside the method. Especially since In some cases I only have an Optional already, so I'd have to unwrap it then wrap it back with something like myMethod(data.orElse(null)) and then do Optiona.ofNullable(parameter) in the method.
All in all, it seems like an unreasonable limitation to always treat that as a problem even if it's not going to be transferring data across systems or across layers, etc.
So, can I disable that generally from the settings for just private methods but nothing else?
For the current moment there is no option to disable the inspection for private methods. Please follow/comment the issue created for your feature request at YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-207468
Thank you
I am trying to define the value for the method PropertyFactory.iconImage for my layer object. The return value PropertyValue<String> should use a certain field inside the Feature to define it's value.
The result could look something like that:
PropertyFactory.iconImage(Expression.step(Expression.get("myfield"),"mydefaultValue", Expression.Stop.stop("case1", "valueForCase1"), Expression.Stop.stop("case2", "valueForCase2"));
Unfortunately I was not able to find a similar solution so far.
The following expression solved my problem:
SymbolLayer("asset-layer", "assetMapDataSource").withProperties(
PropertyFactory.iconImage(Expression.match(
Expression.get("asset_type"), Expression.literal("bbq_default"),
Expression.stop("bridge", Expression.literal("bridge_default")))))
Edit:
Some more information why I used the method in my example:
PropertyFactory.iconImage expects a string which points to a certain bitmap that you have saved before via MapBoxMap.addImage(...).
Expression.match is used to "match" a certain String based on the given stop and default cases.
Expression.get is used to access a certain field inside your feature property. In this case the field "asset_type" provides a certain type that I can match against.
The default case of the Expression.match and each Expression.stop are using the Expression.literal. This method is used to tell the underlying expression system that your value is from type x (in that case String). Take a look at the Expression.literal methods to get an idea of that.
Each Expression.stop is used to symbolize that the Expression.match is trying to "match" the given value from the first parameter of Expression.stop against the given Expression.get value. If Expression.get and that method value are the same, the 2nd value of the Expression.stop is used which provides the actual value for the Expression.iconImage. If the underlying expression system wasn't able to find a "matching" stop for the given Expression.get value, the system will use the default value (in that case Expression.literal("bbq_default")).
I have got my protobuf GeneratedMessage(only castable to this base) and I would like to get the text format(parsable by TextFormat class) including all fields of this message.
I see only two ways:
by reflection find all setters and put in some values, then use TextFormat
get list of fields(from api) and recreate this format
Neither of them is good, so my question is: is there any better way? If not which of these you find better?
If you have a GeneratedMessage, you may simply pass it into any of TextFormat's print methods. GeneratedMessage implements the MessageOrBuilder interface which these methods want.
EDIT: I see, your problem is that you want it to actually print all the fields, and TextFormat only prints fields that have been filled in.
You will have to fill in the fields with dummy data. This is actually pretty easy, though:
Message fillAllFields(Message prototype) {
Message.Builder builder = prototype.newBuilderForType();
for (FieldDescriptor field: builder.getDescriptorForType().getFields()) {
builder.setField(field, prototype.getField(field));
}
return builder.build();
}
The trick here is that we're calling setField() for every defined field, not just the ones that are set in prototype. For the ones that aren't set there, prototype.getField() will return the default value, but we're still explicitly setting the field to that value, so it will now show up in text format. Note that this actually creates a different message from the original -- setting a field to its default value is detectably different from leaving the field unset.
I'm trying to call a drawable spectrum from my controller, then set the following data to it. I keep getting an error that the left side must be a variable. The call is getting a specPanel(JPanel) which has a DrawableSpectrum assigned to it. SpecPanel has a method called get Spectrum which returns this spectrum. In both of these call I put a System.out.println if they are not null, and they never are.
Am I missing something here?
con.getSpecPanel().getSpectrum() = (DrawableSpectrum)interpreter.getShapes().get(0);
Thanks.
You should use Spectrum's setter instead, assuming you have one. If you don't you should implement it and then you can set the data like this:
con.getSpecPanel().setSpectrum((DrawableSpectrum)interpreter.getShapes().get(0));
Assignations can be made on fields and variables, that's what the setter does under the hood.