Overlays.getProperty is broken.... still


#1
var e = Overlays.addOverlay("text", {
x: 300, y: 100, width: 10, height: 10 ,
backgroundColor: { red: 0, green:0, blue:0},
backgroundAlpha: 0.0,
visible:false,
text: "Hello, world!",
alpha: 0.0
});


var n = Overlays.getProperty(e, "text");
print(n);

result:

[07/30 09:45:18] [DEBUG] script:print()<< undefined

#2

Just a sec while I correct my derpiness…
Fail.
Nevermind.

Wasn’t attempting to call you a liar; just wouldn’t imagine something that fundamental would somehow get broken. Overlays has been in the code since way back when.


#3

:open_mouth: You Must know high fidleity better @AlphaVersionD. Old things still can break.


#4

You’re right. I should’ve known better. :wink:


#5

This broke almost all my projects :smiley: I spent about 8 hours trying to figure out why my scripts were no longer working and turned out to be a hifi bug.


#6

Bumping, because it is still a problem.


The Open and Honest Content Provider Community Dialog Thread
#7

Looking at the HiFi code … Overlays.getProperty() works for 3D overlays but doesn’t work for 2D overlays. This is “by design” - or rather “by implementation” - because of the way 2D overlays are implemented, getProperty() on 2D overlays apparently would result in a race condition.

Possible work-around: assuming your script is creating the overlay it could keep track of the properties it was created with.


#8

Well it used to work.


#9

Yes, I believe the implementation change.


#10

Yeah sounds like it needs to be fixed.


#11

Can you explain your use case? Yes, you used to be able to fetch the property that you set, but this isn’t a compelling feature. You set it, so you should already know it.


#12

The main reason would be to pass values between separate scripts, as in the case of using an overlay handler library (as an include). I guess you could store this information separately but now you are taking up twice the memory you would have been had you been able to just dump the value already held in the overlay.

I guess another way would be to write the data to the settings file but then you have an ever growing file on your hard drive.

It’s not a huge deal but it also doesn’t help the scripting system to be more intuitive. Why not treat 3D overlays and 2D overlays similarly?

What really bugs me about this whole thing is that one day somebody can suddenly decide something isn’t very important and change it to break hundreds if not thousands of scripts. We need to start thinking about backwards compatibility pretty soon (well… soon as in “release” haha, this is still beta after all).


#13

There’s a messaging API that can be used to pass information between scripts. Overlays should not be used for that purpose.

The backend mechanisms for rendering them are completely different. We control the rendering of 3D objects in the scene and thus we have all the control required to make them thread safe. 2D overlays are implemented using QML, which can only be interacted with on the main thread. We don’t have any control over the constraints of QML.