yes, once again im doing some work on Play MiniTunes but im stuck with my playpause button. IT seems like it should be simple…the concept definately is. I want it so if iTunes is paused the pp button has a pause icon if it is playing it has the play icon. i tried this:
on clicked theObject
if the name of theObject is equal to "pp_button" then
using terms from application "iTunes"
set the_state to player state
if the_state is playing then
set icon of theObject to "play_arrow.png"
else if the_state is paused then
set icon of theObject to "pause_arrow.png"
end if
tell application "iTunes"
playpause
end tell
end using terms from
end if
but i noticed “icon” is not the right word (it came out as a variable when i compiled the script)
Check the button documentation or the dictionary in Xcode.
on clicked theObject
if the name of theObject is equal to "pp_button" then
tell application "iTunes" to set isPlaying to player state is playing
if isPlaying then
set image of theObject to load image "test1.png"
else
set image of theObject to load image "test2.png"
end if
tell application "iTunes" to playpause
end if
end clicked
Why bother loading ang unloading images and checking state, when you can let Interface Builder and nsbutton do all of that for you? In IB, you can set the image of the button to your play image, and then set the ‘alternate image’ to your pause image. Set the “Behavior” option of the button as a “Toggle” button. The toggling of the button’s image is done for you, and you don’t use any extra memory loading more images to put into it. All you need to do is keep track of which state you are in and which state you want to be in, and set it programmatically. If you stick with something like what you’re already doing, the following would handle everything for you, without messing with loading or setting images…
tell application "iTunes" to set isPlaying to player state is playing
set state of button "PlayerAndPauserThingy" of window "GroovyWindow5000" to isPlaying
Don’t reinvent what you already get for free in the basic abilities of the object.
In this thread I posted an obj-c subclass that watches itunes via notifications rather than polling itunes using an idle handler. It could easily be configured to handle everything you’re doing, and would tie your interface to itunes better than retroactively trying to keep track of changes it makes or that the user makes to it outside of your interface.
uh ohhhh…when i added the alternate icon and saved…IB unexpectedly quit and now when i try and open my MainMenu.nib it says “The document MainMenu.nib could not be opened.” that’s not cool…
I just had the same problem and had to practically rebuild the the main nib but all is not lost for you if you had not trashed the main~.nib. That should be the automatic backup file of your main nib that got corrupted.
If you can’t get your corrupted main nib to work (and you probably will not be able to as I experienced with my little knowledge of file recovery) then the main~.nib should be able to give you the original nib before you lost the main nib. However, based on my experience again you will not be able to save any new editings in your main nib. It means that you have come to a point that your main nib is really corrupted even if you are able to recover the backup.
Right now, I learned a pretty painful lesson so every few builds that I like, I always save a copy of my main nib somewhere so that in case something goes wrong, as it seemingly occurs frequently especially with Xcode 2.4.1, I can get back to a cleaner version.
BTW, there was an early thread on this same issue that I posted several months ago and got several good responses. Still I didn’t learn my lesson well or forgot all to easily. Shucks!
ugh, it’s pretty much messed…it’s going to take for ever to rebuild! yeah the backup just got corrupted to when i tried to save…grrr…that ticks me off…i dont care about rebuilding the window but renaming all the objects is going to be a big pain in the @$$:(…because i noticed when you copy an item and paste it it doesn’t keep it’s name:(
Yeah, I can sympathize with you. I’ve gone thru hellacious times myself finding a fix and ended up rebuilding the thing. What a waste of valuable time but what can we do? Nobody seems to have a good fix right now. The backup thing worked with me for a while until I found out that, while the app would compile and be useful to that end, the backup nib would not accept anymore changes no matter how small so that was practically the end.
Learned my lesson well so, like I said, every build that pleases me gets the main nib stored in a safe haven.
Let’s hope some clever guy finds a way to recover lost nibs.
indeed, or in the next IB build they throw in a preference that lets you choose to keep the objects name and values (clicked, idle, etc) when you copy it. It would be incredibly handy and would make rebuilding a nib file a snap.
I absolutely agree. Let’s just hope something good comes out soon…either from Apple, Inc. or from some third party developer. It’ll take the pain in the …!
Meanwhile, if you get around to replacing your corrupted nib file with something clean in the future remember one thing before you get frustrated again - you cannot just copy the nib file directly to your project’s folder (like the English build folder). The nib would copy but the compilation will fail. I just noted this. The only way the clean nib would be accepted by the project is by adding it via the “Add to the project” menu item method.
Just for your info for future use. Stash it somewhere to use for the rainy day.
Most newer ASStudio developers run into a major crash and burn like this at some point. I did early on and gave up on my first major project because I didn 't want to have to redo it all again. Although it’s a pain to have to redo everything, even if just once, it’s a good learning experience and teaches you that you and your projects are not invincible. There’s a lot going on behind the scenes with xcode and IB, and you have to learn to respect that it is your responsibility to make sure you don’t do something that will risk all of your long hours of hard work. Crashes like this are usually caused by messing with things too much and working on your UI as you work on your actual project rather than in developmental test versions. You should try to only make changes… especially major ones… when you are certain that you know exactly what you want and how you want it. The more you tweak things and go back and forth with your design the more you open yourself up to conflicts and corruption,
The key is to MAKE BACKUPS. Manually, or with a custom automated solution. What I do routinely… like every day when I’m done working on a project for the day… is to reveal the project in the finder, and make a copy of the WHOLE THING. Just select the “duplicate” command in the finder contextual menu and make a copy of the project’s entire folder. Make sure to clean the project before building it, so you don’t end up copying the executable every time. It does make copies of all the resources such as images and other files, but it’s a small price to pay for a FULL working copy the next time you need to back up a bit, whether because you had a crash or made a change you don’t like any more. I just let the finder name the copies incrementally for me (i.e. “Project copy 1”, “Project copy 2”, etc.) so I can go back through them incrementally if necessary. I believe that in another thread there were some scripts posted that automate this process, and Xcode may today or tomorrow have this feature built in, but I’ve gotten out of the habit of letting applications do my backing up for me because they often don’t back up how or when I want them to. I also regularly make dvd backups of ALL my development projects and important files, because you can’t assume that you won’t have an unexpected hardware problem.
My point… NEVER think that a crash or corruption won’t happen to you. It WILL. At least that’s the way you should look at it. Choosing to not protect yourself from it now and not having a system in place for keeping real development versions for reference or to protect your hard work is foolish… unless you like doing everything twice.
We should really be backing up the whole project rather than just the main nib albeit most of the headaches I’ve had has been with the nib file. But you’re quite right, it’s safer to backup the entire project.
Indeed, there was an earlier thread on this (I was in it) but I still did not learn my lesson well. Time to implement what had been learned. The auto-backup idea that came about in that thread is worth looking at henceforth.
The value I find in keeping lots of backups is twofold. Recovering a nib from a crash is certainly a fantastic thing, but as I said, since I am a bit more premeditated with my approach to developing my interfaces I don’t have nearly as many problems with losing nibs anymore. All of the problems I’ve encountered with nibs getting corrupted seem to stem from having a scatterbrain development style. That’s certainly not to say that I don’t learn as I go and add things that I hadn’t planned on adding along the way. This, in fact, is where I’ve learned to place the greatest value on keeping backups. Earlier, I mentioned “developmental test versions”, which are really just copies of my most stable project that I’m trying the next development step on. Every time I get some major task or element accomplished, I make a backup. This becomes my baseline project, around which all further development will occur. I will often explore new concepts, code, or elements on a test copy, and if it doesn’t work out I just pitch it in the trash and I know I’m simply right back to my last stable version. Even if my changes do work out and I decide to keep them, chances are it still does not become part of my main project. I’ll take all of the code and objects I want to keep, clean 'em up, and make another new copy into which I cleanly and carefully add it all. This may seem complicated, but I’m big on cleaning my code as I go, rather than when I’m done with the project. Since cleaning up your code is always a wise thing to do before releasing a project, I figure I can get most of that work done during development rather than after. On big projects this can be a lifesaver, because I often forget what I wrote at the beginning by the time I reach the end months or years later. I have come to the conclusion that saving full backups is the only thing that I can do today that I can be sure will prepare me for whatever I may have to deal with tomorrow.
Again, you are absolutely correct in your presumptions - most of the problems that I had encountered especially losing nibs were generated when I start looking at new things that just pop out of my mind, not necessarily part of a big plan, and, I must say, I got burned quite a few times in the process. But that’s part of being a newbie to AS Studio. I don’t claim I am a savvy AS Studio programmer, not by a long shot! And, as you said, most problem do occur by having a scatterbrain development style -unfortunately correct as I intimated above. While surely not justifying the scatterbrain approach, I must say that it is perhaps common among newcomers, partly because of lack of experience (including especially painful ones from losing nibs and other essential things) and our eagerness to explore, to see what results from applying certain things to what we are doing. These are, I believe, common H. sapiens trait (I am Curious George).
But, I don’t want to use that as an excuse. Else experienced programmers like you may not be forthcoming to help newbies like us who do not learn readily from mistakes. Yes, I am now backing up my project religiously I must admit. As to creating a well-conceived master plan for a project, perhaps I can begin to learn that too as I certainly recognize its benefit.
Hopefully, there’ll be no more sad experiences to meet along the way and to share in this forum.
just wondering, if i downloaded the last release of my own program when into its contents and grabbed that nib file and stuck it in my project, would that work?
EDIT: Turns out, luckily for me that that works fine! i have my nib back and updated and a back up of the entire project has been made
yeah i hadn’t lost anything in my nib because the first change i tried to make to it since its last release, was when it was corrupted. so now i have a working program with a clean backup, im very relieved, hope it helps you archseed!
