macOS ProgressBar

[CylonGlitch]

I'm stumped and maybe someone knows what's going on. Here is the problem in a nutshell. I have an app that I want to take files from a drop and drag and then process each one. This is fine, it works without issue. BUT I have a ProgressBar that I start animating with [piRunning startAnimation:self]; or whatever the function is. I have a test button I created that processes just one file; and everything is fine. BUT if I drop the same file on (or any file for that matter) it does all the work, but the progressBar doesn't animate.

I've stripped out all code except the bare minimum to cause what I'm doing. If you have a few minutes to look it over please let me know if you see what's going on.
testDragDrop Archive

Remember clicking the button works exactly as I would want it to do; dropping the file, does the file processing but no animation. 🙁

Thanks,
Dave

 

[CylonGlitch]

No ideas?

Thanks for looking though. 😀

 

[jared_kipe]

Ok couple of things. When you press the button , you are triggering
- (void)startPB; Which does different things. In fact it is making the progress run by doing [self.piRunning startAnimation:self];

Technically this isn't called anywhere else so I'm not sure why you expected it to be animating, since nothing else seems to call -startPB.

The most obvious thing to me was to try to call that in something like - (BOOL)performDragOperation: HOWEVER that didn't work. Took me a while to decide to try to log out the NSProgressBar object. SURPRISE it is nil.

Some curious things going on. You're treating a view as if it is a view controller. So I decided to NSLog out self in those two methods... SURPRISE again self (aka the view) are two different views, one of which has a NSProgressBar and one which clearly does not.

 

[xStep]

First, be patient. You're posting to a forum where people come an go at their pace, not yours. 15.5 hours is a short time to expect someone to actually go look at your code sample. Most of the time I refuse to do that. Today while at work I saw your post, but couldn't return to it until late tonight. Anyway...

It sounded like an interesting puzzle so took a quick look. Can't say I've played with NSTask, so take the following with a grain of salt, as they say.

I found it interesting that you are potentially calling starPB multiple times but keep using the same runTimer object. When the first stopPB call gets called, it will affect the last runTimer setup. So I suppose you could be stopping later timers and therefore you animation. If you are stopping a later timer, then the earlier ones will continue to run forever. I think you only want one timer.

In the sample code, sysCmd isn't setup anywhere, so you are hiding some valuable information from us. If you are doing the same thing with sysCmd as you are with runTimer, then again, that may be an issue. Say that latest sysCmd finishes before earlier ones, then the stopPB gets called and ends the animation.

In the context given, timerTimeout doesn't make sense to me. Just increase the time for the timer instead. For each new pass through startPB you do reset it to zero, but after that last reset and after incrementing greater than 10, it will aways pass the test in the updateTimer: method.

I see NSProgressIndicator has a method named setUsesThreadedAnimation: which might be helpful to you. Although I suspect other problems as mentioned above.

 

[CylonGlitch]

Ok couple of things. When you press the button , you are triggering
- (void)startPB; Which does different things. In fact it is making the progress run by doing [self.piRunning startAnimation:self];

Technically this isn't called anywhere else so I'm not sure why you expected it to be animating, since nothing else seems to call -startPB.

startPB is called from within the processFile routine. The processFile routine is called when you click the button (line 188) or when files are dropped (line 125). The only difference between the two calls is that the one from the drop will iterate through all of the files dropped and call this routine for each one (normal testing is using only one file); the other one is called when the button is pressed using a hard coded test file.

The most obvious thing to me was to try to call that in something like - (BOOL)performDragOperation: HOWEVER that didn't work.

Nah, I don't call this, it gets called automatically when drag operations are going on. The whole drag and drop section is almost directly copied from Apple's example code.

Took me a while to decide to try to log out the NSProgressBar object. SURPRISE it is nil.

I should have thought to look at that, but why would it be NIL when performing the drop but not when getting the button click? Very odd behavior.

Some curious things going on. You're treating a view as if it is a view controller. So I decided to NSLog out self in those two methods... SURPRISE again self (aka the view) are two different views, one of which has a NSProgressBar and one which clearly does not.

This has to be the source of the problem.. hmm... not sure why there would be two views . . . I'll look into this more. Thanks.

----------

First, be patient. You're posting to a forum where people come an go at their pace, not yours. 15.5 hours is a short time to expect someone to actually go look at your code sample. Most of the time I refuse to do that. Today while at work I saw your post, but couldn't return to it until late tonight. Anyway...

Yeah, I know. Sorry, been banging my head against a wall on this for quite some time now. 🙁 If I can get this one thing to work, everything will be working the way I want it to . . . besides features yet to come.

I found it interesting that you are potentially calling starPB multiple times but keep using the same runTimer object. When the first stopPB call gets called, it will affect the last runTimer setup. So I suppose you could be stopping later timers and therefore you animation. If you are stopping a later timer, then the earlier ones will continue to run forever. I think you only want one timer.

True, but this is more of a function of the sample code then the real code. The real code will verify that one process is done before the next one begins. The push button is just for me to debug stuff with, but I left it in as an example of working the way I want it to work.

In the sample code, sysCmd isn't setup anywhere, so you are hiding some valuable information from us. If you are doing the same thing with sysCmd as you are with runTimer, then again, that may be an issue. Say that latest sysCmd finishes before earlier ones, then the stopPB gets called and ends the animation.

sysCmd is never used in this sample code yet the code shows the same issues as the code that does use it. I removed everything that wasn't necessary to seeing the problem; no need to have to wade through hundreds of other lines of code.

In the context given, timerTimeout doesn't make sense to me. Just increase the time for the timer instead. For each new pass through startPB you do reset it to zero, but after that last reset and after incrementing greater than 10, it will aways pass the test in the updateTimer: method.

I see NSProgressIndicator has a method named setUsesThreadedAnimation: which might be helpful to you. Although I suspect other problems as mentioned above.

Yeah, been through that, didn't seem to make a difference. I'm guessing it has to do with the multiple views that Jared saw. I bet that's the root cause.

Thanks guys, at least now I have some ideas where to start looking.

Dave

 

[jared_kipe]

startPB is called from within the processFile routine. The processFile routine is called when you click the button (line 188) or when files are dropped (line 125). The only difference between the two calls is that the one from the drop will iterate through all of the files dropped and call this routine for each one (normal testing is using only one file); the other one is called when the button is pressed using a hard coded test file.



Nah, I don't call this, it gets called automatically when drag operations are going on. The whole drag and drop section is almost directly copied from Apple's example code.



I should have thought to look at that, but why would it be NIL when performing the drop but not when getting the button click? Very odd behavior.



This has to be the source of the problem.. hmm... not sure why there would be two views . . . I'll look into this more. Thanks.

----------



Yeah, I know. Sorry, been banging my head against a wall on this for quite some time now. 🙁 If I can get this one thing to work, everything will be working the way I want it to . . . besides features yet to come.



True, but this is more of a function of the sample code then the real code. The real code will verify that one process is done before the next one begins. The push button is just for me to debug stuff with, but I left it in as an example of working the way I want it to work.



sysCmd is never used in this sample code yet the code shows the same issues as the code that does use it. I removed everything that wasn't necessary to seeing the problem; no need to have to wade through hundreds of other lines of code.

In the context given, timerTimeout doesn't make sense to me. Just increase the time for the timer instead. For each new pass through startPB you do reset it to zero, but after that last reset and after incrementing greater than 10, it will aways pass the test in the updateTimer: method.



Yeah, been through that, didn't seem to make a difference. I'm guessing it has to do with the multiple views that Jared saw. I bet that's the root cause.

Thanks guys, at least now I have some ideas where to start looking.

Dave

Ahh I missed the call to startPB because of the use of @selector vs a standard message send.

Ok well after a little digging (it was late last night and the wife wasn't happy about the amount of time I was online) I have fixed it.

And when I say fixed, I mean that I made it work with its current configuration.
The problem was in fact two separate instances of DragDropView inside of MainMenu.xib.

You'll note the first one (the one that takes the drop operation) does NOT have an outlet connected to that NSProgressBar. If this wasn't Objective-C messaging its piRunning would result in a crash on most languages.
The second instance of DragDropView has its outlets hooked up, and is the one that receives the button presses.

'Fixing' it was as simple as connecting the first DragDropView's piRunning outlet up to the NSProgressBar. That fixes the animation, but it obviously doesn't fix it the right way. I leave that up to you.

 

[CylonGlitch]

Ok well after a little digging (it was late last night and the wife wasn't happy about the amount of time I was online) I have fixed it.

Sorry about that! 🙁

Have a virtual beer on me.

'Fixing' it was as simple as connecting the first DragDropView's piRunning outlet up to the NSProgressBar. That fixes the animation, but it obviously doesn't fix it the right way. I leave that up to you.

I don't know how I didn't see that. Sometimes you're just so close to the project that you don't see something obvious.

Thank you so much for all your time. Really, I appreciate it. 😀

Dave