Hi all.
Any body know, what happened with progress indicator in these El Coyote OSX? :mad:
i look in what’s new, but there say nothing about, displayIfNeeded() present… but progress bar lost animations.
Best regards, Alex.
It’s just part of the redesign. Copy a large file in the Finder and you’ll see the same thing: there’s a very subtle animation before the copying starts, then none that I can discern.
Nice redesign :lol:
First time show initial message, then “App is idle…” and finally “ label about last file from queue, full progress bar.
Any idea how to make it work?
That sounds like a different issue. Have you tried the method outlined in chapter 13 of my book?
Alex,
I’m assuming you’re telling the window to displayIfNeeded(). As a quick hack, try adding this after that line:
delay 0.0001
It works here with 10.11, and it shouldn’t cause problems with earlier versions – although you’ll need to check.
Thanks, Shane
Sample project from chapter 13 work well. Now I need to move it in my projects.
FWIW, I’ve added an update to the book’s errata page on the topic:
Hi, Shane.
I did some changes in my project with samples from Ch. 13 and discovered one problem “ progress bar shows with one step delay.
-- the original doProcess_ handler has been split into four
on doProcess:sender -- STEP 1. Call and initialize progressbar
windowProgress's makeKeyAndOrderFront:me
set my isIdle to false -- app is no longer idle
set aFile to item 1 of vectorFilePosixPaths
set my vectorFileName to (its nameFromPath:(POSIX path of aFile)) as text -- Initial file name for progress bar
my performSelector:"doStartOfJob:" withObject:1 afterDelay:0 -- call next handler as new event
end doProcess:
on doStartOfJob:n -- STEP 2. Refresh file name and show it
set n to n as integer -- need to coerce because it's been passed via Cocoa
set my statusMessage to "Processing number " & n
set my theCounter to n
set aFile to item n of vectorFilePosixPaths
set my vectorFileName to (its nameFromPath:(POSIX path of aFile)) as text -- Current file name for progress bar
(*
tell application "Finder"
activate
display dialog "vectorFileName: " & vectorFileName as text
end tell
*)
-- this where you would do your stuff
my simulateJob:n -- simylate job with call "display dialog"
--my workIllustrator:n
my performSelector:"doRestOfJob:" withObject:n afterDelay:0 -- call next handler as new event
end doStartOfJob:
on doRestOfJob:n -- STEP 3. Loop if need
set n to n as integer -- need to coerce because it's been passed via Cocoa
current application's NSThread's sleepForTimeInterval:0.5
if n < (vectorCount as integer) then
my performSelector:"doStartOfJob:" withObject:(n + 1) afterDelay:0 -- call previous handler as new event
else
my performSelector:"cleanUp" withObject:(missing value) afterDelay:0 -- call next handler as new event
end if
end doRestOfJob:
on cleanUp() -- STEP 4. Reset progress bar and stop process
set my statusMessage to "Finished processing " & (vectorCount as integer) & " times."
set my isIdle to true
end cleanUp
on simulateJob:n -- Simulate intense activity
tell application "Finder"
activate
display dialog vectorFileName & " “ " & n as text
end tell
end simulateJob:
When i start STEP 1. Show noting, progress window opens after the call and close the first dialog box, and show file and progress with one step later.
I’m not sure of your problem – the sample works OK. However, I suggest you follow the samples that don’t have “as Steps” in their name. I suspect using the equivalent of doEventFetch() is going to be the only reliable way to deal with the changed updating behavior.
Maybe, but i try to move progress bar to another window and have same issue “ progress window show only after first step is done.
this Declarations “ “makeKeyAndOrderFront:” and “orderFront:” don’t show me progress window before any kind of stuff, whose called after.
Sorry for my english.
Yes, I think you’re going to have to call either doEventFetch() (or equivalent) or performSelector:withObject:afterDelay: at or very close to the point where you want something to appear or change on screen. That’s an advantage of the doEventFetch() method, in that you can virtually throw it in anywhere.
It’s a big change in behavior.
(Your English is fine…)
Just to be clear, here is what I think will be the easiest and best solution, at least within an app delegate class:
-
Find Myriad Helpers – you can download it from my Web page.
-
Drag the files ObjectWithFords.h and ObjectWithFords.m into the Navigation area of your project, clicking the Copy checkbox.
-
In your app delegate file, where it says:
property parent : class "NSObject"
change it to:
property parent : class "ObjectWithFords"
That makes your app delegate inherit the methods of the ObjectWithFords class.
- Now, wherever you want to screen to be updated, use:
my fordEvent()
And here’s an alternative that seems to be working:
Where you use displayIfNeeded(), for example:
|window|'s displayIfNeeded()
change to:
|window|'s performSelectorOnMainThread:"displayIfNeeded" withObject:(missing value) waitUntilDone:true
I have only tried it one project, but it works there.
Don’t you need to set the needsDisplay property to true, in order to make displayIfNeeded() to work? I never had to use that method, setting the property to needsDisplay to true was always enough.
it’s a good thought. But up until 10.11, displayIfNeeded() alone was fine when the control was changed via bindings, as is the case here – presumably the bindings mechanism marked the relevant controls as dirty.
In any event, adding setNeedsDisplay:true to the window’s content view, either as well as or instead of displayIfNeeded(), doesn’t seem to make any difference in this context (which is for updates within a repeat loop, so not at the end of an event).
Thanks, Shane.
I’m sorry, i put my call handler in wrong place I should place caller in step 3, not in step 2. Now all work well with sample for Chapter 13. With steps and with step with cancel.