Hunting for bugs in OXT 0.98 and above

[tperry2x]

As well as the much-improved new icons for colour selection, the labels: 'Vector Shapes', 'Vector Tools', and 'Paint Tools' are super.

That's great to see. The mere fact that your Mac opened it is a start and a huge relief.
(btw, this might happen - because I'm a moron)

Choose this tool.

oops-1.png (6.31 KiB) Viewed 303 times

"Beep"

I left my debug in!

oops.png (11.35 KiB) Viewed 303 times

[tperry2x]

2. Gives me a chance to fool myself that I am somehow contributing.

Haha, point 2 made me laugh.
Well it's good to know these mac-specific issues.
I have a new icon I'll be using for those:


This is how it's supposed to work, on Linux and on Windows, but should have known the mac would throw me a curve-ball (again):

how-it-should-look.png (14.03 KiB) Viewed 301 times

[richmond62]

OK: slight 'crit' coming up (would you expect anything else?
-

Screenshot 2024-05-04 at 14.59.35.png (227.37 KiB) Viewed 300 times

-
-

Screenshot 2024-05-04 at 15.01.15.png (112.95 KiB) Viewed 297 times

-
I was able to select the
-

Screenshot 2024-05-04 at 15.02.31.png (5.84 KiB) Viewed 297 times

-
Icon BEFORE selecting a line colour or a fill colour: as the default line colour was set to WHITE I was led to believe that the tool did not work when I tried to draw a vector shape on my card.

[tperry2x]

I set them to always be filled as default. You could turn off opaque, but I know what you mean.
The IDE seemingly selects a random fill and stroke colour at boot (and I can't trace where these come from at the moment).
Once you set your own then it's more logical.

But even if I could set it so that the fill and stroke had the right randomly selected colour on boot, that would be a start.

I did test on other OSs and a mixture of them, but this is all valuable info.

Got to go and cut the grass now, so will pick this all up later....

[tperry2x]

Okay, grass cut...
Hedges trimmed, Dad's shopping done, Dad's telephone wiring fixed, Cars washed, Gate put back on hinges, dog walked, Kid's bicycles fixed.... (so much for a restful saturday).

OXT head back on.
So my thinking was first to return IDs of the buttons, and return if they have a fill colour set. If the Foreground / Background fill buttons in the tools palette have no colour overlay (if they appear white on the icon), this returns "unset".

Then if you pick colours, and click the "list btns", their colour overlays are shown.
So this is okay - it detects if the overlays have been set or not.

However, I know that the line colour and fill colour are always set to 'something' when the IDE starts, so - how do I find out what this actually IS when the IDE has loaded and I make my first stack, BEFORE I choose a colour? I'm interested in what the initial colour is (if that makes sense?)

pickers.png (12.34 KiB) Viewed 280 times

[richmond62]

Presumably the colour pickers are set in the livecodescript document that makes the Tools stack . . . ?

Can you not set the line colour to black and the fill colour to white THERE, so those become defaults?

[tperry2x]

Can you not set the line colour to black and the fill colour to white THERE, so those become defaults?

That's exactly what I want to do for the paint tools, and the vector tools. But it won't let me.
I'm not being very clear, but I can't think how to best explain what I mean.

I can set the colours manually by choosing the colours I want, and I can see this showing in my debug stack:

Screenshot at 2024-05-04 19-59-48.png (18.25 KiB) Viewed 270 times

But, what I cannot do at the moment is detect the initial fill and pen colours before I choose any (but they are indeed set if you start painting with a brush) - when you create a new stack after opening OXT.

[richmond62]

I wonder if there is some code in the livecodescript document that generates the MenuBar stack that sends commands to the Tool Bar?
-

Fill-MaCavity.png (28.48 KiB) Viewed 265 times

-
Presumably those numbers refer to the relevant buttons on the ToolBar stack.

[richmond62]

If, for the sake of argument, your buttons each "just" consisted of 2 overlapping graphic squares:
-

Screenshot 2024-05-04 at 22.20.11.png (145.63 KiB) Viewed 264 times

-
It might be a lot easier to, initially have them set to some unchanging default colours, and then when clicked on, and the colour chooser used to set their fillColor (BackGroundColor) transfer that to the pen, brush, what-have-ye.

After all, if I can do this:
-

Screenshot 2024-05-04 at 22.26.56.png (77.79 KiB) Viewed 263 times

-
It should not be unduly difficult to set that via the buttons on the Tools palette.

[tperry2x]

Presumably those numbers refer to the relevant buttons on the ToolBar stack.

Yes, they are. I did mention that a bit further up with the debug stack.
The reason I'm referring them by ID and not name is because the revTools stack is generated by script (it's a script-only stack which is created dynamically). It does not help that as default, it creates buttons with the same names, so referring to them by ID as they are created is the easiest way to keep track of what is what. (which is what the debug stack above does).

It might be a lot easier to, initially have them set to some unchanging default colours

Yes, that would be lovely. Except I can't.

After all, if I can do this:
It should not be unduly difficult to set that via the buttons on the Tools palette.

You'd think so wouldn't you!

not-logical.png (17.24 KiB) Viewed 260 times

edit: so, instead of using an RGB value, I used the word "brown".

this-is-not-brown.png (8.89 KiB) Viewed 257 times

I'd say that OXT's / LCC's version of 'Brown' (which turns out to be 151,3,22 or #970316 is more red than brown). I'd consider 'Brown' to be 75,45,20 or #4b2d14 - but then colour perception is all relative I guess.

I then tried with 'green' and it is indeed green:

still-nope.png (41.78 KiB) Viewed 256 times

So I chose the brush colour picker. It's not green, so I don't know how it's setting that colour via the message box.

In theory, according to the dictionary, I should also be able to use:

Code: Select all

set the penColor to "blue"

But that doesn't work either.

But, irrespective of all that - I'm just trying to retrieve the initial brush and pen colours that the IDE is setting at startup:

Screenshot_2024-05-04_22-24-37.png (23.62 KiB) Viewed 247 times

(this is obviously wrong).

Screenshot_2024-05-04_22-26-04.png (7.74 KiB) Viewed 247 times

As is this - it returns nothing.

So, now I've come full circle on this post - this shows you what I was trying to explain initially (and failing to).

Here's another demo.
Start OXT and make a new stack. Don't pick any foreground / background colours. Just use the brush and pen.
Note the time (22:59). Close the stack without saving. Quit OXT.

Reopen OXT. Do the same again, make a new stack - don't pick any foreground / background colours. Just use the brush and pen as before. Note the time (23:00) - Different each time (why?)

why.png (31.69 KiB) Viewed 236 times

I had a random thought while writing this post, I mean - they are all shades of LC-green aren't they? So I wondered if that green colour was being set somewhere. As if to rub it in, I tried this again one last time to check I wasn't going mad:

rub-it-in.png (6.74 KiB) Viewed 233 times

So, seems that's that theory out of the window. I think I am indeed going mad

I mean, once you manually pick a foreground and background colour - then it's all rosy and everything seems to be logical from that point forward. It's just setting these at initial load that evades me, as the properties seem a bit unattainable at the moment.

[tperry2x]

Finally found out why.
After a lot of trial and error.

gotya.png (18.73 KiB) Viewed 227 times

You have to choose the tool FIRST, then pick a colour or issue the message box commands with the tool chosen.
THEN the tools will use the right colour. If you run those message box commands WITHOUT a tool being chosen and WITH the default colours chosen by the IDE in place, then they seem to be random.

As soon as you manually pick the fill and pen colours via the swatches, then all is logical.

blah.png (7.3 KiB) Viewed 227 times

But you can't present the user with two colour select dialogs when they open the IDE. That would be extremely annoying.
What a pain in the posterior.

[tperry2x]

Finally, found what will work.
When the OXT IDE is first loaded, random colours are no longer assigned. Turns out these were being pushed from the engine, but I'm able to correct that in-stack with xTalk scripting.

All it needs is this handler when the Tools palette is first generated:

gotcha.png (6.24 KiB) Viewed 215 times

Then the fill colour is white, the pen colour is black!

finally.png (18.29 KiB) Viewed 215 times

Finally! - That was a bit of a nightmare, but finding out where these random colours were coming from was key in getting it sorted.

[richmond62]

Wow!

dead impressed: but, presumably not available for us bottom-feeders until 1.05.

[tperry2x]

presumably not available for us bottom-feeders until 1.05.

I've enabled this in the updates.
Please check for updates. (The first time you run it, the update will replace the 'updates.livecode' file)

IF this all goes to plan, and you get that installed...

Check for updates again.

With the first update in place, the updates this time will be different.
It'll download some more files and fix the colours on the tools palette as mentioned above.

This should take you to this build version:

Screenshot 2024-05-05 at 12.39.28.png (45.7 KiB) Viewed 211 times

Or, if that doesn't work - you can replace with the attached files manually:
[location-of-your-OXT-Lite-program-or-app (show package contents if mac)]/Toolset/palettes/tools/revtools.livecodescript
[location-of-your-OXT-Lite-program-or-app (show package contents if mac)]/Toolset/palettes/updates/updates.livecode
(note: if you manually replace these files, it won't increase the build version number, but that's not the end of the world)