Store and Modify a Colour with Code: Possible? How?
-
@GameCRAZY IT IS A STRING!!!
That IS the problem.
-
@GameCRAZY do you know what I mean if I say "different data types?"
-
@Deeeds Yes, but you can still work with strings. I do know some Swift.
-
@GameCRAZY If you don't have access to type casting, nor can you set a type, then once data has had its type changed by the system (hyperPad) and it's no longer compatible with the data required of colouring something (what we're speculating is happening here) then that is the problem.
So labels of no use.
-
@Deeeds The label is only checking whether it's actually a string.
-
@GameCRAZY hyperPad implicitly converts everything to the needed data type at runtime.
-
@GameCRAZY No, the label makes a best effort to show what it can. It's not a type checking mechanism, it's a type handling mechanism.
And your contention, from the beginning, that both debugging by a label and that a label are somehow necessary are both wrongheaded. And you've continued to try to back that. That's why you're in a loop.
Just let that idea go. Labels cannot help, in this situation, and theCheater has already isolated anything a label could tell us.
-
@GameCRAZY Let me try to explain why your claim that a label will help is wrong, so you can see why it is that I'm telling you it's wrong, and you might understand why you feel the way you currently do.
You said you know a little Swift, that will help understand this.
Swift is an incredibly type strict language, for reasons Chris Lattner had in mind for the future that will now never be: Namely, that Swift should be the next language used to make the next operating system. But Swift still has convenience handlers, like printing a line to the console.
If you print something to the console, with Swift, looking at the output, you can't tell what type it is. It doesn't show. Just the content does (in most cases).
So an Int, Int64, Vector, String, Hex number, they all look the same.
If you show a label of a Hex number it's going to look EXACTLY the same as a label of the same figures as a string. The label doesn't help you know what type something is because it just makes a best effort to output something.
AND, @Thecheater887 had already isolated anything else the label could tell us as not being useful... he'd already done a round test to find where exactly his "code" was failing.
When you continued to press for your claim that a label would help, in the face of it being wrong twice, I pushed back.
If you feel hurt, or anything else, that's a result of pushing on something that is probably wrong.
-
@Deeeds I don't feel hurt... No, I just wanted a proper explanation, and I thought it was worth trying.
-
@Thecheater887 said in Store and Modify a Colour with Code: Possible? How?:
@Aidan-Oxley Forming and using a color.
I start with “#” stored in a box container.
I then generate 6 random numbers and append them to the box container, so it should read like “#1F390C” thus far. I then append FF for 100% opacity.
Output that to a change color, and my logic all the sudden doesn’t run by it, when with a standard-typed #FFFFFFFF or anything else functions normally.
This works fine for me:
I'd suggest what @GameCRAZY is saying and outputting the string to a label or text input to verify it is a valid colour.
-
@Jack8680 I was using ifs instead of an array, and started the box container with a ‘#’ instead of empty like you did.
-
@Thecheater887 the # and opacity are optional; it's pretty lenient. You can also do something like "f00" and it will understand it as "#FF0000FF" (red). Using ifs should still work, could there be a mistake in your behaviours somewhere?
-
It’s possible, but I distinctly recall my loops not looping as many times as I told them to.
-
@Jack8680 Exactly!
