How do you guys do enums? I am trying setting an object to my class statics but I have a problem referring to it in my
checkof the properties. Here is an example
of what I mean https://tinyurl.com/y5udhbj5
Generally, is there any preferred pattern to do enums with qooxdoo?
@voger There are a number of ways to write a check. One is to provide an array of values, as you're trying to do there, but it's not run as a function. I think it's hard-coded at compile time, or something equivalent that prevents use of class names and this. The best alternative is to have check be a function that takes in the value being set, and returns true of false based on whether the value is allowed. That function has access to class names and this.
That said, keep in mind that check is only used in the debug version of your app, not in the typical full build/deploy for production. What you want to use instead is validate. here's an example: https://tinyurl.com/yxs8dowr
(I have no idea what the "unrecoverable internal error" is that appears when first loaded. The application is running properly and can be rerun thereafter without any error.)
qx.debug-related, but somehow those checks get stripped.
check key is really not suitable to check runtime values (I always wondered about the additional validatekey), but only for type checking during development.
@sqville It has been picked up by the package browser, but unfortunately there were compilation problems: https://qooxdoo.org/qxl.packagebrowser/qxl.packagebrowser/#sqville~ville.Clean~problems
I had similar error messages when compiling my app recently after cloning my repo to another location.
It turned out that some folders had incorrect casing.
I'm not sure it's the same issue but I thought it might be,
npx qx update and is more up-to-date than the Package Browser which is usually only rebuilt once every 24 hours.
qx.ui.layout.Grow, or it’s a HBox/VBox and the scroller is added with { flex: 1}). Please do a playground example and ill take a look
getRoot()) will try and distribute space to it’s children (eg p and p2) according to the rules you give it, and also taking into account what the widget says that it needs. When a widget has width of null, then the widget will assume the width of all of it’s children; this causes it’s parent (getRoot()) to think that is what the widget needs and therefore will try to allocate that space, at the expense of other widgets which do not have a width. But the issue is that, as a scroller, it is supposed to have scroll bars and specifically not try to force it’s width beyond what the container would normally give it - this is how it worked in v5, and the regression was that the width was set to null which caused the scroller to demand more space
.po files into ru.po, and if you recompile the widgetbrowser/demobrowser locally it should just start using it.