I sometimes do that (hiding a label which contains a dynamic value, as a variable, which I sometimes need to read).
It is very handy for debugging purposes as just switching visible = True in the IDE allows me to see when the value is updated… now the question… why is this bad ?
Why do you think it is bad?
It’ll interfere with threading things, that’s for sure.
If you need to find the value of a variable, use the debugger. That’s what it’s there for.
Properly implemented even threads are no problem. So my question still stands: why do you think it is bad? I sure hope you don’t expect us all to guess what might or might not be.
ha… no… I don’t expect you to guess… I expect you to enlighten me… To be honest I was guessing, myself… but I imagine using labels has at least more overhead than just storing the data in a variable… and as Tim said… Labels are not meant for that… that seems to be a good reason… Just I don’t know the implications of using them for this…
The implications are based on YOUR INTENT
If you (for debugging purposes) wish to “watch” that variable, then your approach is as good as any
otherwise insert breakpoints and let the debugger tell you (this will be a point in time)
Obviously you have a specific concern otherwise you would not have brought this up… what is your concern?
If you store variables in labels instead of properties you’ll get ThreadAccessingUIException
If we stuck to what is made for, I doubt we would have macOS and Windows. Probably would still be stuck with Dos.
If you like your debugging label, it does not hurt anybody.
For myself, though, I would rather use System.Debuglog.
@Dave S : My concern is that I am not as tidy and neat as I’d wish and sometimes I found that I left in my code this labels for more than debugging… they’re there in the final app… and they store useful values… And also that I didn’t know if this has an unwanted impact on performance/resources, etc
Roman, if you want to have a better idea of what is the impact of various portions of your program, check “Profiling” in the Project menu. Then make sure to quit the debug program properly, and you will have in the navigator the profile of the app, with the time it takes to execute each method.
As for your label, it consumes very little resources, and has an insignificant impact on processing time.
You miss my “properly implemented”.
Thread writes to variable.
Timer reads variable and refreshes label.
No problem.
I use this for example in an app. to give feedback on how many proteins have been processed. The calculation takes a long time, and a progress bar slows it down much more than using a label.
I also use labels to show the mouse coordinates in a canvas.
So labels have their proper use. It simply depends on what you use them for and how you implement it.