We can't yet delete the New() method for backward compatibility reasons but I
think I fixed your issue in [1]. Instead of static maps queried by class name,
the enumeration values are simply stored as member variables now which will
give you more flexibility in subclasses of EnumerationProperty. The branch it
is not yet merged into the master but it will be reviewed soon.
[1] https://phabricator.mitk.org/T24541
Von: Bertram Sabrowsky-Hirsch [mailto:bertram.sabrowsky-hir...@risc-software.at]
Gesendet: Wednesday, March 28, 2018 2:29 PM
An: Dinkelacker, Stefan <s.dinkelac...@dkfz-heidelberg.de>;
mitk-users@lists.sourceforge.net
Betreff: RE: Design of mitk::EnumerationProperty
Hi,
In that case, shouldn't the New() factory method be deleted/protected in
EnumerationProperty? Also the documentation of the class is a bit misleading as
it states that direct usage is possible (EnumerationProperty.h: "[...] 1.
Directly use the class and add your possible enumeration values. [...]")
I tried to derive my own class, but that will not work as the public methods
GetMemberEnumIds and GetMemberEnumStrings of EnumerationProperty are not
declared virtual (and thus will always return the static member maps associated
with the class name when down-casted to the EnumerationProperty).
I resolved this for me by implementing a custom EnumerationProperty class
derived from BaseProperty that can handle dynamic enumerations. However, this
does not work with MITKs Properties table view, a feature that I find very
convenient and use quite a lot - is there a way to make a custom property
editable in the Properties table? Also, this way I'll have to register a custom
PropertyPersistanceInfo once I have to deal with serialization.
Kind regards,
Bertram
From: Dinkelacker, Stefan [mailto:s.dinkelac...@dkfz-heidelberg.de]
Sent: 28 March 2018 13:24
To: Bertram Sabrowsky-Hirsch
<bertram.sabrowsky-hir...@risc-software.at<mailto:bertram.sabrowsky-hir...@risc-software.at>>;
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
Subject: AW: Design of mitk::EnumerationProperty
Hi,
the EnumerationProperty class is not supposed to be used directly but to be a
base class for the actual enumeration. You find many examples of subclasses in
MITK when searching for "public EnumerationProperty" in all header files. Even
for your use case you would have to derive a generic subclass that is able to
handle dynamic enumerations.
Best,
Stefan
Von: Bertram Sabrowsky-Hirsch [mailto:bertram.sabrowsky-hir...@risc-software.at]
Gesendet: Tuesday, March 27, 2018 5:25 PM
An: mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
Betreff: [mitk-users] Design of mitk::EnumerationProperty
Hi everyone,
When using mitk::EnumerationProperty I noticed some behaviour that I did not
expect.
I was using mitk::EnumerationProperty to assign dynamic enumeration properties
to specific nodes in my application like this:
auto prop = qilin::EnumerationProperty::New();
prop ->AddEnum("Apple", 0);
prop ->AddEnum("Pear", 1);
prop ->AddEnum("Orange", 2);
node->SetProperty("Fruit", prop);
I figured this was alright since in the documentation of
mitk::EnumerationProperty it reads:
* To use the class enumeration property you have 2 choices:
*
* 1. Directly use the class and add your possible enumeration values via
* AddEnum(name, id). NOte that the ids do not have to be in any order,
they
* just have to be unique. The current value is set via SetValue(...) and
* retrieved via GetValueAsId() or GetValueAsString().
However, this only works as long as a single instance of
mitk::EnumerationProperty exists.
If multiple custom enumeration properties do exist, the instances affect each
other by changing the enumeration values.
I looked up the implementation of mitk::EnumerationProperty and found the cause
there:
The maps for the enumeration Ids and Strings are associated to the class name
(GetNameOfClass) of the instance and stored in a static map member.
This way, all instances of mitk::EnumerationProperty share the same maps for
ids and strings and changing one instance will affect all the others.
I feel like this is inconsistent with the documentation.
Also I'm not sure of how to work around this issue since the GetMemberEnumIds
and GetMemberEnumStrings methods are not declared virtual. Deriving from
mitk::EnumerationProperty for each enumeration type won't work either since I
do work with dynamic enumeration types (they depend on imported data). I can
think of a workaround that overloads GetNameOfClass and returns some UUID, but
that does not seem like a proper solution either (also the data would never get
deleted from the static member map). I could implement my own
EnumerationProperty, but this way the Property Editor won't be able to show the
dropdown for the enumeration (still, it's the best solution I can think of so
far).
Maybe I missed something, but in my opinion the design of
mitk::EnumerationProperty is misleading and should be changed.
Kind regards
Bertram
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
