more efficient way to write this

Is there a more efficient way to write the following script? it is a simplified version of my actual script.
I guess i could work with handlers? or I’m talking nonsense now?
Ideally when the valueAC s recalculated it should also check the ValueAB again.

set valueA to the text returned of (display dialog "side A" default answer "")
set valueB to the text returned of (display dialog "side B" default answer "")
set valueC to the text returned of (display dialog "side C" default answer "")

set valueAB to valueA * valueB
if valueAB < "100" then
	display dialog "multiplication is smaller than 100, restarting AB" buttons {"restart"} default button 1
	repeat until valueAB ≥ "100"
		set valueA to the text returned of (display dialog "side A" default answer "")
		set valueB to the text returned of (display dialog "side B" default answer "")
		set valueAB to valueA * valueB
	end repeat
end if
set valueAC to (valueA - valueB) / valueC
if valueAC < 20 then
	display dialog "division is smaller than 20, restarting AC" buttons {"restart"} default button 1
	repeat until valueAC ≥ "20"
		set valueA to the text returned of (display dialog "side A" default answer "")
		set valueB to the text returned of (display dialog "side B" default answer "")
		set valueC to the text returned of (display dialog "side C" default answer "")
		set valueAC to (valueA - valueB) / valueC
	end repeat
end if

display dialog "pass"

Is this a start?
Can you give this a try.


set valueAB to 0
set valueAC to 0
set doAB to true
set doC to true

repeat until valueAB ≥ 100 and valueAC ≥ 20
	
	if doAB then
		set valueA to my doDialog("A")
		set valueB to my doDialog("B")
	end if
	
	if doC then
		set valueC to my doDialog("C")
	end if
	
	set valueAB to valueA * valueB
	if (valueA * valueB) < 100 then
		display dialog "multiplication is smaller than 100, restarting AB" buttons {"restart"} default button 1
		set doAB to true
		set doC to false
	else
		set doC to true
	end if
	
	set valueAC to (valueA - valueB) / valueC
	if ((valueA - valueB) / valueC) < 20 and doC then
		display dialog "division is smaller than 20, restarting AC" buttons {"restart"} default button 1
		set doC to true
	end if
	
end repeat

display dialog "pass"


on doDialog(side)
	set valReturned to the text returned of (display dialog "side " & side default answer "")
	return valReturned
end doDialog

Hi mira,

You should explain what you want to do in your script instead of just putting it out there and saying is there a more efficient way of doing this.

gl,
kel

well, the script has no real function. I’m writing a script that has something similar but a bit more complicated to explain than this simple example. I just want to know if what I write is done in an efficient way. It’s a basic script, but since it asks the same display dialogs several times, i wondered if there is no way to simplify it.
Also I’m trying to figure out how to meet an earlier condition again, when the script has to restart due to another condition that is not met in a later phase.

Hello.

I’d try to make it all run inside a repat - until loop, inside the repeat loop, there should be a long nested if test block, that tests for the various states, the state could be “initial” to begin with, inside each if block you have a dialog, and based upon the result, you set a new state, one of the if blocks, should test for a state of “completed”, and then, inside that block, there should be an “exit repat”, in order to get out of the loop.

Here is a slighly different version with the Dialogs inside the repeat clauses


set valueAB to 0
repeat until valueAB ≥ "100"
	set valueA to the text returned of (display dialog "side A" default answer "")
	set valueB to the text returned of (display dialog "side B" default answer "")
	set valueAB to valueA * valueB
	if valueAB < "100" then
		display dialog "multiplication is smaller than 100, restarting AB" buttons {"restart"} default button 1
	else
		exit repeat
	end if
end repeat

set valueAC to 0
repeat until valueAC ≥ "20"
	set valueA to the text returned of (display dialog "side A" default answer "")
	set valueB to the text returned of (display dialog "side B" default answer "")
	set valueC to the text returned of (display dialog "side C" default answer "")
	set valueAC to (valueA - valueB) / valueC
	if valueAC < 20 then
		display dialog "division is smaller than 20, restarting AC" buttons {"restart"} default button 1
	else
		exit repeat
	end if
end repeat

display dialog "pass"

ok, thx for all the input you are giving. I see several ways lead to Rome.
I’d like to stick to one version, but I can use some explanation I have put some comments in the script. I’m using TecNik’s script. Like this I learn to work with handlers too.


set valueAB to 0
set valueAC to 0
--why are these set to 0? Because if the variable is not defined, it will produce an error?
set doAB to true
set doC to true
--Don't know what this is about, the true part...


repeat until valueAB ≥ 100 and valueAC ≥ 20
	
	if doAB then
		set valueA to my doDialog("A")
		set valueB to my doDialog("B")
	end if
	--Pretty sure that once I get the 'true' rule, the following will make sense
	if doC then
		set valueC to my doDialog("C")
	end if
	
	set valueAB to valueA * valueB
	if (valueA * valueB) < 100 then
		display dialog "multiplication is smaller than 100, restarting AB" buttons {"restart"} default button 1
		set doAB to true --same remark as above
		set doC to false
	else
		set doC to true
	end if
	
	set valueAC to (valueA - valueB) / valueC
	if ((valueA - valueB) / valueC) < 20 and doC then
		display dialog "division is smaller than 20, restarting AC" buttons {"restart"} default button 1
		set doC to true
	end if
	
end repeat

display dialog "pass"


on doDialog(side)
	set valReturned to the text returned of (display dialog "side " & side default answer "")
	return valReturned
end doDialog

Hello.

Yes, variables has to be defined before they can be tested, in your first question, the answer to the second question must be that TechNik has made a provisio for condtional execution; like if you had different path to follow before doAB and doC, the code inside the blocks will only execute if doAB and doC is true. Another way to write those tests is if doAB = true, and so on. So what happens it sets it to true once again, that the code should execute, (so it is easily for you to change it, based on some condition you have, in your if tests. :slight_smile:

Hi Mira,

Here’s the script with the ‘is true’ bits in, hopefully that makes it a little clearer.


set valueAB to 0
set valueAC to 0
set doAB to true
set doC to true


repeat until valueAB ≥ 100 and valueAC ≥ 20
	
	if doAB is true then
		set valueA to my doDialog("A")
		set valueB to my doDialog("B")
	end if
	
	if doC is true then
		set valueC to my doDialog("C")
	end if
	
	
	set valueAB to valueA * valueB
	if (valueA * valueB) < 100 then
		display dialog "multiplication is smaller than 100, restarting AB" buttons {"restart"} default button 1
		set doAB to true
		set doC to false
	else
		set doC to true
	end if
	
	set valueAC to (valueA - valueB) / valueC
	if ((valueA - valueB) / valueC) < 20 and doC is true then
		display dialog "division is smaller than 20, restarting AC" buttons {"restart"} default button 1
		set doC to true
	end if
	
end repeat


display dialog "pass"

on doDialog(side)
	set valReturned to the text returned of (display dialog "side " & side default answer "")
	return valReturned
end doDialog

I tried to follow the flow of your original script and then I spotted the last bit about re-testing ValueAB again, hence the repeat loop round everything. I’d originally just put the user entry parts in a handler.

As McUsrII said, I’ve set the values of valueAB & valueAC to 0 because of the test in the repeat loop. If I hadn’t set the variables at the start we’d get an error, the first time round this loop, because they don’t exist.

I’d set the flags doAB and doC to trigger the user input of valueA, valueB and valueC as per the first 3 lines of your original listing.

I think the ‘logic’ route may differ slightly from your original requirements and may need some testing when it comes to the values that could come from the user e.g. 0’s or blank entries etc.

HTH