On Thu, Jan 20, 2022 at 5:13 PM Ulf Hermann <ulf.herm...@qt.io> wrote:
> > Well, the number of names isn't fixed is the point - they're loaded at > > runtime and will change (increase) from time to time. > > Then an enumerator won't really help you. The point of an enumerator is > that each entry is a constant. > Each entry is still a constant either way. What I'd intended to provide is a sort of a "remapping". I simply need stable names from the QML side, that map to something (as "definitive" as this may sound), which "something" is going to be mapped to vector indices on the C++ side. The latter (the vector indices) I must assure are not changed from one version to the next. While I do still need to provide some convenient API for QML to modify the value(s). This in a nutshell is what I'm trying to do. Perhaps doing it with an enum in QML is misguided, I was simply attempting to avoid defining one such enum in C++ and needing to reship the compiled binary (to a colleague). Perhaps my whole workflow idea is flawed, I guess. If the names and values can change at runtime, you should use a > QVariantMap or a JavaScript object. > Yes, I suppose. Perhaps that's what I'm going to do in the end. Thanks for the input. If for each version of the program the set of names is fixed, and only > the values change, then properties on a singleton are the better choice. > Actually the other way around (as, described above). Kind regards, Konstantin.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
