Progress bar is broken in ElCoyote 10.11

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?


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"
			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
			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"
			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.