I made a feature request just two weeks ago and it got closed by ‘Xojo Bot’ without any comment.
Does that mean that the request is declined?
I’d like to learn about Xojo’s decision making process regarding feature requests.
I think Robin preferrs that you make a case for every control and lists what properties you’d like to have public. And since Robin put the “information required” label on it, the bot will close it after 2 weeks, if you don’t answer. Strange that this label was not removed after your answer.
I myself sometimes go through plugin classes to make properties debugger visible, when I refresh older code.
Thank you @Christian_Schmitz,
to my understanding, the request is closely related to roadmap items (current) #4, 5.
Maybe the request will be handled in this context. Then it would be logical to close it as an individual item.
Actually, I’d like to know more about what #4 and #5 will bring. This is the broader context I am looking at. Is there any information material/webinar available?
I don’t think the roadmap prevents this.
e.g. with our plugins, you can implement a property either as a regular property, as a computer property and as a pair of getter/setter methods. I often change from the getter/setter to computed properties.
I’m interested. Do you have a doc or demo video for that topic?
Robin is on holiday at the moment. If you reopen it in a week or two (button top right) Robin will probably see it on his return and sort it.
Yup, old feedback used to automatically remove information required once the author responded, it looks like someone forgot to tell the bot that in the new system.
Then let’s assume that Mr. Xojo Bot’s manager will read our conversation 
Have a good weekend!
1 Like
I asked on it in the MVP chat to speed this up.
3 Likes
Looks like Travis fixed it over the weekend.
And they may change the bot to not close it when you posted after the “information required” label was added. The bot should do the same as in Feedback.
2 Likes
I had begun to use computed properties as a way of implementing a debugging feature that VB used to offer : break when variable changed
(Add a breakpoint in the setter)
Recently in a process of profiling, I found that using a computed property repeatedly in a long loop carries quite a time penalty.
But changing it back to a normal variable saves a lot of cycles.
Yes, we do similar for debugging.
And usually I do a lot of changes in the program to debug.
Later I carefully only commit the bug fix and discard all the changes made for debugging.
That’s really unfortunate. I literally only ever use public regular properties when it doesn’t matter if modified from the outside. And that’s rare.