Hi!
Can someone PLEASE explain why the following code causes the progress bar to update so slowly? It currently takes between 16 and 17 seconds! Is this usual behaviour?
dd install with grayscale
dd make dialog {size:[300, 100], style:movable dialog, name:"Progress", contents:
{class:static text, contents:"Calculating...", bounds:[8, 4, 290, 20]},
{class:gauge, bounds:[10, 25, 290, 25 + 12], value:0, max value:100},
{class:push button, bounds:[200, 60, 258, 80], name:"OK"}]}
repeat with n from 1 to 100
dd set value of item 2 of dialog 1 to n
if (dd interact with user for max ticks 0) is 3 then
exit repeat
end if
end repeat
dd delete dialog 1
if (dd count dialogs) = 0 then
dd uninstall
I’m trying to create a progress bar which the user can cancel at any time. Being quite new to ‘dd’ I’m really just experimenting with various things at the moment. Most stuff has worked as expected and I’m pleased with the results but unfortunately I’m a bit stumped on this one…
Incidentally, using ProgressBar OSAX it runs much quicker. (I’ve not timed it but would guess about 2 seconds max.)
Any help would be great,
Thanks
Juerg
Looking at your code here I thought I spotted something to comment on, and I nearly did. I had to go off-line, however, and took a copy in the clipboard. The previous responder is actually right that you should alter your format coding - it doesn’t help.
Anyway I stuck your code in the EditorÉ There is nothing wrong with it!
[b:000]1 [/b:000]The way to speed it up is by altering the loop to, e.g. [code:1:000][b:000]repeat[/b:000] [b:000]with[/b:000] [color=#CC0000:000][b:000]n[/b:000][/color:000] [b:000]from[/b:000] 0 [b:000]to[/b:000] 100 [b:000]by[/b:000] 5[/code:1:000]Note that 1 to 100 is only 99 steps - you need 100 for the bar to get right to the end.
[b:000]2 [/b:000]I don’t think it does speed up by a tiny or a greater shift to the DLOG. I think what is happening is a temporary stopping of ‘progress’ followed by a catching up, which fools the eye.
[color=#FF00FF:000]Andreas[/color:000]
I forgot to add something…
While the script is running, if I move the dialog the whole process speeds up! Simply clicking the title bar doesn’t speed it up but moving only by a single pixel does! Now THAT’S the really weird part!!!
Juerg
: [formatted using ScriptToEmail - gentle relief for mailing
: list pains]
: [http://files.macscripter.net/ScriptBuilders/ScriptTools/ScriptToEmail.hqx]
OT here, but I wouldn’t recommend using ScriptToEmail for formatting forum posts - it’s intended for email formatting (specifically, formatting code in a way that won’t get mauled by Apple’s AS Users List).
Putting
tags around your code is usually good enough. The only time that can cause problems is if your code contains symbols that may be misinterpreted as tags or html entities, in which case you can get some funny-looking posts. But I’ve only seen that happen very occasionally (and it’s easy enough to check for any such problems by previewing your posts).
I can’t say I’m a big fan of the way this forum leaves all formatting issues for the user to sort out (not everyone is an expert at writing html on the fly), but that’s how it goes. There are one or two scripts out there that can apply formatting and stuff for you (though I’ve never used them myself so dunno if they’re any good or not).
HTH
it does really suck that a BBS that is designed for script writers can’t actually handle the formatting! Just as unforgivable as an Esquimo who can’t read English, wouldn’t you say? When you do everything perfectly and the site lets you down then the site really sucks. Thanks for the pointers anyway Just pointers? Is your problem solved or not? When you do everything perfectly and DD lets you down then DD really sucks - is really weird as you say - when you do everything perfectly.
Andreas
Sorry about the code! My mistake
I must say that in my defence it does really suck that a BBS that is designed for script writers can’t actually handle the formatting! Surely that should be one of the first things it should be able to do. If someone like myself wants to post code with line breaks what SHOULD I do?
Oh, and incidentally, I definitely DIDN’T post the second message twice!
Oh well, what the heck!
Thanks for the pointers anyway.
Juerg
Forgive me but you are doing things in a peculiar way and then complaining that they don’t work. You have set “max ticks” to zero (which doesn’t make much sense, does it?) presumably in an attempt to alleviate your problem (which it doesn’t), but actually you really shouldn’t be running the progress bar from the “dd interact with user” loop in the first place. Take it out of that loop (or remove the “dd interactÉ” bit) and you may want to slow your progress bar down!
I honestly think that rather than try any more to make this work you should go back to the drawing board and re-think a way of achieving your objective. Is this part of a bigger project or just a little experiment? Is it essential that the user be able to stop the progress bar or are you just trying to see how to do it?
A different approach, for instance, might be to put a tiny ‘static text’ in lieu of your button, reading “Option key aborts” and then replacing the “dd interactÉ” with “if (keys pressed) = {“Option”} then exit”. Lots of ways of making omlettes!
The question you ask: “Why should an Eskimo need to learn English?” could be paraphrased in two waysÉ
1 Why should this site be able to read your (email-type?) code?
orÉ
2 Why doesn’t DD understand my idiosyncratic way of doing things?
I love innovators and people who want to change the rules, but the innovator must expect at least some sarcasm if his innovation is a retrograde step; similarly for the rule changer to blame the system that runs on the old rules is bizarre, don’t you think?
You may find it helpful to look at the source code for this page - some of the formatting is incredibly simple. If it wasn’t how do you think I manage it??? Andreas
Why should an Eskimo need to learn English? I assume you’re being sarcastic here…
I wasn’t aware that I had to learn HTML or whatever in order to use this BBS. If I do, fine. Where’s the link to tell me how to do it? Where’s the link telling me how to submit code correctly? Can YOU tell me how to submit code properly? Seems to me like there isn’t a single, correct way because not two people appear to use the same formatting. I’m trying my best to make life as simple as possible and getting no-where. OK so I screwed up - the code looked a mess but at least I’m trying. So why is it that all I get is sarcasm about Eskimos!?!?
And no, my problem isn’t solved. It’s still slow and moving the dialog DOES speed it up. It’s not visual. By using DD the code slows down - I guess through the use of ‘interact with user’. That’s what I find weird. Maybe DD is behaving correctly but to me it seems an unfair compromise that in order to allow a user to interact with a progress bar it slows down the processing of whatever it is the script is trying to do!!!
Whatever. Who cares anyway…
Juerg
PS I have no idea whether this will be at all helpful or not - it’s a minor variation on your theme:
dd install with grayscale
set d to dd make dialog {size:[300, 100], style:movable dialog, name:"Progress", contents:
{class:static text, contents:"Calculating...", bounds:[8, 4, 290, 20]},
{class:gauge, bounds:[10, 25, 290, 25 + 12], value:0, max value:100},
{class:push button, bounds:[200, 60, 258, 80], name:"OK"}}
set {n, fin, step} to {0, 100, 5}
-- Obviously, use 'step' as the speed control
repeat
set i to dd interact with user for max ticks 1
set n to n + step
if (i = 3) or n > fin then exit repeat
dd set d's item 2's value to n
end repeat
dd delete d
dd uninstall
Hi!
Thanks for getting back to me. Sorry for my outburst…
: Is this part of a bigger project or just a little experiment?
This IS an experiment but one which I need to incorporate into an exisiting script. The main part of this script exists in a repeat loop and the entire cycle can take up to 10 minutes. If the user realises they’ve made a mistake when inputting information in the GUI, I need a way to let them abort the script and start again.
:You have set “max ticks” to zero (which doesn’t make much sense, does it?)
That’s what I thought when I saw the example ‘Progress.as’ that came with DD. What I’m saying is - my script was based on an example that came with DD. My mistake? Probably, but I’m not sure how if I followed an example supplied by the author of the OSAX which I’m using… I suspect there’s been an oversight on my part but I just can’t see it.
: A different approach, for instance, might be to put a tiny
: ‘static text’ in lieu of your button, reading “Option key
: aborts” and then replacing the “dd interactÉ”
: with " if (keys pressed) = {“Option”} then exit
: ". Lots of ways of making omlettes!
I’m not too keen on omlettes myself but the idea is great!
: You may find it helpful to look at the source code for this page
: - some of the formatting is incredibly simple. If it wasn’t
: how do you think I manage it???
Hmm… so why does the continuation character (option-return) not appear correctly? I’d like to be able solve these sorts of problems. Other users may not have picked up on this and find that they can’t use the code you submitted… THIS is why I was having a moan. I’m sure I’ve seen somewhere, a forum/BBS which allows user to click something like ‘Insert Code’ and it imports the code correctly. I don’t think it was for AppleScript though but it was a great idea.
Incidentally, I still have the problem with DD progress bars running too slowly. This happens on all the progress examples supplied with DD and on your example (which works great, thanks!). I’m using DD v0.7 and AS 1.6 - am I running and outdated version of AS?
Many thanks for your persistence,
Juerg
" I still have the problem with DD progress bars running too slowly"
Juerg, I just don’t understand what this means. The speed of the progress bar depends not on DD or on your version of anything - it depends on how often you increment its value and by how much each time. The ‘how often’, with the sort of script you are using, could be altered by changing ‘max ticks’, but that will produce a jerkiness which you may not like. What happens if you do as I suggested and alter the value of ‘step’ in my latest offering, or the value of ‘increment’ in ‘repeat with x from 0 thru 100 by increment’? Do you have other things happening in your loop which affect the frequency of incrementation (i.e. the speed of the loop)?
±±±+
Concerning formatting on this bbs the sort of question you are now asking tells me that you may find what you need by going to Marc Myers’s site and looking at his excellent “HTML text”. Andreas
Juerg - I still can’t understand why you think you have a problem, and I can’t see the purpose of all these timings. I repeat:
The speed of the progress bar depends not on DD or on your version of anything - it depends on how often you increment its value and by how much each time.
You are using a “dd interact with user” loop and it should therefore be no surprise that it notices your “interaction” of moving the dialog. Having sensed an interaction that cycle of the loop can end and another one start. As I said before, ‘working’ the progress bar from the ‘interact’ loop may not be the best of ideas.
You make it sound as if a shorter timing is in some way ‘better’ than a longer one. I cannot see this as a question of good versus bad - what I would say matters is the final visual effect on the user. I repeat:
The speed of the progress bar depends Éon how often you increment its value and by how much each time.
You want it to go faster? Increase the ‘step’ or the frequency - and vice versa. You don’t like to see the speed alter as you move the DLOG? Do you HAVE to move the DLOG?
My suspicion, Juerg, is that you don’t have a problem, but that you just can’t rest easy without understanding what’s happening. Am I right? Is that the real ‘problem’? Or have I missed something?
Today’s sugestion for you - change to a non-movable style of dialog. (Not just a joke - it might remove part of the ‘problem’.) Andreas
Andreas,
I’ll try to expain what exactly is happening…
Using your example I timed it by using Jon’s Commands ‘the ticks’ at the start and end of the script, then subtracting one from the other and dividing by 60.
The average running time is 3.78 seconds.
However, if I run the script and immediately move the dialog as soon as it appears, the whole thing speeds up to an average 0.72 seconds. This is what I don’t understand. Why should moving the dialog speed everything up???
I’ve submitted a copy of the script I’m running - it averages at 23.3 seconds. Again, if I move the dialog as soon as it appears I can get it to run in 3.8 seconds.
Can you tell me how long it takes your example to run on your Mac? And may be you’d be so kind as to run my script and let me know how long it takes to run that one too!?
I thought that I’d been making a silly mistake but the same thing happens on your example, which makes me think that the problem lies not in the script itself but elsewhere.
Thanks once again for your help,
Best wishes,
Juerg
dd install with grayscale
set Dialog_01 to (Your Dialog Info)
set Temp_Dialog to Dialog_01
repeat (until i is equal to 1)
set i to interact with user --(only if you want buttons to be active before you start the main process)
if i is equal to 1 then
repeat (until i is equal to 1)
dd set the value of item 2 of Temp_Dialog to i
end repeat
end if
end repeat
This might speed it up a little and actually gives you the option of running the application twice. although it is not wise to use the same button to stop the progress of the application as you do for quiting the program. I am unsure if the (until i is equal to 1) will work, but if not you will have to do another if statement.
– David
OK, I’m giving up now… I’m obviously just not getting it
Maybe part of the problem IS that I can’t rest easy. I just can’t understand why interacting with the user for 0 or 1 ticks slows everything down so dramatically… The timing IS important. If a routine which should not really take too much time takes up to 30 times longer then I see it as a problem. I guess I’ll just have to accept that I don’t fully understand why the interaction slows down the routine and use your method of holding the option key to abort.
I think I’ve taken far too much of your time as it is and don’t want to waste any more of it!
Thanks for all your help - I’m sorry if it’s been frustrating for you!
Cheers,
Juerg
