Syntax error on while/wend statement

I need a little help straightening out a syntax error on the while/wend statement that is pointing to a checkbox array:

[code]While me.Value then rem checkbox array
StairwayDamper(2).Value = True

StairwayDamper(0).Value = True Rem Radio button

wend[/code]

No “then”.

The Idea is to cycle this damper in the loop until the checkbox is unchecked. But as it stands a beach ball stops one from unchecking the box. Most certainly the wrong way to do this. A 3 second pause on each close and open cycle

[code]Var i as integer
Var Damper As Dampers
Damper = new Dampers

While me.Value Rem Array check box.
StairwayDamper(2).Value = True Rem The Start Radio button

i = system.ticks
while system.ticks-i < 3*60 ’ 3 sec
wend

StairwayDamper(0).Value = True Rem The Stop Radio button

i = system.ticks
while system.ticks-i < 3*60 '3 sec
wend

wend[/code]

do you know http://documentation.xojo.com/ ?

The Select entry is:
http://documentation.xojo.com/api/code_execution/select_case.html

Any loop in the main thread (where everything runs except for Threads you create) is going to stop anything else from happening, include any UI interaction.

Instead, put a Timer on the Window, set it’s period to, say, 500 and its Mode to Multiple, then put your code in its Action event. Once the condition you want is reached, it can turn itself off and call the next method, if any.

Note: You won’t put a loop into the Timer. Because it runs during idle time every Period, it IS a loop.

Kem, that was an excellent answer for someone like me trying to restart programming in XOJO. I still do have the issue of creating a visual, seeing the close and open radio buttons change their value as the damper cycles. I see why but am trying to figure out a method for doing this. The timer needs to finish its business before changing the Radio buttons, so I’m wondering if I need two timers. One to open and one to close which trigger one another. Seems too complicated of an answer. Your thoughts are welcome.

I do find the XOJO docs to be very lacking with not enough useful examples or explanations and continue to look at my outdated Realbasic, The definitive Guide, I used to 18 years ago to write my Home Automation Program. To bad this publication hasn’t been updated since it was an excellent source of information in its days. I’m now doing a rewrite because of an outdated Powerbook running Realbasic 4.5 which was written a long time ago.

The Definitive Guide was outstanding, and most of its fundamentals still apply.

If I understand you, some outside even is taking place (damper cycles) and you want radio buttons to reflect those changes?

If so, what is causing those changes, your code, or something external? If the latter, how are you notified that it has, in fact, changed?

I am using a diagnostic window with many outputs that are controlled to turn on, off or be disabled with radio buttons. I also have three dampers that have a diagnostic routine which cycles them with pauses at close and open. This routine below activates the radio button associated with the damper to close and open it. It would be nice to see this visual associated with the damper as it cycles.

Call to the timer from the three damper check box’s:

[code]DamperSelected = me.index rem Use in DamperDiag Timer

if me.Value then
DamperDiag.Mode=2 Rem DamperDiag is the timer
else
DamperDiag.Mode=0 Rem DamperDiag is the timer
end[/code]

Code in Timer:

[code]Var Damper As Dampers
Damper = new Dampers

Select Case DamperSelected Rem saved property

Case 0 Rem Stairway Damper
StairwayDamper(2).Value = True Rem Radio button. Open Damper. This will not show the radio button change which is understanable. This is the problem due to the timer thread

Damper.pause(3*60) Rem 3 sec Pause

StairwayDamper(0).Value = True Rem Radio button. Close Damper.

Damper.pause(3*60) Rem 3 sec Pause

Case 1 Rem Bedroom Damper
BedroomDamper(2).Value = True Rem Radio button. Open Damper This will not show the radio button change

Damper.pause(3*60) Rem 3 sec Pause

BedroomDamper(0).Value = True Rem Radio button. Close Damper

Damper.pause(3*60) Rem 3 sec Pause

Case 2 Rem Diningroom Damper
DiningDamper(2).Value = True Rem Radio button. Open Damper This will not show the radio button change

Damper.pause(3*60) Rem 3 sec Pause

DiningDamper(0).Value = True Rem Radio button. Close Damper

Damper.pause(3*60) Rem 3 sec Pause
end[/code]

I think you have to rethink this as event-driven rather than linear. A Dampers object should raise an event after it changes state, pauses, or resumes after a pause. You would implement those events on your window and react to them.

You need to avoid this kind of code as it blocks the UI update. You could get away with it in a thread, but not in a timer. You might want to create a state machine. At any given time, you need to know 3 things:

  • what is the current state
  • what is the next action I need to take
  • when should that action happen
    You can use a timer to deal with the “when” aspect. Inside the timer, you take the next action, update the state, and determine the next action, if any. Then reset the timer to fire when the next action is needed.

[quote=492095:@Tim Hare]You need to avoid this kind of code as it blocks the UI update. You could get away with it in a thread, but not in a timer. You might want to create a state machine. At any given time, you need to know 3 things:

  • what is the current state
  • what is the next action I need to take
  • when should that action happen and where.
    You can use a timer to deal with the “when” aspect. Inside the timer, you take the next action, update the state, and determine the next action, if any. Then reset the timer to fire when the next action is needed.[/quote]

Tim, I wanted to let you know I took your advice and used your reasoning process. I wrought it down and realized I was making it way to difficult. This was the answer. I placed this code in a timer, used its delay and it works fine. Thanks for the direction.

[code]Var Damper As Dampers
Damper = new Dampers

Select Case DamperSelected

Case 0 rem Stairway Damper
if StairwayDamper(0).Value = True then Rem Stairway Damper Closed Radio
StairwayDamper(2).Value = True Rem Stairway Damper Set Open Radio
else
StairwayDamper(0).Value = True
end
Case 1 Rem Bedroom Damper
if BedroomDamper(0).Value = True then
BedroomDamper(2).Value = True
else
BedroomDamper(0).Value = True
end
Case 2 Rem Diningroom Damper
if DiningDamper(0).Value = True then
DiningDamper(2).Value = True
else
DiningDamper(0).Value = True
end[/code]
end select

do you ever use the variable named “Damper” ?
from the code posted you could remove the lines

Var Damper As Dampers
Damper = new Dampers

[quote=492144:@Norman Palardy]do you ever use the variable named “Damper” ?
from the code posted you could remove the lines

Var Damper As Dampers Damper = new Dampers [/quote]

Good call Norman, I missed taking that code out.

On another thought. I’m saving boolean values to a textstream text file and was wondering if their is a better way to read them back out converted to boolean to set some radio button values.

SAVE:
f[code]or i = (controlcount-1) downto 0
if self.control(i) isA RadioButton and RadioButton(self.control(i)).index = 3 then Rem Good IsA example from Tim Hare

TOS.WriteLine str(RadioButton(self.control(i)).value)

end
next[/code]

LOAD:
f[code]or i = (controlcount-1) downto 0
if self.control(i) isA RadioButton and RadioButton(self.control(i)).index = 3 then Rem Good IsA
if TOS.ReadLine =“True” then
RadioButton(self.control(i)).value = true
else
RadioButton(self.control(i)).value = false
end

end
next[/code]

There are definitely different ways to store this data
But you also have to consider what you might do with the application long term to really get a feel for “is it worth this?”

You could write the data as a “key value pair” so each line is like

      RadioButton N = true 

or false
then the left hand side is the name(radiobutton) and index (N) of the radiobutton and the right hand side the value
loading isnt a lot more complex BUT this would allow you to add or remove radiobuttons without having to alter the loading since if you cant find the button with that name & index you just skip it

The program is a one-trick pony home automation system Norman. Once it starts it should run forever. I wrote it 19 years ago using binary stream files which I liked for the sake of variants. Many were pstrings. The software system is still running 24/7. Troubleshooting the files can make life difficult though. I beat this around the forms for a week and decided to try text files this time but now must deal with string conversions. My actual question to you was much simpler:
Can this be a one-liner in some way to convert the string to a boolean?

Can this be a one liner in some way to convert the string to a boolean?

if TOS.ReadLine =“True” then
RadioButton(self.control(i)).value = true
else
RadioButton(self.control(i)).value = false
end

Ah ok
Yes it can be written as a one liner

Perfect! That will help immensely. I’m trying to get back up to speed after 18 years off from programing, so thanks.

Ah so I should advise you NOT to do that one liner as its less clear than your prior code ?
One liner ? better :stuck_out_tongue:
Clear code is better in the long run esp if you are the maintainer

Bob did a blog and a presentation about how to avoid your future self wanting to come back in time and hurt you
Its worth reading & watching
https://www.bkeeneybriefs.com/2020/05/xojo-design-mistakes-video/
https://www.bkeeneybriefs.com/2020/06/write-code-that-your-future-self-and-others-wont-hate/
https://www.bkeeneybriefs.com/2019/06/dont-overuse-variants/
https://www.bkeeneybriefs.com/2019/05/dont-use-goto/
https://www.bkeeneybriefs.com/2017/12/coding-habits-to-keep-you-alive-when-time-travel-is-invented/

[quote=492162:@Norman Palardy]Ah so I should tell you NOT to do that one liner as its less clear than your prior code ?
One liner ? better :stuck_out_tongue:
Clear code is better in the long run esp if you are the maintainer[/quote]

Point well taken, although what you did makes perfect sense. I generally use a lot of rem statements to keep it together.

Comments are great - right up until they arent maintained and are wrong or misleading
I try & write code that uses long variables names, long method names, and is as close to “self documenting and self describing” as I can make it without writing Cobol :slight_smile: (or applescript)