Checkboxes not being set to their IDE-specified initial "visual state"

Some checkboxes are not being set to the “Initial State” defined for them in the IDE. Now this is a humongous mess of a program, it’s for my personal use and I’ve just kept adding to it over the years and through many versions of XoJo. But I’m at a loss as to what is happening and how to correct it.

This is Xojo 2019 Release 3.1 running under Mac OS X “Catalina” 10.15.5.

The window has well over 100 controls on it. I am looking at two particular problem controls. If I set their “Visual State” to “indeterminate,” when I run the program the window opens with them showing the minus-sign-like “indeterminate” appearance. if I set them to “unchecked,” they are initially unchecked; but if I set them to “checked,” they open as “unchecked.” A MsgBox call placed as the first line of the “Open” event handler, set to report the control’s value, reports the value as “false,” i.e. I don’t think any code of mine could have executed and set them to “false.”

If I build an application, the behavior of the application is the same (checkboxes set as “checked” in the IDE are initially unchecked in the application).

If I delete the checkboxes, reconstruct them manually with new control names, and change the code to reference the new names, the problem will occurs.

If I export the window, delete it, recompile (and get errors), and import the window, the problem still occurs.

Of course I can work around the problem by adding code to set the checkboxes as desired, but it is annoying, and it does not give me a good feeling when Xojo is not compiling what I wrote.

Is anyone aware of any general issues? Is there an undocumented limit to the number of controls on a windows, with nonspecific “bad karma” if you exceed it?

It is a bug in version 2019r3.1. The next release will include the fix. <>

I think you can put this in Open event:

me.VisualState = CheckBox.VisualStates.Checked

Please, stop using MsgBox (as t is deprecated and it can be a potential bug doer).

Use instead System.DebugLog (available since REALbasic 5.5).

The single most basic expectation I have of any RAD tool is that I can add a quick MsgBox to aid debugging.
Going and looking for some obscure place to find a line of text is not helpful to me, nor does it pause execution of the code.
I wish people would stop taking away functionality because it is somehow ‘good for me’

this beautiless bug is many months old without a hot fix …

My brain is very slowly trying to learn MessageBox instead of MsgBox.

replace it with a method Msg

[quote=491449:@Jeff Tullin]Seriously?
The single most basic expectation I have of any RAD tool is that I can add a quick MsgBox to aid debugging.[/quote]
Yes, seriously. The advice Emile is repeating comes from engineers within Xojo.

Calling up a message box changes the event stack and window order. It is the absolute worst way to debug an events order issue.

This bug is not event order related, so the advice is out of place. The “um actually” effect that ravishes this board.

Update: With DebugLog and breakpoints you can get the same effect without causing behavior issues. If anyone wants any help, feel free to reach out!

I suppose you mean MessageDialog. :wink:

API 2.0 renamed MsgBox to MessageBox

Okay, I’ve missed that change. :blush:

Renaming it obviously fixes something. :wink:
But this has gone off topic. Please ignore msgbox here.

The topic is checkboxes.